Компания
158,15
рейтинг
22 октября 2015 в 09:57

Разное → Как можно сделать отказоустойчивую систему хранения данных из отечественных серверов


Нода кластера: сервер отечественного производства Etegro (2 AMD Opteron 6320, 16 GB RAM, 4 HDD)

Системы хранения данных, используемые сейчас на практике в России, условно делятся на три категории:
  • Очень дорогие high-end СХД;
  • Мидрейнжевые массивы (тиринг, HDD, гибридные решения);
  • И экономичные кластеры на базе SSD-массивов и HDD-массивов из «бытовых» дисков, часто собранные своими руками.

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

И вот на этот рынок пришла EMC, известная своими чертовски дорогими и надёжными железками с софтом, который позволяет без проблем поднять и VMware-ферму, и виртуальную СХД, и всякий приклад на одних и тех же х86 серверах. И ещё началась история с серверов русского производства.

Русские серверы


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

Российский сервер — это такая чудо-железка, которая на 100% собирается в России и является по всем нормам 100% отечественной. На практике — возят отдельные детали из Китая и других стран, закупают отечественные провода и делают сборку на территории РФ.

Получается не так чтобы очень плохо. Работать можно, хотя надежность ниже тех же HP. Но это компенсируется ценой железа. Дальше мы приходим к ситуации, в которой не самое стабильное железо должно компенсироваться хорошим управляющим софтом. На этом этапе мы начали экспериментировать с EMC ScaleIO.

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

В итоге концепция поменялась: теперь мы говорим просто про выгоду ScaleIO на различном железе, в том числе (и в первую очередь) — из нижнего ценового сегмента.

Но к делу: результаты тестов


Вот принцип работы ScaleIO (http://habrahabr.ru/company/croc/blog/248891/) — берём серваки, набиваем их под завязку дисками (например, теми же SSD-штуками, которые предназначались для замены HDD в своё время) и соединяем всё это в кластер:

image

Конфигурация, проверенная нами в лаборатории в этот раз — это интеграция EMC ScaleIO и VMware. Коллеги из Etegro любезно одолжили нам 4 сервера с 2 процессорами AMD Opteron(tm) Processor 6320 и 16 GB оперативной памяти в каждом. В каждом стояло по 4 диска. Не самая ёмкая конфигурация, я бы предпочел серверы на 25 дисков 2.5 дюйма, но работать приходится с тем, что есть, а не с тем, чего хочется.

Вот серверы в стойке:



Весь объём дисков в сервере я поделил на 3 части:
  • 10 Gb для ESX. Этого вполне достаточно.
  • 30 GB для внутренних нужд ScaleIO, но об этом позже.
  • Все остальное место будет отдано через ScaleIO.

Первое, что нужно сделать — установить VMware. ESX ставить будем по сети, так быстрее. Задача это не новая, а виртуальная машина с PXE сервером давно заняла заслуженное место в моем ноутбуке.



Как видите, в нашей лабе много тестового оборудования. Справа стоят еще 4 стойки и еще 12 на первом этаже. Мы можем собрать практически любой стенд по просьбе заказчика.

Технология работы Software Defined Storage такова, что каждая нода может запросить достаточно большое количество информации с других нод. Этот факт означает, что в таких решениях очень важны пропускная способность и время отклика BackEnd сети. 10G Ethernet хорошо подходит для решения этой задачи, а коммутаторы Nexus уже стоят в этой стойке.

Вот схема получившегося решения:



Установка ScaleIO на VMware очень проста. Фактически она состоит из 3 пунктов:
  1. Устанавливаем плагин для vSphere;
  2. Открываем плагин и запускаем инсталляцию, в этом же пункте нужно ответить на 15-20 вопросов визарда.
  3. Смотрим, как ScaleIO самостоятельно заползает на серверы.




Если визард закончился без ошибок, в vSphere появится специальный раздел для ScaleIO, в котором можно создать луны и отдать их ESX серверам.



Или можно использовать стандартную консоль ScaleIO, установив ее на локальный компьютер.



Теперь небольшой тест на производительность. Я создал на каждом хосте по виртуальной машине с 2 дисками по 50Gb и равномерно разделил их по датасторам. Нагрузку генерировал с помощью IOmeter. Вот максимальные результаты, которые мне удалось получить на нагрузке 100% random, 70% read, 2k.


3000 application IO c 4-х серверов с SAS дисками — неплохой результат.

В качестве развлечения я попытался «завалить» систему, выдергивая ноды в разной последовательности и через разные промежутки времени. Если ноды выдергивать по одной и давать ScaleIO достаточно времени для ребилда, то виртуальные машины будут работать, даже если останется одна нода. Если отключить 3 ноды за минуту, например, доступ к общему пространству остановится до той поры, пока эти ноды не будут включены обратно. Данные становятся доступны, а массив выполняет проверку целостности данных и ребилд (если необходимо) в фоновом режиме. Таким образом, решение получается достаточно надежным для того, чтобы использовать его на боевых задачах.

Пожалуй, про виртуализацию все. Пора подвести итог.

Резюме


Плюсы:
  • Цена решения (процессорные мощности + память + диски) конкурентоспособна и во многих случаях будет существенно ниже, чем серверы + СХД в аналогичных моновендорных предложениях.
  • Можно использовать любое железо и получить замену «большой красивой» СХД для таких же задач. Если нужно, серверы можно заменить на более мощные без закупки каких-либо дополнительных лицензий для ScaleIO. Он лицензируется потерабайтно без привязки к железу.
  • Решение конвергентное. Виртуальные машины и СХД на одном и том же сервере. Это очень удобно практически для любого среднего бизнеса. Флеш-СХД — уже не фантастика на этом уровне.
  • Плюс требуется меньше места в стойках, меньше энергопотребление.
  • Хорошая балансировка — равномерное распределение IO по всем дисковым ресурсам.
  • Решение можно разнести на 2 разные площадки, настроив зеркалирование между ними на уровне одного кластера ScaleIO.
  • Для синхронной и асинхронной репликации между кластерами можно использовать виртуальный RecoverPoint.

Минусы:
  • Во-первых, придётся применить мозг. Дорогие решения, как правило, хороши тем, что внедряются очень быстро и не требуют почти никакого специального обучения. Учитывая, что ScaleIO — это, фактически, самосборное СХД, придётся разобраться в архитектуре, покурить пару форумов для оптимальной конфигурации, поставить эксперимент на своих данных для выбора оптимальной конфигурации.
  • Во-вторых, за избыточность и отказоустойчивость вы платите местом на дисках. Коэффициент преобразования raw space в user space меняется в зависимости от конфигурации, и, возможно, вам потребуется больше дисков, чем вы думали изначально.


Напоминаю, вот здесь можно прочитать про софтверную часть подробно, а я же с удовольствием отвечу на вопросы в комментариях или почте RPokruchin@croc.ru. А ещё через месяц, 26 ноября, мы с коллегами будем делать открытый тест-драйв с Scale IO пылесосом Керхер, кувалдой и другими штуками, пока мужики не скажут: «Аааа, заррраза». Регистрация тут.
Автор: @RPOkruchin
КРОК
рейтинг 158,15

Комментарии (40)

  • +4
    Спасибо за статью! Только вот ETegro уже… того. RIP.
  • +7
    Извините, но что в этом сервере отечественного, кроме этикетки?
    • +1
      Российский сервер — это такая чудо-железка, которая на 100% собирается в России и является по всем нормам 100% отечественной. На практике — возят отдельные детали из Китая и других стран, закупают отечественные провода и делают сборку на территории РФ.


      Сборка. Только сборка.
      • +1
        То-то и оно. Ни оригинального дизайна — ходя бы форм-фактора материнской платы, ни корпуса, ни салазок, ни ru-iLO.

        Сервер отечественного производства. Да его и отверткой-то китайской, наверняка, собирали.
        • +3
          А я-то наивно надеялся увидеть здесь схд на Эльбрусе…
    • 0
      Сборка, цена и дизайн плат. Компоненты и готовые платы производителю (сборщику) везти через таможню куда дешевле, чем целый сервер. Смысл же в том, что можно использовать любое железо, включая такое, и получать надежные решения.
      • 0
        То есть дизайн плат Etegro все таки выполняет самостоятельно?
        • +1
          Да, дизайн плат был их, по словам их инженера
      • +1
        Под дизайном плат — имеете ввиду заказ у Кванты разъемов БП с другой стороны или фейла с подключением mezzanine-платы ко второму процессору?
  • +3
    Простите, 3000 IOPS с 16 SSD дисков???
    • 0
      В массиве нет SSD-дисков.
      • 0
        «Вот принцип работы ScaleIO (http://habrahabr.ru/company/croc/blog/248891/) — берём серваки, набиваем их под завязку дисками (например, теми же SSD-штуками, которые предназначались для замены HDD в своё время) и соединяем всё это в кластер:»
        Поскольку ниже нет описания, какие же диски использовались, то создается полная иллюзия того, что все-таки SSD диски
        • +1
          Если SAS диски стоят в серверах и I/O распределены равномерно по шпинделям, то даже расчетно получается (по консервативным прикидкам) 16*180 IOPS=2880 IOPS.

          Только вот на скриншоте это скорее все же вackend IOPS, т.е. то что выдают диски. А не aplication (или frondend) I/O, т.е. то что генерят приложения на серверах. А это все таки немного разные вещи.
          • 0
            Это вackend IOPS, состоящие из 1500 IO чтения (1500 на FE) и 2*750 IO записи (750 IO записи для клиента).
            • 0
              В статье написано:
              Вот максимальные результаты, которые мне удалось получить на нагрузке 100% random, 70% read, 2k.

              Правильнее предположить что хосты генерят:
              3000=x*0.7+x*0.3*2
              x=3000/1.3= ~2300 IOPS, из которых чтение ~1610 IOPS (70%) и запись ~690 IOPS (30%).
  • +1
    А правда ли, что прайсовая цена ScaleIO примерно 1572 долларов за терабайт сырого места?
    • 0
      Думаю, что правда, у IBM подобная система стоит заоблачных денег) очередная рекламная уловка
      • 0
        Немного шокирует. Да что уж, сильно шокирует.

        Смотрю как «заигрывают» с рынком Nexenta и Nutanix (последние, к сожалению, благодаря блогу производят впечатление аггресивных хвастунов). У ScaleIO достижения скромнее, бери и используй для тестов без ограничений, по времени или объему, но без продуктовой нагрузки.

        Жду широкого шага от VMware. Сейчас цена VSAN не сильно адекватна рынку. И в то же время VMware испытывает определенное давление со стороны Hyper-V, KVM и соответствующих инфраструктурных обвязок. Включение лицензии VSAN в стоимость гипервизора было бы глотком свежего воздуха для VMware.
        • 0
          Если очень хочется, то можно и для нормальной нагрузки её использовать.

          А от VMware халявы ждать не стоит, они нацелены на рынок богатых ентерпрайзов и принципиально не дают ничего бесплатно. У них даже доступ к роликам с VMworld стоит 200 ойро в год, где показали занятную статистику использования DRS. По ней можно сделать вывод, что абсолютное большинство клиентов покупает vSphere в редакции Enterprise и выше, а не дешевую Standard.
          • 0
            Да там все примерно то же написано
            Q: Can I use it in production environments?
            A: No, not really.
            • 0
              Вы зря не скопировали ответ полностью, там вполне разумное объяснение со следующим выводом «If you will NEVER CALL IN SUPPORT – whatevs.»
              • 0
                Думаю, мы понимаем о чем идет речь, об определенных разумных и добросовестных отношениях. «EMC isn’t going to police this.» Но если соблюдать все формальности, то все же нет.
  • –1
    Зачем эта проприетарщина, когда есть Ceph?
    • +1
      Каждое ПО имеет свою область задач. С помощью Ceph невозможно решить задачу, описанную в топике. Нельзя установить его на хосты VMware и сделать SDS для виртуальных машин из локальных дисков.
      • 0
        В топике написано
        Как можно сделать отказоустойчивую систему хранения данных из отечественных серверов

        По Вашему мнению Ceph не пригоден для создания программноопределяемого хранилища для хранения блочных устройств виртуальных машин?
        А что же тогда у меня уже год работает? Мой опыт говорит, что из стандартного железа с помощью Ceph можно собрать SDS по характеристикам не уступающим, а местами и превосходящим high-end системы. Говорю не голословно, мы сравнивали с IBM XIV.
        • 0
          Поэтому ScaleIO не умеет права на жизнь? Как минимум он проще для гетерогенной среды — поставил драйверы на VMware/Windows/Linux, прокликал визард в гуе (в 2.0 обещают больше этого) и у тебя работает SDS.

          Для совмещения ролей СХД и гипервизора не надо изобретать Нутаникс велосипед с пробрасывнием в ВМ контроллеров с дисками.
          • 0
            Имеет. Меня возмущает общий, пространный характер содержания заголовка и преамбулы, и не соответствующее ему маркетинговое содержание коммерческого продукта.
            • 0
              Не заметил там ничего про бесплатность или открытость.
              Отечественные серверы есть были, условно-бесплатный ScaleIO тоже и даже прорекламировали RAIDIX (тоже местный, но сильно небесплатный и узкоспециализированный).
        • +1
          В статье речь идет о виртуализации от VMware. В ESX нет нативной поддержки RBD устройств. Можно отдать RBD устройства по NFS или iSCSI через прослойку (примапить их к серверу и отдать по другому протоколу). Будет ли такое решение превосходить high-end системы по отказоустойчивости, производительности, времени отклика и функционалу? Не будет.
          Предлагаю не вести длинный диалог о том, насколько хорош или плох Ceph по сравнению с high-end системами, а посмотреть на рынок. Заказчики не спешат переносить данные с high-end систем на SDS. Таким образом mission critical данные по-прежнему хранятся на high-end системах. Потерять данные себе дороже.
          • 0
            В статье да, а в заголовке и преамбуле нет. Это вводит в заблуждение. Прочитав заголовок и преамбулу, я как минимум ожидал общее описание SDS или обзор решений, а в итоге получил маркетинговый треш.
  • 0
    Какое среднее время восстановления работоспособности системы при выходе из строя одного жесткого диска или SSD?
    • 0
      Хороший вопрос, вот только посчитать довольно сложно. Блоки по 1Mb начнут копироваться по сети со всех дисков, где лежали дубликаты потерянных данных, на не меньшее количество дисков. Сеть в 1 Gbit/s, если не подрезать эти потоки встроенными средствами, ложится почти наглухо. На 10-ке наверно должно быть полегче. Хотя будет сильно зависеть от количества нод в кластере и от размера «погибшего» диска.

      Но в целом интересно было бы увидеть, что было на практике на стенде из статьи.
  • 0
    Вот только вы не учитываете Storage Efficiency (компрессия, дедупликация) у тех самых «красивых и дорогих» СХД, и если посмотреть в этом разрезе, то не такие уж они и дорогие получаются, в особенности для VMWare. То что EMC для этого не подходит — тут я с вами согласен. У нас на уровне группы от америки до азии запрещено использовать в продуктиве на EMC как компрессию так и дедупликацию. Плюс я сам убедился в этом когда у нас 2 раза тестовый VNX прилег часов на 12 из-за использования дедупликации.
    • 0
      Может вы просто не умеете ее готовить? :) Там достаточно много нюансов.

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

      Компрессия так вообще требует при всех операциях I/O online сжатия/разжатия данных. Т.е. дополнительных ресурсов контроллера и времени. Что тоже не везде применимо.
      • 0
        Так было бы из чего готовить. Не буду тут показывать пальцем на правильных вендоров, дабы не быть обвиненным в рекламе, где всё работает уже более 10 лет без нареканий (10 лет это только мой опыт, а так и того больше). Хочу так же отметить, что это не только мой опыт, а так же опыт всей группы в которой суммарно >500 СХД разного калибра… более того у нас так же стандартами «запрещено» использовать MirroView — если нужна репликация на EMC то SRDF или VPLEX. И для виртуализации никакого Fibre Chanel (SCSI) под датасторы — только NFS… все эти стандарты написаны «кровью» убитыми данными. Я думаю это долгий разговор и не в рамках комментариев. :)

        P.S. Приходите на EMC Forum 2015 30 октября :)
        • 0
          Не надо давить меня «групповым авторитетом», а то сломаюсь :).

          У меня мнение простое. Не работает как написано в документации? Значит кто-то не прочитал документацию вдумчиво и до конца. А потом рождаются стандарты легенды о пряморуких админах и неправильном оборудовании :).

          Про репликацию я вас не понял. MirroView — это встроенный функционал средних хранилок (Clariion\VNX). SRDF — это уже hi-end массивы Symmetrix\VMAX. VPLEX — вообще самостоятельное, «массиво-независимое» решение, причем тоже скорее hi-end. Т.е. у вас в компании принято использовать только Hi-End решения? Ну значит этого требует бизнес, что тут можно сказать :).

          А вот NFS меня окончательно запутал. Вы NFS с VMAX-а как раздаете (про VPLEX даже боюсь подумать)? Через файловые шлюзы от массивов среднего уровня? Ака Celerra\VNX file gateway? Мда…

          P.s. На форум с удовольствием, если мне кто-нибудь билет на самолет до Москвы и обратно подкинет :).

          • 0
            Давить ни на кого не собираюсь, я делюсь своим опытом и привожу опыт группы, чтобы показать, что это не просто моё IMHO, а большая работа проделанная большой группой специалистов совместно со специалистами от самих производителей, поэтому тут не пройдут отмазки, что заказчик сделал что-то не так. Периодически, раз в несколько лет, проводится «батл» среди вендоров на право входа в стандарт. На этом батле решения гоняются во всех возможных режимах, что можно только придумать. Прошлый батл, например, длился почти год…

            Так вот, если коротко, то если для решения нужна репликация, то для этого решения возьмут либо VPLEX + VNX, VMAX + SRDF или VPLEX + XtremIO, либо другой вендор, но не VNX + MirrorView. За рубежом EMC прекрасно знают о своих недостатках и их там не единожды в них тыкали моськой и они это признавали. Только в России этот шлак толкают на право и налево подо всё, что только можно. Но, к сожалению, трансформировать убогую архитектуру VNX быстро просто не возможно, как и прикрутить какие-то техологичные фичи. Этому ещё мешает дичайшая разнородность решений их корявейшая интеграция друг с другом (например, VPLEX до сих пор хреново понимается PowerPath'ом и не умеет общаться с массивами расположенными под ним… уже сколько лет)

            Про NFS — боже упаси вас использовать NAS от EMC. Нет, конечно, не используем этот ужас. Есть же нормальные вендоры для NAS.
            • 0
              Чем по вашему рядовые тех.специалисты вендора отличаются от обычных инженеров? По моему опыту в 95% случаев ни чем. Плюс у них свои задачи. Как вы думаете что выгоднее продать вендору VPLEX или лицензию на MirrorView :)? Особенно когда присутствует понимание, что деньги у заказчика есть? :)

              Если по вашему решения EMC, в том числе midrange уровня, «шлак», то как и главное за счет чего они попадают в «стандарты» вашей организации? При таком то «жестком» отборе (или я не правильно, что то интерпретировал)? И что вы в таком случае собираетесь делать на EMC Forum? Плюнуть представителю вендора в лицо? :)

              Вам не кажется, что у каждого решения и технологии просто есть своя ниша и задачи, для которой/которых оно и разрабатывалось. Если же пытаться натягивать это решение куда попало, то и результат будет соответствующий. И я не пытаюсь вам доказать, что MirrorView — это верх совершенства :). Все таки этому решению уже минимум 10-ток лет. А мир не стоит на месте.

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

              В конце концов, приведите уже конкретный кейс, где благодаря оборудованию EMC вы потеряли данные по вине вендора? Хотелось бы увидеть так же описание условий вашего «супер батла», в котором испытывается оборудование и побеждает супер вендор, которого нельзя рекламировать. А инженеры EMC плачут в сторонке, сидя верхом на «убогом» VNX. А то пока все выглядит несколько голословным.

              Про фичастость оборудования и архитектуру VNX оставим вопрос в сторонке, да бы не разводить тут холивар. И так уже почти туда скатились.
              • 0
                P.s.: Меньше эмоций, больше конкретики и фактов.
  • 0
    RPOkruchin, я так понимаю Вы как-минимум плотно занимались тестирование сабжа. Хотел бы задать несколько вопросов:
    1) Как себя ведет такое распределенное хранилище на not equal hardware? К примеру если сервера разной производительности и в особенности если разной емкости у них дисковые массивы (к примеру одно и двуюнитовые сервера по 4 и 8 дисков соответственно).
    2) Почитал whitepaper по развертыванию сабжа на vmware. Вопросов стало еще больше… Настоятельно рекомендуют использовать RDM а не VMFS, RAID контроллер в IT-mode (отдает диски по одному). Ат где тогда разворачивать appliance самого ScaleIO? Получается что нужен еще и локальный VMFS раздел. В итоге — количество дисков, которые можно отдать под данные уменьшается. Если сервера одноюнитовые, то отдать получится всего 2 диска, а на двух остальных будет небольшой VMFS. Все верно, или я что-то упустил? Чем плох VMFS для данных (кроме долгого создания eager-zeroed thick disk)?

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

Самое читаемое Разное