Любое отключение питания в стойке — это инцидент, который инженер дата-центра должен решить в минимальные сроки. Чаще всего критически важное оборудование в ЦОДе запитано от двух лучей, и после сбоя одного луча устройства нормально работают от второго. Но бывают банальные ошибки подключения и нестандартные случаи, из-за которых "падает" вся стойка.

Каждый сбой в питании мы фиксируем в системных журналах и отчетах смены и затем анализируем причины падений. За годы у нас накопилась статистика удивительных, а иногда просто глупых ситуаций падения стойки. Заодно мы собрали несколько таких историй от коллег в нашем чате Салатовой телеги. 

Сегодня расскажем, как учесть этот опыт и снизить вероятность "падения" серверной стойки.

Ни для кого не секрет, что большинство вендоров СХД привязывают своих пользователей к накопителям собственной торговой марки. Так что типичный подбор, например, SSD подразумевает определение парт-номера накопителя в соответствии с характером нагрузки (read, mixed, write) и его емкостью. В целом, данный подход призван облегчить жизнь IT отделу, но при этом создать повышенную нагрузку на бюджет компании. А бюджеты, как известно, не резиновые. Поэтому всегда существовали и будут существовать вендоры, производящие решения из области хранения данных, которые позволяют использовать накопители сторонних производителей. В этом случае у пользователей имеется гораздо больше возможностей по выбору тех или иных накопителей, поскольку листы совместимости СХД содержат в себе большое количество позиций.

Добрый день, меня зовут Павел Поляков, я Principal Engineer в каршеринг компании SHARE NOW, в Гамбурге в 🇩🇪 Германии. А еще я автор Telegram-канала Хороший разработчик знает, где рассказываю обо всем, что должен знать хороший разработчик.

Сегодня хочу поговорить о том стоит ли хранить данные в JSONB полях в PostgreSQL. Как это влияет на производительность?

Удаленные площадки, как правило, ограничены в пространстве, и часто, когда необходимо обеспечить максимальную доступность для критически важных служб, ограниченное пространство этого не позволяет. Для бизнеса, который зависит от этих служб, перебои в их работе могут быть очень дорогостоящими, а в более критичных случаях, приводящими к отключению служб, которые контролируют системы безопасности, защищающие жизнь людей.

Одна из известных компаний, применяющих HPE SimpliVity, купила решение как раз для последнего сценария. Развертывание осуществляется на морских нефтяных вышках, на которых размещены сделанные на заказ системы мониторинга безопасности. Эти системы очень важны для работы в сфере нефтяной промышленности, так как они предназначены для обеспечения безопасности людей. Поскольку ближайшие ИТ-ресурсы находятся довольно далеко, в случае отказа оборудования требуют доставки компонентов и технического персонала на вертолете, что ведет за собой дополнительные затраты и риск для бизнеса и жизни людей. Крайне важно, чтобы решение по хранению данных обладало высокой отказоустойчивостью на нескольких уровнях и занимало минимально возможную площадь. Это одна из основных причин, по которой компании выбирают HPE SimpliVity.

HPE SimpliVity уделяет основное внимание обеспечению высокой отказоустойчивости при минимальной площади, занимаемой узлом. Архитектура RAIN + RAID (обеспечивает доступности 99.999%.

Постановка задачи

Ранее компания Seagate представила один из первых NVMe SSD с поддержкой интерфейса PCIe 4.0, а именно FireCuda 520. Он показал достойный уровень производительности в синтетических тестах, и теперь Seagate представила преемника FireCuda 530. Посмотрим, как новый SSD покажет себя. Сможем ли мы назвать его идеальным накопителем для энтузиастов? Предлагаем ознакомиться с результатами тестов, которые мы проводили совместно с лабораторией Hardwareluxx.

7 октября мы провели второй митап о нюансах работы с большими объёмами данных. Под катом видео докладов наших разработчиков и приглашенного эксперта Microsoft Data Platform. Кейсы будут полезны тем, кто администрирует и разрабатывает DWH, создает аналитические запросы и работает c Microsoft SQL Server.

На дворе 2021 год и рассказы про безопасные гавани, сетевые нейтралитеты и "ничего личного, просто бизнес" уже мало кого впечатляют. Информационные посредники, поисковые сервисы и т.п.наперегонки бросились занимать позиции в разных конфликтах.

Многие рассуждают о том, какое будущее нас ждёт, но меня, как историка, больше беспокоит вопрос о том, какое же нас ждёт ПРОШЛОЕ. Причём, в основе этого беспокойства лежат общепринятые плюсы цифровых технологий: быстрый доступ к контенту из любой точки мира, и простота улучшения и обновления любых материалов.

Как и всегда, сохраняя обратную совместимость мы увеличили скорость восстановления в 20 раз! Благодаря этому мы сделали внешнее восстановление очень надежным и быстрым процессом, на который вы можете рассчитывать. О том, как этого удалось добиться, рассказывает Product Owner & Solution Advisor Zextras Luca Arcara.

В середине августа мы приняли участие в международной научной конференции VLDB (Very Large Data Bases), и хотим поделиться актуальными идеями о работе с базами данных.

Если вы специалист по базам данных, или так или иначе связаны с ними, то приглашаем к чтению.

1. Масштабируемое неограниченно (главная особенность — количество «холодных» данных будет постоянно нелинейно расти).
2. Нечувствительное к потере частей, то есть катастрофоустойчивое и устойчивое к поломкам. Почти как хранилище на космический корабль.
3. Способность экономически оправданно эволюционировать вместе с частями информационной системы, то есть в идеале — замена железа и обновление софта, а не переход к другим архитектурам и переносы в другие форматы хранения.
4. Единообразный доступ к данным независимо от платформы исполнения.

Иногда мне попадаются статьи о будущем технологий, в которых это будущее выглядит ясно и непротиворечиво.

Недавно это была статья восход дата инжиниринга от Maxime Beauchemin – инженера данных из Airbnb и создателя фреймворка Apache Airflow. В Astronomer Apache Airflow - основа технического стека: наши интеграционные потоки построены как пайплайны данных на направленных ациклических графов (DAG) в Airflow. Такие статьи как эта позволяют понять, почему именно сейчас лучшее время для компаний, таких как Astronomer.

После прочтения статьи я связался с Максом и попросил его об интервью, и к моей огромной радости, он согласился и дал полные ответы на вопросы про Apache Airflow и будущее дата инжиниринга.

Данные. Они повсюду и их становится только больше. За последние 5-10 лет data science привлекла множество новичков, пытающихся ощутить вкус этого запретного плода.

Но как сегодня выглядит ситуация с наймом в data science?

Вот краткое изложение статьи в двух предложениях.

TLDR: в компаниях на 70% больше вакансий на должности дата-инженеров, чем на должности дата-саентистов. Так как мы обучаем новое поколение практиков в сфере обработки данных и машинного обучения, давайте сделаем больший упор на инженерные навыки.

Так как моя работа заключается в разработке обучающей платформы для профессионалов в области данных, я много думаю о том, как эволюционирует рынок вакансий, связанных с данными (машинное обучение и data science).

Общаясь с десятками перспективных новичков в сфере данных, в том числе и со студентами лучших вузов мира, я увидел серьёзное недопонимание того, какие навыки являются наиболее важными, помогают выделиться из толпы и подготовиться к карьере.

Дата-саентист может работать в любом сегменте следующих сфер: моделирование машинного обучения, визуализация, очистка и обработка данных (например, преобразование данных для SQL), проектирование и развёртывание на производстве.

С чего вообще начинать рекомендации курса обучения для новичков?

Данные говорят громче слов. Поэтому я решил провести анализ должностей в сфере данных, на которые есть вакансии у компаний, выходивших из Y-Combinator с 2012 года. Вопросы, которыми я руководствовался в своих исследованиях:

Источники бесперебойного питания (ИБП) и модули распределения питания в стойке (Enclosure Power Distribution Units — ePDU) предназначены для защиты оборудования организаций от аварий и поломок, связанных с проблемами электроснабжения. В случае неисправности этих приборов в период действия гарантии ремонт и замена не представляют трудности и практически полностью ложатся на плечи производителя или его представителей.

Eaton предлагает новую услугу — возможность продления гарантийного срока обслуживания ИБП и дополнительного оборудования на 1 или 3 года. Максимальный общий срок основной и дополнительной гарантии при этом достигает 7 лет с момента покупки.

В отделе продаж можно услышать аббревиатуру ABC: Always Be Closing, что означает заключение сделки с покупателем. Последнее десятилетие породило еще одну аббревиатуру ABCD: Always Be Collecting Data. 

Мы используем Google для почты, карт, фотографий, хранилищ, видео и многого другого. Мы используем Twitter, чтобы читать поток сознания одного президента. Мы используем Facebook для обмена сообщениями и… ну, почти все. Но наши родители пользуются им. Мы используем TikTok… Понятия не имею, зачем. 

На самом деле, оказывается, что большинство из вышеперечисленного бесполезно… Ничего подобного, суть в том, что мы их используем. Мы их используем, и они бесплатны. В экономике XXI века, если вы не платите за товар, вы являетесь товаром. 

Итак, короче говоря, я хотел выяснить, насколько корпорация Alphabet, владелец Google, обо мне знает. Крошечная доля, я посмотрел на историю геолокации. Я никогда не отключал службы определения местоположения, потому что ценил комфорт выше конфиденциальности. Плохая идея.

В наше время всё больше заказчиков задумываются о строительстве различных DR-решений для повышения отказоустойчивости их служб и сервисов. Это хорошая тенденция, и различных продуктов для решения этой задачи большое количество. Их условно можно разделить на несколько групп в зависимости от того, на каком уровне инфраструктуры они работают. Какие-то - на уровне приложений, другие - на уровне виртуальных машин, а какие-то - могут работать на уровне СХД. Многие из продуктов удачно сочетают возможность работы на разных уровнях. Этот обзор посвящен Huawei OceanStor BCManager, который позволяет управлять DR-решениями, используя при этом возможности систем хранения Huawei.

Эксперты облачного направления OnCloud компании «Онланта» постоянно совершенствуют сервисы для наших заказчиков. Не так давно в нашей публичной части облака появились новые массивы Huawei Dorado V6, о которых я рассказывал в предыдущей статье «Обзор и тестирование Huawei Dorado 5000V6». Мы решили рассмотреть, какие возможности для гранулярной репликации виртуальных машин предлагает OceanStor BCManager, который работает в связке с системами хранения Huawei.

Рассматриваем возможные решения, считаем производительность и прикидываем, как правильно настроить систему.

Этим летом вышел новый релиз платформы данных InterSystems IRIS Data Platform 2021.1.

Основные «темы» в этом релизе связаны с расширением доступности платформы для разработчиков на различных технологиях и новыми возможностями по анализу данных.

Расширяется выбор доступных языков разработки, как серверных, так и клиентских, а также новые компоненты для аналитики больших объемов данных. Но, обо всём по порядку.

Задача

В Uber применяется несколько технологий хранения информации, причем, хранение бизнес-данных зависит от того, какова модель приложения, в которой они применяются. Одна из таких технологий называется Schemaless и обеспечивает моделирование взаимосвязанных записей с представлением в виде одной строки из множества столбцов, а также версионирование для каждого столбца отдельно.

Schemaless в ходу уже пару лет, и там накапливаются данные Uber. Притом, что Uber консолидирует все практические кейсы в Docstore, Schemaless остается источником истины для различных клиентских конвейеров задач, тех, что существуют уже давно. Schemaless как таковая использует быструю (но дорогую) базовую технологию хранения данных, которая позволяет обходиться задержкой порядка нескольких миллисекунд при высоком показателе QPS (запросы в секунду). Кроме того, Schemaless развертывает для каждого региона несколько реплик, чтобы обеспечить сохранность и доступность данных при различных моделях отказов.

Поскольку Schemaless – дорогостоящее хранилище, а данных в нем накапливается все больше, она превратилась в ключевую статью расходов и поэтому требует внимания. Чтобы разобраться в этой ситуации, были проведены замеры, помогающие лучше понять паттерны обращения к данным. Было обнаружено, что в течение некоторого периода времени обращения к данным происходили часто, а после этого – не столь часто. Точная длительность такого периода варьируется от кейса к кейсу, но при любом запросе старые данные все равно должны безусловно предоставляться по запросу.