Как стать автором
Обновить

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

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


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

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

Только вот на скриншоте это скорее все же вackend IOPS, т.е. то что выдают диски. А не aplication (или frondend) I/O, т.е. то что генерят приложения на серверах. А это все таки немного разные вещи.
Это вackend IOPS, состоящие из 1500 IO чтения (1500 на FE) и 2*750 IO записи (750 IO записи для клиента).
В статье написано:
Вот максимальные результаты, которые мне удалось получить на нагрузке 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%).
А правда ли, что прайсовая цена ScaleIO примерно 1572 долларов за терабайт сырого места?
Думаю, что правда, у IBM подобная система стоит заоблачных денег) очередная рекламная уловка
Немного шокирует. Да что уж, сильно шокирует.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Про фичастость оборудования и архитектуру VNX оставим вопрос в сторонке, да бы не разводить тут холивар. И так уже почти туда скатились.
P.s.: Меньше эмоций, больше конкретики и фактов.
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)?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий