Русский
Русский
English
Статистика
Реклама

Система хранения данных

Dell EMC PowerStore коротко о нашей новейшей СХД корпоративного класса

07.07.2020 12:09:02 | Автор: admin
Совсем недавно наша компания представила новый продукт Dell EMC PowerStore. Это универсальная платформа с ориентированным на производительность дизайном, обеспечивающим многомерное масштабирование, постоянное сокращение данных (компрессия и дедупликация) и поддержку носителей нового поколения. PowerStore использует микросервисную архитектуру, передовые технологии хранения и интегрированное машинное обучение.

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




Преимущества новых систем хранения:


  • Современная микросервисная архитектура. Система базируется на контейнерной архитектуре, когда отдельные компоненты ОС выделяются в отдельные микросервисы. Микросервисная архитектура обеспечивает переносимость функций и быстрое внедрение нового функционала. Такая архитектура позволяет быстро адаптировать ранее написанный функционал на новую платформу т.к. микросервисы автономны и не влияют друг на друга, микросервисная архитектура позволяет обеспечить более высокую надежность работы всей системы по сравнению с монолитной архитектурой. Например, обновление микрокода часто затрагивает только отдельные модули, а не всю систему (или ее ядро) и, как следствие, проходит более гладко.
  • Использование передовых технологий хранения данных. Поддержка памяти Storage Class Memory (SCM) Intel Optane и NVMe All-Flash позволяет устранить узкие места в системе и существенно увеличить производительности и сократить время отклика системы.
  • Непрерывное сокращение объема данных на лету. Всегда включенные механизмы компрессии и дедупликации данных, позволяют уменьшить объёмы, занимаемые данными внутри системы и оптимизировать хранение. Это позволяет сократить затраты на приобретение и эксплуатацию системы и повысить эффективность работы.
  • Гибкая масштабируемость решения. Архитектура решений Dell EMC PowerStore поддерживает как вертикальное, так и горизонтальное масштабирование, благодаря чему вы можете эффективно планировать расширение инфраструктуры наращивая ёмкость или вычислительные ресурсы независимо друг от друга.
  • Встроенные механизмы защиты данных. Системы PowerStore обладают широким спектром встроенных механизмов защиты данных от мгновенных снимков и репликации до шифрования данных и интеграции с антивирусными программами. Система также широко интегрируется с внешними решениями, как от Dell Technologies, так и от других производителей.
  • AppsON. Благодаря интегрированному в систему гипервизору VMware ESX заказчики могут запускать пользовательские виртуальные машины непосредственно внутри системы.
  • Интеграция с VMware. PowerStore предназначен для глубокой интеграции с VMware vSphere. Интеграция включает поддержку VAAI и VASA, уведомления о событиях, управление снимками, vVols, а также обнаружение и мониторинг виртуальных машин в PowerStore Manager.
  • Унифицированный доступ к данным. PowerStore обеспечивает хранение данных приложений в различных форматах, от физических и виртуальных томов до контейнеров и традиционных файлов благодаря возможности работы по множеству протоколов блочных, файловых и VMware vSphere Virtual Volumes (vVols). Эта способность обеспечивает высокую гибкость данной системы и позволяет ИТ-отделам упростить и консолидировать инфраструктуру.
  • Простой, современный интерфейс управления. Интерфейс управления системой PowerStore Manager разрабатывался на основе требований наших заказчиков к простоте управления системой. Это web-интерфейс, запускающийся на контроллерах системы PowerStore. Доступен по протоколу HTML5 и не требует установки дополнительных плагинов.
  • Программируемая инфраструктура. Упрощает разработку приложений и сокращает сроки их развёртывания с нескольких дней до нескольких секунд благодаря интеграции с VMware и поддержке ведущих сред управления и оркестрации, включая Kubernetes, Ansible и VMware vRealize Orchestrator.
  • Интеллектуальная автоматизация. Встроенные алгоритмы машинного обучения автоматизируют трудоемкие рабочие процессы: такие как начальное планирование и размещение томов, миграция данных, балансирование нагрузки и устранение проблем
  • Аналитическая информация об инфраструктуре. Программное обеспечение Dell EMC CloudIQ для мониторинга и анализа хранилищ сочетает в себе преимущества машинного обучения и человеческого интеллекта для анализа производительности и ёмкости систем в режиме реального времени, а также хранения исторических данных, чтобы получить единое представление об инфраструктуре Dell EMC. Компания Dell Technologies планирует интегрировать CloudIQ с полным портфелем своих решений для еще более глубокой аналитики.

Платформа представлена двумя типами систем:

  1. PowerStore T выступает в качестве классической СХД.
  2. PowerStore X выступает как гиперконвергентное решение, позволяющее запускать виртуальные машины заказчика, совмещенное с выделенной, классической СХД.

Благодаря интегрированным возможностям VMware ESXi, модели PowerStore X предоставляют возможность размещать приложения с интенсивным вводом-выводом непосредственно внутри системы PowerStore. При использовании встроенных механизмов VMware (vMotion) обеспечивается возможность перемещения приложений между системой хранения PowerStore и внешними решениями. Встроенный гипервизор VMware ESXi запускает приложения заказчиков вместе с операционной системой PowerStore в виде виртуальных машин VMware. Этот инновационный дизайн идеально подходит для приложений с большим объёмом хранилища, обеспечивая дополнительные вычислительные и высокопроизводительные хранилища для существующей среды или любого сценария, в котором плотность, производительность и доступность являются основными факторами.

Явными примерами, когда AppsON идеально решает задачи наших заказчиков, являются:

  • Выделенная инфраструктура для одного приложения. Например, для базы данных, которой требуется выделенный сервер, СХД, а также какая-то дополнительная обвязка, например, для резервного копирования. В этом случае вы можете купить одну единственную систему PowerStore которая закроет все задачи, т.к. само приложение и сервер резервного копирования можно развернуть в рамках узла PowerStore без необходимости в дополнительной инфраструктуре.
  • ROBO (удаленные филиалы и офисы). Многие заказчики сталкиваются с задачей в каком-то виде реплицировать инфраструктуру основного ЦОД на периферию, чтобы обеспечить работу удаленных филиалов своих компаний. Раньше приходилось для этого покупать отдельные сервера, СХД, коммутаторы для их соединения, а также ломать голову на тему того, как защитить инфраструктуру и самое главное данные. Мы предлагаем, как и в предыдущем примере, пойти по пути консолидации инфраструктуры в рамках одного решения Dell EMC PowerStore. Вы получите полностью готовую инфраструктуру в рамках шасси в 2U, состоящую из пары отказоустойчивых серверов, соединенных с высокоскоростной СХД.

Оба типа систем представлены в виде линейки моделей с разными техническими характеристиками:



Важной особенностью систем PowerStore является возможность модернизации уже купленной системы в будущем. Вот как это можно сделать.

  • Традиционный апгрейд младших моделей до старших позволяет избегать лишних инвестиций на этапе закупки системы: нет необходимости сразу покупать дорогое решение, потенциал которого в полной мере раскроется только через несколько лет. Процедура апгрейда это штатная замена одних контроллеров на другие, она выполняется без остановки доступа к данным.
  • Благодаря правильно выбранной архитектуре систему можно будет модернизировать до нового поколения, что позволит поддерживать её в актуальном состоянии и увеличить срок эксплуатации.
  • Есть способ заложить возможность модернизации системы на этапе закупки. Для этого существует специальная опция Anytime Upgrade, которая позволяет либо актуализировать систему за счёт модернизации её до нового поколения, либо модернизировать систему до более старшей и более производительной модели.

Лицензирование


Dell EMC PowerStore лицензируется по модели Всё включено. Весь доступный функционал заказчик получает вместе с системой без дополнительных инвестиций. По мере выхода нового функционала массива он также станет доступен заказчикам после модернизации микрокода.

Оптимизация физического объема данных


Dell EMC PowerStore включает несколько методов повышения эффективности хранения данных за счёт сокращения используемого данными физического объёма:

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

Динамические пулы


Dell EMC PowerStore оснащается системой RAID на основе экстентов для обработки сбоев дисков. Большое количество элементов RAID представляет собой единое логическое пространство, формирующее пул, с которым работает конечный пользователь.

Архитектура динамический RAID обеспечивает 5 основных преимуществ:

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



High availability


СХД Dell EMC PowerStore полностью защищена от сбоев и включает ряд методов обеспечения высокой доступности. Данные методы предназначены для противостояния сбоям компонентов в самой системе и во внешней инфраструктуре, таких как перебои в сети или отключение питания. В случае сбоя отдельного компонента система хранения продолжает обслуживать данные. Система также может противостоять нескольким сбоям, если они происходят в отдельных наборах компонентов. После того, как администратор получит уведомление о сбое, он может заказать и заменить неисправный компонент без последствий.

NVMe SCM


Носители хранения данных SCM (Storage Class Memory) это высокопроизводительные энергонезависимые накопители, созданные на основе технологии Intel Optane. Накопители NVMe SCM имеют меньшую задержку и улучшенную производительность по сравнению с другими SSD. NVMe это протокол, который позволяет осуществлять доступ напрямую через шину PCIe. NVMe разработан с учетом низкой задержки высокопроизводительных носителей. Накопители NVMe SCM служат уровнем хранения для PowerStore, используются для пользовательских данных или метаданных. На данный момент доступны объёмы в 375 и 750 ГБ.

NVMе NVRAM


NVMe NVRAM это высокопроизводительные накопители, используемые для улучшения системы кэширования PowerStore. Они доступны с обоих контроллеров системы и позволяют системе легко кэшировать входящие записи. Накопители работают на скоростях DRAM по PCIe, обеспечивая исключительную производительность. Их конструкция позволяет им функционировать как энергонезависимые носители, и PowerStore может быстро сохранять входящие записи и подтверждать операции хосту без оповещения второго контроллера. Хранилища данных устанавливаются парами для зеркалирования данных между собой на случай аппаратного сбоя.

Данный подход позволил существенным образом ускорить работу системы хранения данных:

  • во-первых, контроллерам не надо тратить такты своих ЦП на синхронизацию данных кэш-памяти друг с другом;
  • во-вторых, вся запись на накопители происходит блоком в 2 МБ, т.к. система копит этот объем данных перед тем, как записать данные на диски. Таким образом, запись из случайной превратилась в последовательную. Как вы сами понимаете, такой подход существенным образом снижает нагрузку на хранилища данных и сами контроллеры.



Кластеризация


Каждое устройство Dell EMC PowerStore развёртывается в виде одного из узлов кластера, т.к. кластеризация является частью архитектуры данной платформы. На текущий момент в единый кластер можно объединить не более четырех узлов PowerStore. При развертывании кластера с несколькими устройствами эту задачу можно выполнить во время процесса начальной настройки или в будущем добавить устройства в уже существующий кластер. Кластер PowerStore можно уменьшить, удалив устройства из существующего кластера, фактически разделив один большой кластер на два более маленьких.



Кластеризация устройств Dell EMC PowerStore даёт много преимуществ.

  • Scale-Out масштабирование для увеличения количества ресурсов системы за счёт добавления дополнительных вычислительных узлов процессора, памяти, ёмкости и интерфейсов подключения к хостам.
  • Независимое увеличение ресурсов хранения или вычислительных ресурсов.
  • Централизованное управление много узлового кластера.
  • Автоматическая балансировка нагрузки между узлами кластера.
  • Повышенная надёжность и отказоустойчивость.

PowerStore Manager


PowerStore Manager предоставляет администраторам СХД простой и интуитивно понятный интерфейс для настройки и управления кластером. Он основан на HTML5, не требует установки дополнительного программного обеспечения на клиенте и помогает выполнить следующие задачи:

  • Начальная настройка нового узла PowerStore.
  • Добавление или удаление узлов из существующего кластера.
  • Управление ресурсами кластера.

мкость кластера является агрегацией ёмкостей отдельных узлов кластера. Статистика по экономии доступна для всего кластера целиком.

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

Вместо заключения


На этом краткий рассказ о Dell EMC PowerStore мы завершаем. В данной статье мы разобрали основные моменты, относящиеся к технике и экономике, которые надо понимать при планировании закупки систем PowerStore от кластеризации до лицензирования и планирования будущих апгрейдов. Много технических моментов осталось за кадром, и мы с удовольствием вам про них расскажем либо в следующих статьях, либо при общении со специалистами отдела продаж.

В заключении статьи хочется отметить, что первые проданные системы уже развернуты в ЦОД-ах наших заказчиков, дистрибьюторы и партнеры закупили демо-системы и готовы показывать их вам. Если система вызывала у вас интерес смело обращайтесь к нашим партнёрам и представителям для проработки ваших проектов.
Подробнее..

Эльбрус VS Intel. Сравниваем производительность систем хранения Аэродиск Восток и Engine

28.09.2020 06:06:32 | Автор: admin


Всем привет. Мы продолжаем знакомить вас с системой хранения данных Аэродиск ВОСТОК, выполненной на базе российского процессора Эльбрус 8C.


В этой статье мы (как и обещали) детально разберем одну из популярнейших и интереснейших тем, связанной с Эльбрусами, а именно производительность. На тему производительности Эльбруса есть достаточно много спекуляций, причем абсолютно полярных. Пессимисты говорят, что производительность Эльбруса сейчас никакая, и чтобы догнать топовых производителей потребуются десятилетия (т.е. в условиях нынешней реальности никогда). С другой стороны, оптимисты говорят, что уже сейчас Эльбрус 8C показывает хорошие результаты, а в ближайшие пару лет с выходом новых версий процессоров (Эльбрус 16С и 32С) мы сможем догнать и перегнать ведущих мировых производителей процессоров.


Мы в Аэродиске люди практичные, поэтому пошли самым простым и понятным (для нас) путем: протестировать, зафиксировать результаты и только потом делать выводы. В итоге мы провели довольно большое количество тестов и обнаружили ряд особенностей работы Эльбруса 8С архитектуры e2k (в том числе, и приятных) и, конечно же, сравнили это с аналогичными СХД на процессорах Intel Xeon архитектуры amd64.


Кстати, более подробно о тестах, результатах и о будущем развитии СХД на Эльбрусах мы поговорим на нашем очередном вебинаре "ОколоИТ" 15.10.2020 в 15 00. Зарегистрироваться можно по ссылке ниже.


РЕГИСТРАЦИЯ НА ВЕБИНАР


Тестовый стенд


Мы создали два стенда. Оба стенда состоят из сервера с Linux-ом, подключенного через 16G FC-коммутаторы к двум котроллерам СХД, в которой установлено 12 SAS SSD 960 ГБ дисков (11,5 ТБ сырой емкости или 5,7 ТБ полезной емкости, если используем RAID-10).


Схематично стенд выглядит следующим образом.



Стенд 1 e2k (Эльбрус)


Конфигурация оборудования следующая:


  • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
  • Коммутатор FC 16 G 2 шт.
  • СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Стенд 2 amd64 (Intel)


Для сравнения с аналогичной конфигурации на e2k использовалась похожая конфигурация СХД с похожим процессором по характеристикам на amd64:


  • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
  • Коммутатор FC 16 G 2 шт.
  • СХД Aerodisk Engine N2 (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 32 GB DDR4, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Важное замечание: используемые в тесте процессоры Эльбрус 8С поддерживают оперативную память только DDR3, это конечно плохо, но не долго. Эльбрус 8СВ (в наличие его у нас пока нет, но скоро будет) поддерживает DDR4.


Методика тестирования


Для генерации нагрузки мы использовали популярную и проверенную временем программу Flexible IO (FIO).


Обе СХД сконфигурированы согласно нашим же рекомендациям по настройке, исходя из требований к высокой производительности на блочном доступе, поэтому используем дисковые пулы DDP (Dynamic Disk Pool). Чтобы не искажать результаты тестирования, на обеих СХД отключаем, компрессию, дедупликацию и RAM-кэш.


Созданы 8 D-LUN-ов в RAID-10 по 500 ГБ, каждый, суммарный полезный объём составляет 4 ТБ (т.е. примерно 70% от возможной полезной емкости данной конфигурации).


Выполняться будут основные и популярные сценарии использования СХД, в частности:


первые два теста эмулируют работу транзакционной СУБД. В этой группе тестов нам интересны IOPS-ы и задержка.


1) Случайное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random


2) Случайная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random


вторые два теста эмулируют работу аналитической части СУБД. В этой группе тестов нам также интересны IOPS-ы и задержка.


3) Последовательное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


4) Последовательная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


третья группа тестов эмулирует работу потокового чтения (пример онлайн трансляции, восстановление резервных копий) и потоковой записи (пример видеонаблюдение, запись резервных копий). В этой группе тестов нам уже интересны не IOPS-ы, а MB/s и также задержка.


5) Последовательное чтение большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


6) Последовательная запись большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


Каждый тест будет длиться один час без учета времени прогрева массива в 7 минут.


Результаты тестов


Результаты тестов сведены в две таблицы.


Эльбрус 8С (СХД Аэродиск Восток 2-Э12)



Intel Xeon E5-2603 v4 (СХД Аэродиск Engine N2)



Результаты получились крайне интересные. В обоих случаях мы хорошо утилизировали процессорные мощности СХД (70-90% утилизации), и при таком раскладе явно бросаются в глаза плюсы и минусы обоих процессоров.


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


Если говорить о случайной нагрузке небольшими блоками, то:


  • с точки зрения случайного чтения Intel, безусловно, впереди Эльбруса, разница в 2 раза;
  • с точки зрения случайной записи однозначно ничья, оба процессора показали примерно равные и достойные результаты.

В последовательной нагрузке небольшими блоками картина другая:


  • и при чтении, и при записи Intel существенно (в 2 раза) опережает Эльбрус. При этом, если у Эльбруса показатель IOPS ниже чем у Intel, но выглядит достойно (200-300 тысяч), то с задержками явная проблема (они в три раза выше чем у Intel). Вывод, текущая версия Эльбруса 8С очень не любит последовательные нагрузки небольшими блоками. Явно есть над чем работать.

А вот в последовательной нагрузке большими блоками картина прямо противоположная:


  • оба процессора показали примерно равный результат в MB/s, но есть одно НО. Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину. Это серьезное преимущество Эльбруса (и архитектуры e2k в целом) перед Intel (и, соответственно, архитектуры amd64). Будем надеяться, что этот успех получит дальнейшее развитие.

Есть ещё одна интересная особенность Эльбруса, на которую внимательный читатель может обратить внимание, посмотрев на таблицу. Если взглянуть на разницу показателей чтения и записи у Intel, то во всех тестах чтение опережает запись в среднем примерно на 50%+. Это норма, к которой все (в том числе и мы) привыкли. Если посмотреть на Эльбрус, то показатели записи значительно ближе к показателям чтения, чтение опережает запись, как правило, на 10 30%, не более.


О чем это говорит? О том, что Эльбрус очень любит запись, а это, в свою очередь, говорит о том, что этот процессор будет очень полезен в задачах, где запись явно преобладает над чтением (кто сказал закон Яровой?), что также является несомненным преимуществом архитектуры e2k, и это преимущество нужно развивать.


Выводы и ближайшее будущее


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


Intel сильно превзошел Эльбрус в случайном чтении небольшими блоками, а также в последовательном чтении и записи небольшими блоками.


При случайной записи небольшими блоками оба процессора показывают равные результаты.


По показателям задержки Эльбрус выглядит значительно лучше Intel-а в потоковой нагрузке, т.е. в последовательном чтении и записи большими блоками.


Кроме того, Эльбрус в отличии от Intel, одинаково хорошо справляется как с нагрузками чтения, так и с нагрузками записи, в то время как у Intel чтение всегда значительно лучше записи.
Исходя из полученных результатов можно сделать вывод о применимости систем хранения данных Аэродиск Восток на процессоре Эльбрус 8С в следующих задачах:


  • информационные системы с преобладанием операций записи;
  • файловый доступ;
  • онлайн-трансляции;
  • видеонаблюдение;
  • резервное копирование;
  • медиа-контент.

Коллективу МЦСТ есть ещё над чем работать, но результат их работы виден уже сейчас, что, конечно, не может не радовать.


Данные тесты проводились на ядре Linux для e2k версии 4.19, на текущий момент в бета-тестах (в МЦСТ, в Базальт СПО, а также у нас, в Аэродиске) находится ядро Linux 5.4-e2k, в котором, кроме всего прочего, серьезно переработан планировщик и много оптимизаций под скоростные твердотельные накопители. Также специально для ядер ветки 5.х.х АО МЦСТ выпускает новый компилятор LCC версии 1.25. По предварительным результатам, на том же процессоре Эльбрус 8С, собранное новым компилятором новое же ядро, окружение ядра, системные утилиты и библиотеки и, собственно, ПО Аэродиск ВОСТОК позволит получить ещё более значительный прирост производительности. И это без замены оборудования на том же процессоре и с теми же частотами.


Мы ожидаем выхода версии Аэродиск ВОСТОК на базе ядра 5.4 ближе к концу года, и как только работа над новой версией будет завершена, мы обновим результаты тестирования и также опубликуем их здесь.


Если теперь вернуться к началу статьи и ответить на вопрос, кто же прав: пессимисты, которые говорят, что Эльбрус никакой и никогда не догонит ведущих производителей процессоров, или все-таки оптимисты, которые говорят, что уже почти догнали и скоро перегоним? Если исходить не из стереотипов и религиозных предубеждений, а из реальных тестов, то, однозначно, правы оптимисты.


Эльбрус уже сейчас показывает хорошие результаты, если сравнивать его с процессорами amd64 среднего уровня. До верхних в линейке моделей серверных процессоров Intel или AMD 8-ке Эльбруса, конечно, далеко, но она туда и не целилась, для этого будут выпущены процессоры 16С и 32С. Вот тогда и поговорим.


Мы понимаем, что после этой статьи вопросов про Эльбрус станет ещё больше, поэтому мы решили организовать ещё один онлайн-вебинар ОколоИТ, чтобы в прямом эфире на эти вопросы дать ответы.


В этот раз у нас в гостях будет заместитель генерального директора компании МЦСТ, Константин Трушкин. Записаться на вебинар можно по ссылке ниже.


РЕГИСТРАЦИЯ НА ВЕБИНАР


Всем спасибо, как обычно ждем конструктивной критики и интересных вопросов.

Подробнее..

Функция AppsON в Dell EMC PowerStore запускаем приложения прямо на массиве

10.03.2021 10:18:02 | Автор: admin
Мы продолжаем цикл статей о нашей новой линейке систем хранения данных PowerStore. Этот материал посвящен уникальному функционалу, позволяющему запускать на борту системы пользовательские приложения AppsON.

Для начала вкратце напомним основные особенности PowerStore. Система имеет микроконтейнерную архитектуру. Разные компоненты ОС выделяются в отдельные, изолированные функциональные элементы (контейнеры). Это обеспечивает простую переносимость функций, стандартизацию и быстрое внедрение нового функционала, а также максимальную гибкость развёртывания.



Как вы наверняка помните из предыдущей статьи, платформа PowerStore представлена двумя типами систем:

  • PowerStore T традиционная внешняя СХД, которая подключается к серверам для обеспечения потребностей в хранении информации.
  • PowerStore X гиперконвергентное решение на базе гипервизора VMware ESXi, который стал признанным фундаментом для большинства HCI решений. Забегая вперед, отметим, что гипервизор ESXi загружается на каждый из двух контроллеров, работающих в режиме active-active, а PowerStore OS работает как виртуальная машина на каждом узле.



Важно понимать, что после выбора типа системы PowerStore T или X, пользователи не cмогут переключаться между ними в силу архитектурных особенностей, которые мы и рассмотрим ниже.

Размещение гипервизора на борту PowerStore X позволяет одновременно запускать приложения пользователя и функционально организовать внешнюю дисковую систему хранения данных со всем привычным нам функционалом. Этот подход получил название AppsON.

Независимо от того, какую модель PowerStore выберет заказчик, он получает в части СХД одни и те же возможности, службы по работе с данными и полную отказоустойчивость.

Виртуализация функционала СХД обеспечивает не только дополнительную изоляцию и абстракцию операционной системы, но и предполагает в недалёком будущем новые варианты развёртывания платформы, в которых ПО хранения данных может быть развёрнуто на серверах заказчиков либо в облаке, причём без привязки к специально разработанным для этого аппаратным устройствам. С таким подходом мы уже сталкивались на примере Unity VSA (Unity Virtual Storage Appliance), когда заказчик на своем сервере мог развернуть полнофункциональную систему хранения данных.



В PowerStore X, как было отмечено выше, ОС запускается внутри виртуальной машины. Каждый физический узел содержит один экземпляр виртуальной машины с PowerStore OS Controller VM. Этот вариант ничем не отличается от PowerStore OS, работающей непосредственно на физических узлах PowerStore T, но в данном случае 50% аппаратных ресурсов зарезервированы для этой виртуальной машины. Остальные ресурсы доступны для клиентских виртуальных машин.

Для минимизации влияния на производительность СХД совместно с компанией VMware была разработана специальная технология проброса ключевых аппаратных ресурсов PowerStore (диски, чип сжатия и т.д.) напрямую в виртуальную машину PowerStore OS Controller VM. На выходе подобный механизм позволил получить сопоставимое время отклика от дисковой подсистемы с моделью PowerStore T.



Идеальным вариантом использования подобного решения являются рабочие нагрузки с интенсивным вводом-выводом (в отличие от нагрузок с интенсивным вычислением): например, базы данных. Ещё одним вариантом является консолидация, когда надо развернуть инфраструктуру, где фактически нет ЦОД или очень мало места. Кроме того, одновременно с запуском виртуальных машин, PowerStore X может выступать в роли внешней СХД и предоставлять ресурсы хранения серверам через FC или ISCSi.

Таким образом, мы получаем новый уровень унификации решения, а термин Unified Storage играет новыми красками.

Тезисно резюмируем вышесказанное перед тем, как идти дальше:

  • ESXi устанавливается непосредственно на каждый из контроллеров PowerStore X.
  • PowerStoreOS работает внутри виртуальной машины на каждом из контроллеров. Эта виртуальная машина называется Controller VM (контроллером виртуальной машины).
  • PowerStore X может предоставлять традиционные ресурсы хранения (такие как SAN/NAS/vVOl) внешним серверам и вместе с тем выполнять приложения пользователя.
  • Независимо от модели X или T, PowerStore разработан с использованием архитектуры Active/Active, оба узла имеют доступ ко всем дискам и ресурсам хранения.
  • Как и многие наши продукты, PowerStoreOS основана на операционной системе Linux, которая обеспечивает весь необходимый программный стек: API функции и точки интеграции, размещает веб-браузер для управления системой.
  • PowerStoreOS реализована в виде контейнеров Docker. Контейнерная реализация упрощает обслуживание и развитие платформы, поскольку новые сервисы (контейнеры) можно легко и быстро добавить, а затем и перевести в оперативный режим. Если контейнер необходимо перезагрузить или изменить, то для этого не нужно останавливать весь стек. Это также обеспечивает больший потенциал для интеграции в портфель продуктов Dell Technologies, поскольку новые функции могут быть легко развёрнуты в среде докеров для PowerStore для использования.
  • В модели PowerStore T 100% системного ЦП и памяти используются PowerStoreOS.
  • В модели PowerStore X 50% ЦП и памяти зарезервированы для PowerStoreOS, что гарантирует наличие ресурсов для служб хранения данных, а остальные 50% доступны для запуска виртуальных машин пользователей.




На рисунке представлено наглядное сравнение двух подходов:

  • Отдельный физический сервер, на котором запущен ESXi, подключается через FC или iSCSI к внешнему массиву хранения (в данном примере Unity). На сервере работает приложение (внутри виртуальной машины), которое получает доступ к ресурсам хранения данных.
  • PowerStore X содержит одновременно вычислительные компоненты и компоненты хранения данных. Два отдельных хоста ESXi (оба контроллера) образуют единый вычислительный кластер. Виртуальная машина Controller VM запускает PowerStoreOS, которая предоставляет доступ к внутреннему хранилищу для любых встроенных приложений или (при необходимости) предоставляет ресурсы хранения для внешних хостов.
  • PowerStore X может предоставлять ресурсы хранения внешним потребителям так же, как это делает обычная СХД.
  • PowerStore X может выполнять приложения пользователей и обеспечивать их потребности в ресурсах хранения через внутренний интерконнект.
  • PowerStore X может быть легко интегрирована в вашу виртуальную ферму. Одно из преимуществ, которое вскоре станет доступно, vMotion для бесшовной миграции ВМ между вашими системами.




Сценарии использования


Консолидация рабочих нагрузок


Очевидным сценарием использования возможностей функционала AppsON является консолидация рабочих нагрузок в рамках одной PowerStore X. Практика внедрения и использования систем PowerStore показала востребованность такого подхода, что подтверждается статистикой продаж. Нашим заказчикам пришлась по вкусу возможность иметь одну систему взамен комплекса различных устройств сервер, SAN-коммутаторы, СХД. Для бизнеса малого и среднего размера, а также для задач не требовательных к большому объему оперативной памяти, такой подход оказался экономически и технически интересным.

Удалённые филиалы (ROBO)


Интересный сценарий применения PowerStore X размещение системы в удалённых филиалах, где не требуется мощная инфраструктура, используются типовые офисные приложения, а технический персонал состоит из одного или двух администраторов-многостаночников. В такой ситуации минимизация нагрузки на сотрудников и упрощение применяемых решений один из важнейших критериев при выборе решения.
При таком подходе компактный форм-фактор 2U, простота развёртывания, гибкая архитектура, способность поддерживать несколько типов данных, централизованное управление и расширенная репликация в основные центры обработки данных делают PowerStore идеальным решением для периферии. Филиалы компаний и магазины розничной торговли, распределительные центры и склады, поликлиники и больницы, где пространство и ресурсы ограничены и где нет узкоспециализированных специалистов, смогут воспользоваться преимуществами простой системы, способной заменить собой целый комплекс различного оборудования и программного обеспечения.

Гиперконвергенция


Безусловно PowerStore также можно развернуть и в основном центре обработки данных. Благодаря интеграции с VMware, IT-специалисты могут легко и эффективно балансировать рабочую нагрузку в наиболее эффективную для нее среду на основе потребностей приложений и доступности ресурсов.

Управление кластером PowerStore в сочетании с инструментами VMware, включая vMotion, обеспечивает беспрепятственную мобильность приложений между PowerStore и другими узлами VMware. Приложения можно развернуть, например, на серверах, гиперконвергентной инфраструктуре или на самом PowerStore, а затем прозрачно для приложения переносить его между этими системами.

Аналитика


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

Интеграция с vCenter


Многие наши заказчики используют VMware vSphere в качестве основной платформы виртуализации для всех своих IT-систем. Таким заказчикам важно понимать, что PowerStore X глубоко интегрирован с VMware vCenter, а следовательно создание виртуальных машин и управление ими ничем не отличается от управления простым внешним сервером ESXi.

Известно, что для взаимодействия VMware и систем хранения данных используется VSI провайдер (Virtual Storage Integrator), который обеспечивает возможности выделения ресурсов хранения, управления и мониторинга непосредственно из интерфейса клиента VMware vSphere.

Выполнение и контроль стандартных задач администрирования хранения можно выполнять прямо из vSphere, без необходимости запуска интерфейса управления PowerStore. Подключаемый модуль VSI обеспечивает менеджмент системы хранения, позволяя администраторам легко управлять базовым хранилищем, на котором размещаются их виртуальные машины.



PowerStore поддерживает простую настройку виртуальных машин с использованием vVol, а также отображает много полезной информации о них. Таким образом, заказчики, сделавшие выбор в пользу семейства PowerStore, получают систему с простым управлением и мониторингом, нативной интеграцией с продуктами VMware и возможностью размещения виртуальных машин на самом массиве. В статье мы привели несколько практических примеров использования данного функционала, основанных на реальном опыте эксплуатации AppsON у наших заказчиков. Уверены, что со временем их станет ещё больше, и нам будет о чём рассказать в следующих статьях, посвященных системам PowerStore.
Подробнее..

Гиперконвергентная система AERODISK vAIR v2. Часть 1. Система виртуализации АИСТ

14.04.2021 06:04:04 | Автор: admin


Всем привет. Этой статьей мы начинаем знакомить вас с новой версией российской гиперконвергентной системы AERODISK vAIR v2, в частности, со встроенным гипервизором АИСТ, который сейчас получил возможность работать автономно от vAIR, используя внешние СХД.


Изначально мы хотели рассказать о функциональности новой версии vAIR в одной статье, но материала получилось очень много, и мы встали перед выбором: либо сократить материал, либо разбить его на три части. Мы выбрали второй вариант и разбили материал следующим образом:


  • Управление кластером и гипервизор АИСТ
  • Файловая система ARDFS
  • Аппаратные платформы, лицензирование и поддержка

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


Коротко об архитектуре. Основные отличия между первой и второй версией


С момента выхода первой версии в 2019 году архитектура vAIR претерпела ряд изменений. Связано это в первую очередь с борьбой за стабильность, ресурсоемкость и производительность. Однако обо всем по порядку.


Описывать полностью архитектуру с нуля мы рамках этой статьи не будем. Коснёмся лишь тех отличий, которые существуют в настоящий момент между первой и второй версией. Для более глубокого знакомства с изначальной архитектурой vAIR v1 рекомендуем ознакомиться с нашими предыдущими статьями на эту тему:



На уровне большой картинки на данный момент архитектура vAIR v2 выглядит следующим образом:



Ну а теперь переходим к деталям.


Косметические изменения


Незаметное внешнему глазу, но при этом важное и трудоемкое событие произошло в распределенной базе конфигураций (ConfigDB), которая отвечает за одновременное хранение конфигураций всех компонентов решения на всех нодах кластера. Мы полностью её переработали и, соответственно, оптимизировали. В итоге ConfigDB стала значительно стабильнее и минимизировала пожирание бесценных аппаратных ресурсов. Если говорить о цифрах, то за счёт переработки полезную производительность решения удалось увеличить примерно на 30%, что, очевидно, хорошо.


Стандартный блок данных, которым оперирует ARDFS, изменился с 4МБ до 64 МБ. Сделано это было также с целью увеличения производительности ввода-вывода.


Ещё одним маленьким, но приятным бонусом, который получился в результате оптимизации ARDFS и ConfigDB, стало снижение минимальных системных требований по количеству нод в кластере. Первая версия vAIR требовала не менее четырех нод, во второй-же версии начинать можно с трёх нод. Мелочь, но тоже приятно.


АИСТ покинул гнездо


Теперь перейдем к главному архитектурному изменению, с которого и начнем рассказ про подсистему виртуализации. Гипервизор АИСТ, который раньше умел работать только внутри vAIR, научился летать работать автономно и, соответственно, может поставляться отдельным продуктом по отдельной лицензии.


Для справки: и АИСТ, и vAIR как два отдельных продукта прошли всю необходимую экспертизу регуляторов и, соответственно, добавлены во всех необходимые гос. реестры Минцифры и Роспатента, чтобы по-честному считаться российским ПО.


Чтобы не было путаницы, поясним. По факту АИСТ и vAIR не являются разными продуктами. Гипервизор АИСТ это составная и обязательная часть гиперконвергентной системы vAIR, при этом АИСТ может использоваться в качестве самостоятельного решения, а также АИСТ может всегда быть обновлен до полноценного vAIR-а.


Данное архитектурное изменение не только позволяет импортозаместить зарубежную виртуализацию на российских предприятиях, но и открывает ряд крайне полезных сценариев использования vAIR. Разберем их:


Сценарий 1. Просто гиперконвергент


Тут все просто. АИСТ используется как составная часть vAIR и работает с хранилищем ARDFS. Это то, что было в первой версии, и остается сейчас.



Виртуальные машины, сеть и хранилище работают в рамках одной отказоустойчивой аппаратной платформы (3 ноды+).


Сценарий 2. Просто виртуализация


Классическая серверная виртуализация. На локальные диски физических серверов устанавливается АИСТ, к АИСТу пригоняются сторонние СХД по файловым или блочным протоколам, и на базе этих СХД хранятся виртуальные машины.



При этом в этой схеме всегда остается возможность добавить локальных дисков во все физические серверы, объединить их быстрым (от 10 Гбит/сек) интерконнектом и обновить лицензию АИСТа до vAIR, получив в итоге гибридный сценарий (см. ниже).


Сценарий 3. Гибридный сценарий


Самый интересный сценарий. Мы одновременно с гиперконвергентом используем в качестве хранилища виртуальных машин сторонние СХД (например ENGINE или ВОСТОК :-)). Полезным является то, что к любой виртуалке, которая хранится на ARDFS, мы можем легко прицепить дополнительные виртуальные диски с СХД. И наоборот, к любой виртуалке, которая лежит на СХД, мы можем прицепить виртуальные диски с ARDFS. Это открывает очень много возможностей, начиная с задач постепенной и бесшовной миграции инфраструктуры между разными хранилищами, заканчивая полезным использованием старых СХД и серверов хранения, которые и выкинуть жалко, и подарить некому.



В итоге, когда мы пишем vAIR, мы имеем ввиду большой продукт в целом гиперконвергентную систему, которая включает в себя гипервизор АИСТ и файловую систему ARDFS. А если мы пишем АИСТ, то имеем в виду только компонент, который отвечает за серверную виртуализацию и виртуальную сеть. Чтобы внести ещё больше ясности, приводим ниже таблицу с разбивкой функционала по компонентам.



Обзор функционала. Что нового и для чего


Функции управления


Управление системой осуществляется при помощи web-консоли на русском языке (поддерживаются любые браузеры) или командной строки. Важной и полезной плюшкой является то, что за счёт распределённого хранения конфигураций для осуществления управления всем кластером можно подключиться к любой ноде по IP или DNS-имени. Специальных серверов управления разворачивать не нужно. При этом это не запрещено.


Предусмотрен сценарий развертывания управляющей виртуальной машины (УВМ), которая через RestfulAPI может осуществлять полноценное управление всем кластером.


Кстати RestfulAPI, как понятно выше, есть, он описан и работает (по нему будет отдельная статья). Его спокойно можно использовать для автоматизации операций и интеграции со смежными системами. К примеру, уже сейчас есть интеграция (и, кстати, есть внедрение в продуктив) с российским VDI-решением Термидеск, как раз реализованная на базе нашего API. Плюс ещё несколько продуктов вендоров-партнеров на подходе.


Для управления виртуальными машинами изнутри гостевой ОС используется на выбор два протокола: VNC (по умолчанию) или Spice. На уровне отдельных ВМ администратор может задавать разные варианты подключений.



Сам интерфейс разбит на несколько логических частей.


1) Основная область управления, в которой выполняются почти все операции



2) Основное меню, которое выдвигается наведением курсора



3) Панель действий, на которой отображаются доступные для выбранного объекта действия.



4) Панель задач, которая показывает, какие задачи выполняются или были выполнены над выбранным объектом, вызывается выбором объекта и последующим кликом по кнопке задачи.



5) Ну и, наконец, информационная панель, которая показывает количество актуальных ошибок (красные) и выполняемых в данный момент действий (синие).



В целом после оптимизации распределенной БД интерфейс стал работать очень плавно и шустро, кроме того мы делали интерфейс сразу адаптивным и без привязки действий к правому клику мышки, и поэтому с ним спокойно можно работать даже с мобильного телефона.



Лирическое отступление: когда я эту функцию показал моему старому товарищу, который является тру-админом (то есть он админил системы в те славные времена, когда систем ещё не существовало) он воскликнул:
Вы нормальные там??!!! Нельзя админить серьезные системы через мобилу!!!
Хочу отметить, что во втором своём высказывании он, безусловно прав, лазить по серьезным кластерам через мобилку опасно, можно ткнуть не туда и всё как обычно упадёт, но всегда есть НО
Я напомнил ему ситуацию, в которую он попал несколько лет назад, когда потратил примерно 40 минут времени и 10 тонн мата на то, чтобы перезагрузить пару зависших виртуалок на известном гипервизоре, используя свой смартфон. Ноутбука у него с собой не было, а его заказчик с паром из ушей требовал устранить проблему здесь и сейчас.
Вспомнив об этом случае, мой товарищ тру-админ перестал сомневаться в нашей нормальности :-).

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


Гипервизор АИСТ


Не секрет, что в основе АИСТа лежит старый добрый KVM с libvirt-овой обвязкой. При этом наша реализация очень сильно доработана. Про годный веб-интерфейс, который управляет не только виртуализацией, но и сетью с хранилищем и который доступен, как с любой ноды, так и с управляющей ВМ, мы писали выше. Но это далеко не все доработки. Вот ещё несколько крайне достойных функций, которых в штатном KVM-е нет.


Отказоустойчивость виртуальных машин (HAVM) реализована классическим и понятным образом. Она может быть активна или неактивна для каждой виртуалки, а включается на этапе создания ВМ или в процессе её редактирования.



Если параметр HAVM активен, то в случае отказа ноды кластера, ВМ автоматически перезапуститься на другой ноде.


Для отдельных ВМ или для групп ВМ предусмотрены приоритеты обслуживания (QOS) из libvirt-а, где в свою очередь предусмотрены шаблоны популярных конфигураций.



Для защиты данных на уровне ВМ, а также для большей гибкости администрирования предусмотрены мгновенные снимки и клоны (которые можно превратить в шаблоны ВМ соответственно). Важной доработкой и одновременно крайне большой радостью является то, что снэпшоты делаются на горячую (при работающей ВМ) и полностью поддерживают консистентность файловых систем гостевых ОС (Linux, Solaris, Windows, BSD) и ряда поддерживаемых СУБД (пока только PostgreSQL и MySQL). При этом с помощью RestfulAPI никто не мешает реализовать консистентные снимки для других систем внутри гостевой ОС самостоятельно.


Для внешнего хранения из коробки поддерживается NFS, то есть хранить виртуалки можно на распределенном хранилище ARDFS (доступно в vAIR) или на внешней СХД по протоколу NFS. Опционально предусмотрена поддержка блочных внешних СХД по протоколам iSCSI и FC.


Миграция виртуальных машин со сторонних гипервизоров


Миграция, причем неважно откуда и куда, всегда стоит особняком во всей ИТ-жизни. За время полутора лет эксплуатации нашими заказчиками первой версии vAIR они (и мы автоматически) регулярно сталкивались с проблемами миграции виртуальных машин со сторонних гипервизоров в АИСТ. Штатный конвертер KVM штука хорошая, но крайне капризная. Поэтому в vAIR v2 (и в АИСТе соответственно) мы предусмотрели человеческий конвертер ВМ из VMware/Hyper-V прямо в интерфейсе vAIR/АИСТ.



Для конвертации администратор выбирает шару NFS (пока только NFS), где лежат файлы виртуальных машин VMware или Hyper-V. Далее vAIR сам сканирует шару на наличие нужных ему файлов и формирует доступный список для миграции. Далее выбираем целевой пул ARDFS (или внешнюю СХД), то есть куда будем конвертировать, выбираем нужные файлы ВМ (можно несколько, они будут конвертироваться по очереди) запускаем и идём пить пиво.



Когда пиво выпито, новые, уже сконвертированные, виртуалки ждут нас уже внутри vAIR-а в выключенном состоянии.


Мониторинг и логирование


Функции мониторинга реализованы как локально, так и удаленно. Администратор может работать со счетчиками утилизации ресурсов CPU, RAM, сетевых интерфейсов и подсистемой ввода-вывода (IOPS, MB/s, latency), как на уровне отдельных нод, так и на уровне кластера в целом.



Всё то же самое доступно и для удаленной системы мониторинга на базе Grafana.



Для логирования и алертинга предусмотрен журнал событий (ноды, порты, физические диски (SMARTCTL), сенсоры, температура и т.п.) с разбивкой по категориям и возможностью оповещения по электронной почте. Опционально поддерживается SNMP.




Кроме описанных выше возможностей гипервизор АИСТ позволяет выполнять функционал, который мы считаем must have, поэтому сильно его разрисовывать не будем, а просто перечислим:


  • Обновление ПО без остановки и миграции виртуальных машин
  • Живая миграция ВМ, а в ближайшем будущем с возможностью динамичного распределения ресурсов (а-ля DRS)
  • Распределённые виртуальные коммутаторы с поддержкой VLAN-ов
  • Расширение кластера без остановки виртуальных машин
  • Автоподдержка (автоматическое оповещение производителя и заведение тикетов в тех. поддержку, при согласии заказчика, само собой)
  • Метрокластер (отдельная большая функция, которой мы посветим позже отдельную статью)

Детально ознакомиться с особенностями функционала можно в технической документации, которая есть у нас на сайте:


https://aerodisk.ru/upload/Datasheet_AIST_final_11042021.pdf


В завершение первой части


В процессе разработки vAIR и АИСТ собственных решений в области виртуализации многие наши доверенные партнеры (которые допущены к раннему доступу), глядя на это, утверждали, что это плохая идея, потому что ВМварь и Нутаникс не догнать, они слишком крутые и великие, у них тысячи программистов по всей планете, бороды длиннее и свитера в два раза толще.


На подобные утверждения мы всегда задавали вопрос.


А эти компании сразу появились на свет с тысячей бородатых разрабов в толстых свитерах?

ИЛИ другой вариант


А вы когда родились вам сразу было 35 лет, у вас была машина, семья, дача, работа и образование? Это в комплекте вам врачи в роддоме выдавали?

В продолжении этой мысли позволим себе процитировать нашу же старую статью:


притча на эту тему.


Однажды странник попал в город, где шло грандиозное строительство. Мужчины ворочали большие камни под палящим солнцем. Что ты делаешь? спросил наш герой у одного из рабочих, который медленно тащил булыжник. Ты что, не видишь камни таскаю! зло ответил тот. Тут странник заметил другого рабочего, который волок телегу с большими камнями, и спросил: Что ты делаешь? Я зарабатываю на еду для своей семьи, получил он ответ. Странник подошел к третьему рабочему, который занимался тем же, но работал энергичнее и быстрее. Что делаешь ты? Я строю храм, улыбнулся тот.

О чем эта притча? О том, что если веришь в большую идею, видишь большую цель, то для тебя нет ничего невозможного, все достижимо. И каждый шаг, который приближает тебя к большой цели, удваивает твои силы. Существует устоявшийся миф о том, что разработка любого серьезного продукта, по силам только транснациональной корпорации, у которой обязательно сотни или тысячи программистов по всему миру.


В жизни это совсем не так. Практически всегда (за редким исключением), новый серьезный продукт создается небольшим коллективом до 10 человек (а обычно 2-3). При этом на этапе создания закладывается 80% всего функционала продукта. Далее продукт силами этого маленького коллектива выходит на рынок (или как-то еще громко заявляет о себе), и там его уже подхватывают инвесторы (фонды, холдинги или крупные производители).


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


На этом мы завершаем первую часть цикла статей про vAIR v2. В следующей статье подробно расскажем о функционале файловой системы ARDFS.


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


Голосование доступно тут, на Хабре, а также в нашем телеграм-чате https://t.me/aerodisk


Всем спасибо за внимание, как обычно ждем конструктивной критики и интересных вопросов.

Подробнее..

Нагрузочное тестирование СХД на Эльбрусе на базе нового ядра Линукс версии 5.4

31.05.2021 06:09:55 | Автор: admin


Тестирование СХД Аэродиск Восток на базе процессоров Эльбрус 8С на новом ядре 5.4 показало крайне позитивный результат: 1,4 миллиона IOPS! Пока оптимисты верили и надеялись, а пессимисты снисходительно улыбались, программисты работали писали код. В итоге новая версия ядра Линукс v5.4 для архитектуры Эльбрус позволила в разы улучшить производительность подсистемы ввода-вывода и полностью реализовать процессора Эльбрус 8С/СВ для систем хранения данных.


По этому прекрасному поводу мы в Аэродиске, предварительно обновив боевую версию встроенного Альт-Линукса в СХД ВОСТОК до ядра 5.4, повторно выполнили нагрузочное тестирование СХД, которое мы публиковали полгода назад. С прошлым отчетом можно ознакомиться по данной ссылке.


Новые тесты проводились на долгожданном ядре Линукс для e2k версии 5.4, которое появилось начале 2021 года, за что хотим сказать огромное спасибо коллективам разработчиков МЦСТ, Базальт СПО, а также Михаилу Шигорину лично.


В ядре 5.4 изменений много, но нас интересуют только основные изменения с точки зрения СХД, а их можно разделить на следующие группы:


Общие обновления:


  • переработан планировщик ввода-вывода, что позволяет лучше параллелить IO между дисками;
  • много мелких оптимизаций под скоростные твердотельные накопители;
  • и самое главное изменение новый компилятор от МЦСТ (LCC версии 1.25).

Обновления от Аэродиска:


  • обновлённый таргет-драйвер, который позволяет лучше параллелить IO между процессорными ядрами;
  • обновление логики работы связки ядро процессора диск для систем на Эльбрусе.

Тестовый стенд


Тестирование мы выполняли на том же железе, что и в прошлый раз. Стенд состоит из сервера с Линуксом, подключенного через FC-коммутатор к двум контроллерам СХД Восток, в которой установлено 12 SAS SSD дисков.


Конфигурация оборудования следующая:


  • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
  • Коммутатор FC 16G 1 шт.
  • СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Ниже схема стенда.



Методика тестирования


Также как и в прошлый раз для нагрузочных тестов мы использовали популярную и проверенную временем программу Flexible IO (FIO).


СХД сконфигурирована исходя из наших рекомендаций к высокой производительности на блочном доступе или просто настройки для ALL-Flash систем. Поэтому используем не менее двух дисковых пулов DDP (Dynamic Disk Pool). Чтобы не бить в одну точку и максимально реализовать вычислительный потенциал платформы создаем несколько LUN-ов в RAID-10 (8 шт. по 500 ГБ каждый).


Все LUN-ы презентуем двум контроллерам (пополам, по 4 каждому), чтобы максимально утилизировать все ресурсы СХД.


В ходе тестирование будут выполняться следующие популярные сценарии использования СХД, в частности:


Последовательная нагрузка маленькими блоками 4k


  • 100%_read_4k_sequential
  • 100%_write_4k_sequential

Случайная нагрузка маленькими блоками 4k


  • 100%_read_4k_random
  • 100%_write_4k_random

Последовательная нагрузка большими блоками 128k


  • 100%_read_128k_sequential
  • 100%_write_128k_sequential

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


Во всех тестах мы, чтобы не искажать результаты тестирования, намеренно отключаем RAM-кэш СХД, который используется для ускорения ввода-вывода, компрессии и дедупликации. Забежим вперед и отдельно скажем про утилизацию оперативной памяти СХД в целом (чтобы к этому вопросу больше не возвращаться). Во всех тестах RAM утилизируется практически одинаково, т.е. слабо, т.к RAM-кэш, дедуп и компрессия отключены. Вся утилизация RAM это внутренние системные операции СХД. Если бы мы включили RAM-кэш, то результаты были бы заметно лучше, но тогда тест был бы не совсем честным. При этом график утилизации оперативки мы для порядка все-равно приводим в отчете ниже.


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


100%_read_4k_sequential

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=read
numjobs=16
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/read-iodepth-128-numjobs-16
write_iops_log=./logs/read-iodepth-128-numjobs-16
write_lat_log=./logs/read-iodepth-128-numjobs-16
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_write_4k_sequential

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=write
numjobs=16
runtime=2400
time_based=1


write_bw_log=./logs/4k-seq-write.results


write_iops_log=./logs/4k-seq-write.results


write_lat_log=./logs/4k-seq-write.results


[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_read_4k_random

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=64
group_reporting
rw=randread
numjobs=2
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/4k-rand-read.results
write_iops_log=./logs/4k-rand-read.results
write_lat_log=./logs/4k-rand-read.results
[job-1]
filename=/dev/sdc
[job-2]
filename=/dev/sdd
[job-3]
filename=/dev/sde
[job-4]
filename=/dev/sdf
[job-5]
filename=/dev/sdg
[job-6]
filename=/dev/sdh
[job-7]
filename=/dev/sdi
[job-8]
filename=/dev/sdj


100%_write_4k_random

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=16
group_reporting
rw=randwrite
numjobs=2
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/4k-rand-write.results
write_iops_log=./logs/4k-rand-write.results
write_lat_log=./logs/4k-rand-write.results
[job-1]
filename=/dev/sdc
[job-2]
filename=/dev/sdd
[job-3]
filename=/dev/sde
[job-4]
filename=/dev/sdf
[job-5]
filename=/dev/sdg
[job-6]
filename=/dev/sdh
[job-7]
filename=/dev/sdi
[job-8]
filename=/dev/sdj


100%_read_128k_sequential

[global]
blocksize=128k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=read
numjobs=16
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/128k-seq-read.results
write_iops_log=./logs/128k-seq-read.results
write_lat_log=./logs/128k-seq-read.results
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_write128k_sequential

[global]
blocksize=128k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=16
group_reporting
rw=write
numjobs=2
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/128k-seq-write.results
write_iops_log=./logs/128k-seq-write.results
write_lat_log=./logs/128k-seq-write.results
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]


Результаты тестов


Последовательная нагрузка маленькими блоками 4k


100%_read_4k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_4k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Результаты теста с использованием последовательного характера нагрузки небольшими блоками 4k нас впечатлили, получилось !1,4 миллиона! IOPS на чтение и 700k на запись. Если сравнивать это с предыдущим нашим тестом на ядре 4,19 (371k и 233k IOPS), то это скачек в четыре раза при том, что железо мы не меняли.


Также отмечаем довольно небольшую утилизацию CPU, она примерно на 20% ниже предыдущего теста (69/71% против 76/92%).
Задержки при этом остались на том же уровне, что и полгода назад, это не значит, что с этим мы думаем мириться, это значит, что над этим мы ещё будем работать. В конце статьи, будет итоговая таблица сравнения с тестом полугодовой давности на ядре 4,19.


Случайная нагрузка маленькими блоками 4k


100%_read_4k_random
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_4k_random
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Показатели случайной нагрузки маленькими блоками, характерной для транзакционных СУБД остались практически без изменений по сравнению с прошлым тестом. СХД Восток на Эльбрусе вполне нормально справляется с подобными задачами, выдавая 118k IOPS на чтение и 84k IOPS на запись при довольно высокой утилизации CPU.


Отмечаем, что для Эльбруса в отличии от других процессоров работа в режиме постоянной загрузки близкой к 100% является штатной ситуацией (он для этого создавался). Мы это проверяли, оставляя СХД Восток с нагруженным процессором под 95% на несколько дней и результат был следующий: 1) процессор был холодный; 2)процессор и система в целом работали в нормальном режиме. Поэтому к высокому уровню утилизации процессоров Эльбрус следует относиться спокойно.


Также с прошлого ядра сохранилась приятная особенность. Если посмотреть на задержки при случайной нагрузке маленькими блоками, то внимание привлекает то, что задержки на запись ниже, чем на чтение (3 мс против 8 мс), когда мы все привыкли, что должно быть наоборот. Эльбрус с точки зрения случайного характера нагрузки по-прежнему любит запись больше чем чтение, что несомненно является отличным преимуществом, которое грех не использовать.


Последовательная нагрузка большими блоками 128k


100%_read_128k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_128k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Ещё полгода назад СХД Восток на базе процессоров Эльбрус показала отличный результат в тесте последовательной нагрузки большими блоками, что актуально для видеонаблюдения или трансляций. Особой фишкой Эльбруса были ультранизкие задержки при работе с большими блоками (0,4-0,5 мс против 5 6 мс у аналогичного процессора архитектуры x-86).


При чтении данных большими блоками данное преимущество удалось не только закрепить, но и развить. Максимальную скорость на новом ядре удалось поднять в два раза (5,7 ГБ/с на ядре 5.4 против 2,6 ГБ/с на ядре 4.19) при задержках 0,3 мс! Также нагрузка на процессор при данном тесте тоже выглядит лучше (52% на 5,4 против 75% на 4,19).


А вот с записью не так все радужно. К сожалению, в новой версии ядра получить ультранизкие задержки на запись уже не удается, во всяком случае пока. Они находятся на уровне 11 мс (а было 0,5 мс), что в целом не плохо, т.к. примерно такой же уровень задержек при таком тесте мы видим на процессорах других архитектур. Так или иначе это наше домашнее задание, над которым мы будем работать. При этом позитивный момент все-таки есть. Как и в других тестах утилизация процессора значительны снижена (74% против 95%).


Итоговые результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8 С, ядро 5.4


Улучшение в 5.4 зеленые, ухудшения 5.4 оранжевые


Для сравнения, результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8С, ядро 4.19


Улучшение в 5.4 зеленые, ухудшения в 5.4 оранжевые


Прогресс виден не вооруженным глазом! Новая версия ядра 5.4 для архитектуры Эльбрус позволила выжать практические максимумы из совсем не нового процессора Эльбрус 8С (2016 г. выпуска). На данный момент даже у самых ярых пессимистов уже не повернется язык назвать процессор Эльбрус медленным, все таки полтора миллиона IOPS это много.


В очередной раз мы убедились в отличной работе СХД на Эльбрусе среде, где преобладает последовательная нагрузка, а это аналитические СУБД, онлайн-трансляции, видеонаблюдение, обработка больших данных и т.п.


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


Безусловно есть ещё над чем работать (те же задержки при записи больших потоков), но за прошедшие полгода коллектив МЦСТ проделал титаническую работу, и она дала видимый результат, что не может не радовать.


В конце этого 21-ого года мы ожидаем новый процессор Эльбрус 16С, который, кроме того что будет намного быстрее, ещё будет поддерживать аппаратную виртуализацию, а это значит что у нас в России наконец-то появится полностью отечественные не только СХД, но и системы виртуализации, и гиперконвергентные системы (кто сказал АИСТ и vAIR?))).


Кстати о птичках! В течение этой недели мы определимся с датами следующего технического вебинара ОколоИТ про нашу систему виртуализации АИСТ и гиперконвергентную систему vAIR, ссылка на регистрацию появится в этой статье (следите за обновлением), а также в нашем телеграмм-чате.
Ну и само собой, не можем не напомнить о бесплатных курсах по системам Аэродиск, на которые можно записаться тут.


На этой позитивной ноте завершаем очередную статью про Эльбрус. Традиционно ждем каверзных вопросов, конструктивных споров и предложений.

Подробнее..

Kingston Design-In новые опции для бизнеса

18.11.2020 16:23:31 | Автор: admin


Для решения вопроса адаптации продукции под потребности заказчика, компания Kington приняла решение развить направление Design-in SSD. Процесс интеграции оборудования еще никогда не был столь прост. Смотрим, что придумала компания Kingston

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

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

Поэтому пропадает возможность найти то самое нужное только тебе решение в рознице, которое будет полностью отвечать всем необходимым запросам по производительности и совместимости. А если и находятся несколько претендентов, то либо с ненужным дополнительным функционалом, либо со слишком высокой ценой. Чтобы оградить заказчика от всех этих проблем, компания Kingston придумала программу Design-in SSD, способная удовлетворить практические любые потребности.

Ключевые моменты Design-in SSD




IT сфера, как и многие другие сферы производства и разработки рано или поздно достигают пика развития. На этом этапе важно понимать не только то, что вы производите, но и каким боком Вы повернуты к клиенту. Kingston не боится вести прямой диалог с заказчиком, поэтому открывает для себя новое направление программу Design-in в сфере производства SSD накопителей. Ведь любой потребитель, особенно интегратор, проектировщик или разработчик, хочет получать наибыстрейший отклик от производителя на проблемные аспекты внедрения и поддержки оборудования.

Кастомизация

Готовые шаблоны с артикулами, разработанные в соответствии с широкими спектрами потребностей клиентов. Вследствие чего, заказчику можно выбрать предварительный набор функций и свойств SSD заранее проверенный специалистами Kingston. По требованию проекта изменению могут быть подвергнуты различные параметры SSD, начиная от номера SKU, заканчивая прошивкой под выносливость SSD или наоборот, максимальной скорости. Можно менять SMART атрибуты, пороговые значения, название модели, изготовление маркировки и упаковки накопителя.



Одним из примеров удачной кастомизации в рознице для РФ является SSD HyperX Fury 3D. Продукт, изначально планируемый только для рынка стран СНГ, но сейчас нашел себе место в массовом производстве и продается во многих странах. Более подробно с ним можно ознакомиться здесь. Данный проект появился исключительно благодаря запросам ритейлеров и поставщиков, а те учитывали требования пользователей в бюджетном сегмента SSD, в котором нет лишних опций, но его производительность должна соответствовать средним игрокам на рынке. Соответственно его специально сделали для рынка СНГ, но из-за отличного соотношения цены и скорости Kingston HyperX Fury 3D пришелся по нраву остальному миру.

Учет требования заказчика

Для этого адаптируется прошивка накопителя, выбирается фиксированная конфигурация связки контроллера, микросхем NAND, p/n и т.п. Особенное внимание уделяется совместимости SSD для конкретного проекта или используемого оборудования. Так как некоторые производители отвергают любую возможность использования сторонних комплектующих в своих системах. На этом этапе прошивка получает специальные записи для определения статуса свой-чужой в системе. А после интеграции SSD обновить firmware такого SSD общераспространяемой прошивкой невозможно.

Вашу персонализированную и адаптированную прошивку будут поддерживать специалисты Kingston, и каждый релиз проверять на совместимость. Помимо фактической проверки в обязательном порядке будут внесены записи в пакет документов к SSD, иными словами, каждый шаг документируется.



Перед массовой поставкой заказчик получит экземпляры SSD для проверки на своем оборудовании. Процесс напрямую поддерживают специалисты Kingston для внесения корректировок либо улучшения совместимости и производительности оборудования. Благодаря прямому взаимодействию с командой инженеров Kingston любые проблемы будут решаться в кратчайшие сроки.

Помимо вышеперечисленных шагов программы для SSD Kingston, прошедших этап кастомизации под заказчика, остается 3-летняя гарантия производителя и бесплатная техническая поддержка. Время полного цикла согласования занимает менее 3 месяцев, производство еще несколько недель. Минимальное количество не регламентировано.



Кастомизация форм-фактора и размеров. Сама программа имеет достаточно широкий диапазон возможностей, в том числе заказ SSD практически любых интерфейсов (М.2, mSATA) и SSD малых емкостей.
2,5 дюймы 7 мм SATA;
M.2 SATA 2280 и 2242;
mSATA;
M.2 NVMe 2230 и 2280;
BGA чипы NVMe 11x13 мм с контроллером.

Сегменты рынка для программы Design-in SSD

Естественно, обычному покупателю пользоваться возможностями Design-in SSD не обязательно, да и просто не нужно. Она рассчитана на специализированные области применения:



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

Совместный проект с Kingston не обязательно начинать с полного нуля, хотя и такое возможно. В ассортименте есть масса базовых моделей, готовые для последующей модификации. Им можно добавлять и изменять нужные опции. Такой подход позволяет упростить разработку проекта, соответственно сэкономить время и средства.

Начальное количество SSD для старта работы по Design-in рассматривается из любого требуемого количества, хоть от одной штуки, особенно если речь идёт об уже готовых решениях Kingston. Конечно, в зависимости от сложности кастомизации, цена за единицу может варьироваться, и в каких-то случаях гораздо выгоднее снизить стоимость единицы товара за счет увеличения количества.

В данных таблицах представлены все модели в полном объеме, 64, 128 и 256, включая довольно экзотические 64 ГБ NVMe SSD и форм-факторы 2230 и 2242, которые сложно найти в розничных магазинах.





План производства SSD Kingston


Начиная с октября 2020 года Kingston внедряет в свои SSD BiCS4 3D TLC NAND память взамен BiCS3 3D TLC NAND производства Kioxia. Но у заказчиков программы Design-in SSD остается возможность использования BiCS3 3D TLC NAND и получать от производителя твердотельные накопители малого объема.


Важным отличием Kingston остается поддержка и производство 4 типов SATA SSD: 2,5 дюйма, M.2 2242, M2 2280 и mSATA.


NVMe линейка получит нового поставщика NAND памяти. В портфеле NVMe носителей появятся бюджетные модели с контроллером, где оперативная память компьютера будет выделяться для кеша SSD.

Выводы




Kingston это не просто производитель SSD, компания представила программу Design-in SDD и превратилась в надежного партнера по интеграции. Если вам не хочется тратить время на подбор комплектующих для своего проекта, быть уверенным в 100% совместимости, оперативно получать поддержку, то программа Kingston Design-in SSD позволяет:

Выбирать среди накопителей SSD SATA и NVMe, созданных для проектировщиков и разработчиков систем;

Получать фиксированный BOM и Firmware, обеспечивающие стабильную работу в рамках вашего проекта, а все изменения и обновления контролируются и документируются для ведения отчетности и понимания какие были внесены исправления и улучшения;

Один из этапов программы предусматривает инженерную поддержку при проектировании, производстве и внедрении;

Kingston позаботится о предварительной квалификации перед массовым производством, плюс вы получите глобальную поддержку Kingston может координировать свои действия с ODM или CM по всему миру, если это необходимо;

Гарантия трехлетняя ограниченная гарантия и бесплатная техническая поддержка;
В совокупности Kingston предлагает полное решение под ключ на основе выпускаемых SSD для внедрения в проекты любой сложности, с последующей поддержкой.

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

Подробнее о программе Design-in.

Предлагаем читателям оставить свои комментарии о том, каких опций им не хватает в SSD сегодня, чего бы они добавили, а самые оригинальные посты будут вознаграждены подарками Kingston.

Для получения дополнительной информации о продукции Kingston обращайтесь на официальный сайт компании.
Подробнее..

Как Uma.Tech инфраструктуру развивала

29.07.2020 16:12:53 | Автор: admin
Мы запускали новые сервисы, трафик рос, заменяли сервера, подключали новые площадки и переделывали ЦОДы а сейчас расскажем эту историю, с началом которой знакомили вас пять лет назад.

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

Мы обеспечиваем работу сложнейших проектов с жесточайшими требованиями к надежности, и к нагрузкам, среди которых PREMIER и Матч ТВ. На спортивных трансляциях и на премьере популярных сериалов требуется отдача трафика в терабиты/с, мы это легко реализуем, причем так часто, что работа с такими скоростями давно стала для нас обыденностью. А пять лет назад самым тяжелым проектом, работающим на наших системах, был Rutube, который с тех пор развивался, наращивал объемы и трафик, что нужно было учитывать при планировании нагрузок.

Мы рассказывали о том, как развивали железо нашей инфраструктуры (Rutube 2009-2015: история нашего железа) и развивали систему, ответственную за отгрузку видео (С нуля до 700 гигабит в секунду как отгружает видео один из крупнейших видеохостингов России), но с момента написания этих текстов прошло много времени, создано и внедрено множество других решений, результаты которых позволяют нам отвечать современным требованиям и быть достаточно эластичными, чтобы перестраиваться для новых задач.

Сетевое ядро постоянно развиваем. Мы перешли на оборудование Cisco в 2015 году, о чем упоминали еще в прошлой статье. Тогда это были всё те же 10/40G, но по понятной причине уже через несколько лет модернизировали существующие шасси, и теперь активно используем ещё и 25/100G.



Линки 100G уже давно не являются ни роскошью (скорее, это настоятельное требование времени в нашем сегменте), ни редкостью (всё больше операторов предоставляют подключение на таких скоростях). Однако, 10/40G сохраняет актуальность: через эти линки мы продолжаем подключать операторов с небольшим объёмом трафика, по которым на данный момент нецелесообразно задействовать более ёмкий порт.

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

Серверы отдачи видео эволюционируют быстро, для чего мы предлагаем немало усилий. Если раньше мы использовали преимущественно 2U серверы с 4-5 сетевыми картами по два 10G-порта у каждой, то теперь большая часть трафика отдаётся с 1U серверов, в которых 2-3 карточки по два 25G-порта у каждой. Карты с 10G и с 25G практически сравнялись в стоимости, а более скоростные решения позволяют отдавать как по 10G, так и по 25G. Результатом стала очевидная экономия: меньше компонентов сервера и кабелей для подключения меньше стоимость (и выше надежность), компоненты занимают меньше места в стойке стало возможным размещение большего числа серверов на единицу площади и, следовательно, стала ниже стоимость аренды.

Но важнее выигрыш в скорости! Теперь мы с 1U можем отдавать более 100G! И это на фоне ситуации, когда некоторые крупные российские проекты называют достижением отдачу 40G с 2U. Нам бы их проблемы!

Заметим, что поколение сетевых карт, которые умеют работать только на 10G, мы по-прежнему используем. Это оборудование стабильно работает и прекрасно нам знакомо, поэтому мы его не выбросили, а нашли ему новое применение. Эти комплектующие мы установили в серверы хранения видео, которым уже для эффективной работы явно недостаточно одного-двух 1G-интерфейсов, тут 10G-карты оказались актуальными.

Системы хранения данных тоже растут. За прошедшую пятилетку они из двенадцатидисковых (12x HDD 2U) стали тридцатишестидисковыми (36х HDD 4U). Такие емкие тушки некоторые боятся использовать, так как в случае выхода из строя одного такого шасси может возникнуть угроза для производительности а то и работоспособности! для всей системы. Но у нас такого не случится: мы обеспечили резервирование на уровне геораспределенных копий данных. Мы разнесли шасси по разным дата-центрам всего мы используем три и это исключает возникновение проблем как при сбоях в шасси, так и при падении площадки.



Разумеется, такой подход сделал избыточным аппаратный RAID, от которого мы отказались. Избавившись от избыточности, мы одновременно повысили надежность системы, упростив решение и убрав одну из потенциальных точек отказа. Напомним, что СХД у нас самодельные. На это мы пошли совершенно сознательно и результат нас полностью устроил.

ЦОДы за прошедшие пять лет мы меняли несколько раз. Со времени написания предыдущей статьи мы не меняли только один ЦОД DataLine остальные потребовали замены по мере развития нашей инфраструктуры. Все переезды между площадками были плановые.

Два года назад мы мигрировали внутри ММТС-9, перейдя на площадки с качественным ремонтом, хорошими системами охлаждения, стабильным электропитанием и без пыли, которая раньше лежала толстыми слоями на всех поверхностях, а также обильно забивала внутренности нашего оборудования. Выбор в пользу качества услуг и отсутствия пыли! стал причиной для нашего переезда.

Почти всегда один переезд равен двум пожарам, но проблемы при миграции каждый раз разные. На этот раз основная сложность переезда внутри одного ЦОДа обеспечили оптические кроссировки их межэтажное обилие без сведения в единую кроссовую со стороны операторов связи. Процесс актуализации и перепрокладки кроссировок (в чем нам помогли инженеры ММТС-9), был, пожалуй, самым сложным этапом миграции.

Вторая миграция состоялась год назад, в 2019 году переезжали мы из М77 в O2xygen. Причины переезда были схожие с рассмотренными выше, но к ним добавилась проблема с непривлекательностью исходного ЦОДа для операторов связи многих провайдеров приходилось догонять до этой точки своими силами.

Миграция 13 стоек на качественную площадку в ММТС-9 позволило развивать эту локацию не только как операторскую (пара-тройка стоек и пробросы операторов), но и задействовать в качестве одной из основных. Это несколько упростило миграцию из М77 большинство оборудования из этого ЦОД мы перевезли на другую площадку, а O2xygen отвели роль развивающегося, отправив и туда 5 стоек с оборудованием.

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

Основную фазу переезда мы обязательно проводим за одну ночь, и при миграции внутри ММТС-9 и на O2xygen придерживались этого правила. Подчеркнем, что правило переезд за ночь мы строго выполняем независимо от количества стоек! Был даже прецедент, когда мы перемещали 20 стоек и выполнили это тоже за одну ночь. Миграция достаточно нехитрый процесс, требующий аккуратности и последовательности, но и тут есть некоторые хитрости как в процессе подготовки, так и при переезде, и при развертывании на новой локации. О миграции в деталях мы готовы подробно рассказать, если у вас будет заинтересованность.

Результаты пятилетки развития нам нравятся. Мы завершили построение новой отказоустойчивой инфраструктуры, распределенной по трем центрам обработки данных. Резко повысили плотность отдачи трафика если недавно радовались 40-80G с 2U, то сейчас для нас норма отдавать 100G с 1U. Теперь и терабит трафика воспринимается нами как обыденность. Мы готовы и дальше развивать нашу инфраструктуру, которая получилась гибкой масштабируемой.

Вопрос: о чем рассказать вам в следующих текстах, уважаемые читатели? О том, почему мы стали создавать самодельные системы хранения данных? Про сетевое ядро и его особенности? О хитростях и тонкостях миграции между дата-центрами? Об оптимизации решений по выдаче путем подбора компонент и тонкой настройки параметров? Про создание устойчивых решений благодаря многократному резервированию и горизонтальным возможностям масштабирования внутри дата-центра, которые реализованы в структуре из трех ЦОДов?

Автор: Петр Виноградов
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru