Что бы вы хотели знать о VSAN и EMC VxRail (но не догадывались спросить;)

9cff0216a1cc4461ab6f6de87b15af37[1]

В связи с выходом новых продуктов на VSAN — EMC VxRail, маркетинговая машина EMC запустилась, и начала свою работу по продвижению нового продукта семейства EVO:Rail. Новостей о «новом революционном продукте от изобретателей гиперконвергенции» будет много по всем каналам, как у EMC и заведено. Тем не менее для нас, технарей, важно сохранять трезвый взгляд, и знать не только о достоинствах, но и недостатках продукта, в конце концов CIO отрапортуют на chairman’s board о внедрении и пойдут пить свои коктейли, а нам с этим всем жить.
Поэтому я бы хотел остановиться на некоторых моментах VSAN/VxRail, о которых как-то не слишком говорят в презентации продукта.
Поэтому я и написал нижеследующий пост.

Я уже упоминал это, но обратил внимание, что часто этот факт как-то минует сознание многих.
Есть VSAN 1.0, который работает на vSphere 5.5. Он имеет кучу недостатков, о которых я писал раньше в этом блоге. VMware провела большую работу над ошибками, и выпустила следующую версию, которая стала сразу называться «VSAN 6.0». Однако так как VSAN это модуль ядра, то VSAN 6.0 нельзя поставить на vSphere 5.5. Вам придется обновиться на vSphere 6.0. Все бы ничего, но, к сожалению, качество релиза vSphere 6 «оставляет желать». Многие компании продолжают сидеть на 5.5 + Updates, в ожидании, пока 6.0 стабилизируется. Но если вы не готовы мириться с многочисленными проблемами vSphere 6.0, и при этом нуждаетесь в VSAN, то единственный выход для вас — VSAN 1.0, со всеми ее проблемами.

Если в вашей системе VSAN выходит из строя SSD, то это ведет к прекращению работы всей дисковой группы, в которую входит этот SSD.

Добавить еще SSD в систему можно только в создаваемую новую disk group.

Если disk latency для HDD вырастает, по каким-то причинам, до 50ms, то этот диск выводится из дисковой группы, так как считается неисправным. Если по каким-то причинам для операций ввода-вывода на SSD также вырастает latency до 50ms, то он также выводится из дисковой группы, но при этом, см. выше, прекращает работу вся дисковая группа! Это поправлено в VSAN 6.2, но, например, EMC VxRail — это сейчас VSAN 6.1!

В VSAN отсутствует поддержка VCAI (View Composer API for Array Integration), что может стать проблемой с производительностью при развертывании большого числа VDI-десктопов разом.

Соотношение 70/30 для Read/Write операций в VSAN Cache не изменяемо. Это также может быть проблемой для ряда нагрузок, отличающихся от типичных (пример — VDI, где в типичной среде записей происходит больше, чем чтений).

Максимальный размер Write buffer — 600GB. Остальное место, если оно есть на SSD (сегодня есть SSD уже и 1,2TB), как я понимаю, просто не используется?

По-прежнему используется крайне спорное решение, когда при выходе из строя ноды кластера VSAN система ожидает его возвращения в строй 60 минут (целый час!), и только потом начинает процедуры ребилда информации и состояния системы. Если в течение этого часа для системы с FTT=1 происходит отказ в еще одной ноде, то, как я понимаю, все становится очень плохо.

Дедупликация, компрессия, а также Erasure coding доступно ТОЛЬКО на All-Flash системах, и недоступны на Hybrid-конфигурациях (SSD+HDD).

Официально поддержка SAP Core появилась только в VSAN 6.2, см выше про VxRail, а Oracle RAC и Windows Clustering — только с VSAN 6.1.

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

UPD: Заходите в комментарии, там тоже есть много интересного. Я рад, что мое замечание о намерении избежать FUD-а и оперировать фактами было замечено, очень часто комментарии к подобным статьям не менее важны и содержательны, чем сам пост. Как только я разберусь с приведенными контраргументами, я обновлю пост там, где это он заслуживает.

Что бы вы хотели знать о VSAN и EMC VxRail (но не догадывались спросить;): 15 комментариев

  1. Николай

    Роман, вечер добрый.
    Давайте по порядку :)
    1.) «Я уже упоминал это, но обратил внимание, что часто этот факт как-то минует сознание многих Вам придется обновиться на vSphere 6.0. »
    Мы уже с вами дискутировали на эту тему в вашем прошлом посте, про «недостатки VSAN» и несколько разошлись в оценках критичности данного требования в реальных инсталляциях, так что повторяться смысла особого не вижу. Хотя сюдя потому, что «этот факт как-то минует сознание многих», люди, с которыми вы это обсуждаете, тоже не разделяют вашу панику на этот счет.

    2.) «Если в вашей системе VSAN выходит из строя SSD, то это ведет к прекращению работы всей дисковой группы, в которую входит этот SSD.»
    Да, это действительно так. Но вот встречный вопрос, а что происходит при этом на Nutanix (кроме того, что машины продолжат работать и будут писать на удаленные ноды, но это и у VSAN так), оказался не очень очевидным для меня. Ведь на SSD находится кэш на запись, который мы потеряем, а так же горячие блоки из extent store, плюс у нас есть таблица дедупликации, а так же метаданные Cassandra (на одном из SSD). При этом детального описания последствий и алгоритмов работы ноды при потере одного (именно одного из двух) из SSD нету ни в документах, ни блогах, ни даже в Nutanix Bible (почему-то там ограничиваются сбоем HDD, CVM или всей ноды, ну или фразой «ВМ продолжат работать»). Я думаю это достаточно интересная тема для вашего технического блога. (ну или киньте, пожалуйста, ссылку где почитать)
    Правда удалось прочитать, что при сбое единственной SATA-SSD (с которого грузиться CVM), мы потеряем всю ноду со всеми дисками и SSD (разумеется, с точки зрения хранилища), ибо диски пробросаются напрямую в него. Что в общем-то еще хуже, чем потерять дисковую группу. http://www.nutanix.com/2014/03/24/nutanix-controller-failure-will-users-notice/

    3.) «Добавить еще SSD в систему можно только в создаваемую новую disk group.»
    Ага, а как что-нибудь вообще добавить в Nutanix? HDD, например, если он продается исключительно готовыми коробками as-is?

    4.) «Если disk latency для HDD вырастает, по каким-то причинам, до 50ms, то этот диск выводится из дисковой группы, так как считается неисправным.»
    А вы считаете, что задержки в 50мс на диске- это нормально для продуктивного внедрения? И пусть ОС/приложение еле ползает? И что же тогда делает Nutanix в случае появления таких дисков? Если у устройства задержки более 50мс, то с ним явно какие-то проблемы и может лучше не ждать пока оно сломается совсем, а вывести из эксплуатации заранее? К тому же, если у вас home lab или тестовое внедрение (на том что нашли, исключительно чтобы проверить исключительно функционал), то это значение всегда можно подкрутить: http://cormachogan.com/2015/09/22/vsan-6-1-new-feature-problematic-disk-handling/

    5.) «Это поправлено в VSAN 6.2, но, например, EMC VxRail — это сейчас VSAN 6.1!»
    А вы не могли бы подробнее написать (ну или кинуть ссылку) что именно было поправлено? В открытых источниках у меня не удается найти почему-то. Наоборот, Willam Lam пишет, что на VSAN 6.2 у него по-прежнему работает команда на изменение дефолтного таймаута: http://www.virtuallyghetto.com/2016/03/vsan-6-2-vsphere-6-0-update-2-homelab-on-6th-gen-intel-nuc.html
    Ну и к тому же, последняя на данный момент версия VSAN доступная для скачивания — 6.1. Поэтому EMC использует актуальную и последнюю на данный момент версию. GA VSAN 6.2 ожидается в марте, EMC же обещает наличие dedup/compression (а значит и VSAN 6.2 внутри) на All-Flash, при этом GA VxRail в Q1 (для части конфигураций) и Q2 (для другой части). Таким образом, в худшем случае, задержка будет не более 3-х месяцев. http://virtualgeek.typepad.com/virtual_geek/2016/02/vxrail-an-incredible-product-at-an-incredible-time.html

    6.) «В VSAN отсутствует поддержка VCAI (View Composer API for Array Integration), что может стать проблемой с производительностью при развертывании большого числа VDI-десктопов разом.»
    Никогда не понимал этих заявлений про отсутсвие поддержки VAAI у VSAN. Зачем нужно использовать публичное (а значит стандартизированное, а значит и ограниченное) API, если тоже самое можно сделать и без этого? Да еще и проходит формальную сертификацию? Ведь можно просто «из коробки» сделать внутреннюю интеграцию с ESXi/Horizon ? VSAN же делает свои снэпшоты на базе vsanSparse/VirstoFS без всякого VAAI/VCAI.
    https://www.vmware.com/files/pdf/products/vsan/Tech-Notes-Virtual-San6-Snapshots.pdf
    Кстати, а почему Nutanix не сертифицирован (по крайней мере, формально) под VCAI, хотя поддерживает VAAI Native SS for LC, а не VCAI?
    http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vcai

    7.) «Соотношение 70/30 для Read/Write операций в VSAN Cache не изменяемо. »
    При этом вас не смущает, что у Nutanix кеш на чтение вообще жестко зафиксирован на 20GB? А oplog (буфер на запись) тоже жестко считается строго по формуле (30%/numSSD*RemainingGB)?
    Но на самом деле, конечному пользователю — это совершенно все равно, т.к. различные пропорции и параметры выбираются на основе внутренних алгоритмов работы каждого решения разработчиками. Пользователю важно, как вы правильно заметили, его нагрузки. А в Virtual SAN еще с первой версии можно задавать резервирование кэша на чтения для каждой отдельной ВМ/vmdk (Flash Read Cache Reservation). Это позволяет подстроиться под каждую конкретную нагрузку (write — всегда в кэш, read — любой,от 0 до 100%). Что, кстати, и используется в VDI, когда золотой образ (диск реплики) при создании автоматически ставит значение в 10%, хотя политику всегда можно поменять вручную.

    8.) «Максимальный размер Write buffer — 600GB.»
    Ну да, только вопрос в том, а нужно ли больше? Если мы говорим про Hybrid, то 30%=600GB, 70%=1400GB. Итого SSD может быть до 2TB, что явно более, чем достаточно на текущий момент. Если мы говорим про AllFlash, то если использовать базовое правило кэш=5% от capasity (при FTT=1 для всех ВМ), то получается суммарно Capasity-SSD может быть до 12TB. При 7 дисках в дисковой группе, каждая SSD может быть до 1.7 TB.
    http://www.vmware.com/files/pdf/products/vsan/VSAN_Design_and_Sizing_Guide.pdf

    9.) «По-прежнему используется крайне спорное решение, когда при выходе из строя ноды кластера VSAN система ожидает его возвращения в строй 60 минут (целый час!), и только потом начинает процедуры ребилда информации и состояния системы.»
    Это способ избежать проблем, если наблюдаются, например, короткие сбои в сети. И не начинать сразу ребилды после каждого такого сбоя, а потом делать сразу ресинк, когда хосты появляется обратно. Очевидно же, что это лишняя нагрузка на хосты + сеть. К тому же, если для вас такое решение — спорное, то вы всегда можете поставить меньше: https://kb.vmware.com/kb/2075456

    10.) «Дедупликация, компрессия, а также Erasure coding доступно ТОЛЬКО на All-Flash системах, и недоступны на Hybrid-конфигурациях (SSD+HDD).»
    На мой взгляд, данное решение вполне логично. Жесткие диски имеют проблемы со случайными операциями чтения/записи маленьких блоков, что может быть критично при работе дедупликации/компресии/RAID5/6 в некоторых сценариях, а стоимость SSD под capasity, в свою очередь, продолжает быстро падать:
    a.) Использование дедупликации приводит к тому, что при сбое хоста требуется сделать регидрацию данных для восстановления требуемого количества копий. Регидрация — чтение огромного количества маленьких блоков (у Nutanix это 16K вместо 4K для уменьшения накладных расходов на CPU, пусть и с меньшей эффективностью дедупликации, но принципиально это дела не меняет) с оставшихся копий. Учитывая, что диски плохо работают со случайными маленькими операциями (использование Nutanix’ом oplog на SSD для таких операций это подтверждает), время восстановления копий может быть очень большим, даже при использовании дисков всего кластера. Вероятность того, что блоки будут на SSD тоже не большая, т.к. у ВМ есть куча холодных данных, которые должны уехать на HDD при работе тиринга. Давайте возьмем кластер из 16 3060/3155 нод. У нас будет итого 64 HDD 7200rpm. Если диск выдаст даже в прыжке 100 iops, то это всего 6400 iops блоком 16K (у VMware в 4 раза меньше), т.е. 100 MB/s максимум. Разумеется, часть данных будет в SSD, что несколько ускорит процесс, но и вряд ли мы будем читать/писать именно со всех дисков кластера. Если у нас в ноде 4х4TB диска, то нам нужно восстановить до 16TB данных при сбое одной из них, что займет более 46 часов ( (16*1024*1024/100) / 3600). Поправьте, пожалуйста, если я где-то ошибся с математикой. SSD же, как минимум, в 500 раз быстрее (50k read IOPS c SSD против 100 на HDD).
    b.) С RAID5/6 мысли схожие — RAID-penalty на запись есть всегда (хотя запись всегда идет через SSD-кэш, поэтому это не так важно ), но при сбое узла/диска начинаются penalty на чтение с HDD/CapasitySSD. В AllFlash конфигурации проблем с производительностью на уровне capasity практически никогда нет, поэтому потери не особо заметны, а для HDD многократное увеличение операций чтения может серьезной проблемой из-за малого кол-ва IOPS с каждого из них.
    http://www.joshodgers.com/2016/02/17/erasure-coding-overheads-part-1/

    11.) «Официально поддержка SAP Core появилась только в VSAN 6.2, см выше про VxRail, а Oracle RAC и Windows Clustering — только с VSAN 6.1.»
    А тут, на самом деле, очень забавный парадокс: SAP (кроме HANA) не требует какой-либо сертификации СХД (https://websmp230.sap-ag.de/sap/support/notes/2273806, если нет доступа, то об этом написано тут http://scn.sap.com/docs/DOC-70528). Поэтому любая СХД является «сертифицированной» со стороны SAP, если сертифицирована платформа (vSphere). VMware же, с свою очередь, поддерживает SAP на vSphere тоже без каких-либо ограничений со стороны СХД (она, разумеется, должна быть в HCL) уже очень давно. При этом до появления VSAN 6.2, не было никакой отдельной SAP Note или примечания в каких-либо документах VMware о том, что VSAN 5.5/6.0/6.1 является каким-то исключением из этого правил описанных выше. Поэтому, честно говоря, и до появления VSAN 6.2 я с трудом представляю обоснование отказа от поддержки со стороны SAP или VMware. И только после появления 6.2 такая заметка появилась. Поэтому это жутко смахивает на голый маркетинг и ответ на «сертификацию» SAP от Nutanix.
    С Oracle и MS в общем-то аналогичная история. Ждем отдельной сертификации Apache/Tomcat/MS Office со стороны Nutanix и VSAN ;)

    12.) «Я стремлюсь к тому, чтобы вся информация в этом блоге была максимально достоверной и качественной.»
    IMHO: как мне кажется, было бы намного лучше и полезнее, если бы вы показывали свои сильные стороны, которые, очевидно, есть у Nutanix (разумеется, как и недостатки, но о них вам писать смысла нет), чем проводить необъективные (а обьективных у вас не может быть по определению, т.к. вы участник одного из лагерей) сравнения и указывать на «недостатки» конкурентов, особенно такие.

    1. romx Автор записи

      > Мы уже с вами дискутировали на эту тему в вашем прошлом посте, про «недостатки VSAN» и несколько разошлись в оценках критичности данного требования в реальных инсталляциях, так что повторяться смысла особого не вижу. Хотя сюдя потому, что «этот факт как-то минует сознание многих», люди, с которыми вы это обсуждаете, тоже не разделяют вашу панику на этот счет.

      Николай, это не паника, я в самом деле встречал достаточно людей, которые и правда не придавали значения тому, что для VSAN 2.0 (AKA 6.0) им придется сперва проапгрейдиться на vSphere 6.0 в обязательном порядке. Или мириться с недостатками VSAN 1.0

      Что касается «реальных инсталляций», вы просто посмотрите, сколько (спустя сколько лет после выхода 6.0?) в форумах VMware вопросов про 5.5? На мой взгляд очень много. Это значит, что весьма значительная доля рынка на переход на 6.0 не решилась.

      > а что происходит при этом на Nutanix

      В случае одного SSD на ноде — да, на SSD соседней ноды или миграция VMs. Но один SSD на ноду у Nutanix только у самых младших моделей, NX-1000, и еще у специальных, 6000-х (6035С). У всех остальных — 2 и более. Дисковая группа данной ноды (например SATA) не прекращает работать.

      > Ага, а как что-нибудь вообще добавить в Nutanix? HDD, например, если он продается исключительно готовыми коробками as-is?

      Никак. Мы просто делаем следующий шаг, и не предлагаем такого варианта. А вот покупателей VSAN это может удивить, ведь формально такое действие нет ограничений, самосбор же?

      > А вы считаете, что задержки в 50мс на диске- это нормально для продуктивного внедрения? И пусть ОС/приложение еле ползает?

      Да нет, проблема не в том, что диск выводится, проблема что при ситуации, когда по такому условию выводится SSD, он уносит с собой всю группу, вот это проблема, об этом я пишу.

      > А вы не могли бы подробнее написать (ну или кинуть ссылку) что именно было поправлено? В открытых источниках у меня не удается найти почему-то.

      Постараюсь найти, это я увидел в отзыве практика, исследовавшего VSAN, спрошу у него.

      > Ну и к тому же, последняя на данный момент версия VSAN доступная для скачивания — 6.1.

      Нет, мне понятно, почему EMC использует VSAN 6.1. Но в свете выхода и активного раскручивания VSAN 6.2 в новостях, покупатели EMC могут ожидать именно ее, а не 6.1. Они же покупают новую, передовую, самую новейшую систему, и вдруг в ней «старый» VSAN с «неисправленными» багами. Цель-то поста в этом — перечислить слабоизвестные и неочевидные особенности.

      > Кстати, а почему Nutanix не сертифицирован (по крайней мере, формально) под VCAI, хотя поддерживает VAAI Native SS for LC, а не VCAI?

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

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

      Николай, боюсь показаться вам резким, но в этом блоге, который мой личный блог, я сам решаю, что я пишу, и сам выбираю темы. Так что «Спасибо вам за ваше мнение» (с) ;)

      1. Nikolay

        Роман,

        >>я в самом деле встречал достаточно людей, которые и правда не придавали значения тому, что для VSAN 2.0 (AKA 6.0) им придется сперва проапгрейдиться на vSphere 6.0

        Просвещение конечных пользователей — это всегда хорошо, здесь я с вами полностью соглашусь.
        Единственное, что хотелось бы дополнить, что внедрение VSAN 6.0/6.1/6.2 не подразумевает обновление всего ЦОД на vSphere 6.0 по умолчанию. C точки зрения VMware, VSAN — это просто еще один кластер в инфраструктуре, которая может быть в десятки и сотни кластеров. Ничто не мешает сделать новый кластер (например, management, DMZ, VDI, кластер какого-то подразделения или приложения (например, Oracle Cluster), DR/DA кластер и т.д.) на vSphere 6.0, а имеющиеся кластера оставить на текущих версиях ESXi под уже купленными СХД. Ведь управление-то все равно одно всей инфраструктурой (и под VSAN, и под SAN/NAS)- vCenter. На мой взгляд, это несколько отличает подходы VMware и Nutanix (которые, ИМХО, ближе к концепции «всё или ничего»)

        >>В случае одного SSD на ноде — да, на SSD соседней ноды или миграция VMs. Но один SSD на ноду у Nutanix только у самых младших моделей, NX-1000, и еще у специальных, 6000-х (6035С). У всех остальных — 2 и более. Дисковая группа данной ноды (например SATA) не прекращает работать.
        Вот тут хотелось бы по-подробнее, если можно (ну или ссылку). Во-первых, из Nutanix Bible: «Cassandra is on the first SSD by default, and if that SSD fails the CVM will be restarted and Cassandra storage will then be on the 2nd.» Т.е. если нам «повезет» и выйдет из строя SSD c метаданными, то это будут перезагрузка CVM (см. CVM Failure)? Кстати, интересно, а Nutanix в таком случае, сразу начнет ребилд всей ноды?
        А так же, что происходит с размерами остальных компонентов OpLog/Cache/Extent на живом SSD — они меняются при сбое или остаются такими же? Из-за уменьшения отношения SSD/HDD в два раза, не приводит ли это к значительно большим cache-miss на чтении и более медленному сбросу данных на запись на диски? В общем, вопросы есть, а ответов найти не могу.

        >>А вот покупателей VSAN это может удивить, ведь формально такое действие нет ограничений, самосбор же?
        Ограничения есть всегда и любой нормальный человек это понимает. Для этого есть список совместимости и Configuration Maximums. Иначе мы дойдем до того, что в обычный 2U сервер, оказывается, нельзя поставить больше 24 дисков, хотя VSAN поддерживает до 35+5.
        Поэтому даже формально, такое ограничение есть. В одной дисковой группе — одна SSD, см, например, Administration Guide или тот же Configuration Maximums.
        Но только вот в чем проблема добавить SSD и перераспределить имеющиеся HDD по новым дисковым группам?

        >>Постараюсь найти, это я увидел в отзыве практика, исследовавшего VSAN, спрошу у него.
        Уже после написания комментария, появилась статья у Cormac Hogan на этот счет. Суть — VSAN 6.2 делает unmount диска только если диск из Capasity Tier и задержки на запись превышают порог. При этом, наоборот, появился advanced setting, который позволяет делать unmount SSD диск при превышении порога. Плюс появился второй алгоритм, который следит за сбоями IO на дисках.
        Не смотря на это, мое мнение, что VMware излишне перестраховывается таким образом. Длительные, аномально высокие задержки на любом устройстве (SSD/HDD) — явный признак проблем с ним.
        В любом случае, данная, с вашей точки зрения, проблема с выходом VSAN 6.2 не актуальна, а для тех, кому это не нравится, как мне — оставлены Advanced Settings. Все счастливы :)

        >>Нет, мне понятно, почему EMC использует VSAN 6.1

        Просто потому, что до вчерашнего дня ничего другого просто не было. И учитывая, что, вряд ли кто-то разместит заказ на VxRail в день анонса (т.к. в enterprise так дела не делаются — одна конкурсная процедура в РФ занимает 1-2 месяца) и с учетом стандартных сроков поставки железа 6-8 недель у вендоров, к заказчику приедет железка в Q2. Когда EMC уже обещает доступность VSAN 6.2 в VxRail. Так что вероятность сценария, когда заказчику приезжает старый VSAN в VxRail — на практике, стремиться к нулю.

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

        Судя по тому, что в списке сертифицированных СХД есть Trinti и Atlantis USX, Nutanix вполне должен пройти по формальным причинам.
        Но неужели вам первый раз задают этот вопрос? Это же очевидно — вы много где говорите/пишите, что поддерживаете VCAI, я смотрю список совместимости VCAI и не нахожу там Nutanix. От сюда и вопрос. Хотя я и не исключаю, что у Nutanix просто руки не дошли, как и всех остальных вендоров, которые поддерживают Native Snapshot for LC, но не поддерживают VCAI.

        >>Николай, боюсь показаться вам резким, но в этом блоге, который мой личный блог, я сам решаю, что я пишу, и сам выбираю темы. Так что «Спасибо вам за ваше мнение» (с) ;)
        Роман, прошу прощения, если случайно вас обидел. Я прекрасно понимаю, что это ваш блог и вы сами решаете, что в нем писать, поэтому я вовсе не пытаюсь «научить вас жить». Это был, скорее, feature request, потому что изучая что-то в Nutanix, порой сложно найти нужную информацию, отличающуюся от стандартной, а вот FUD’a в сети предостаточно. SSD-failure, VCAI, Nutanix disk unmount и т.д. — примеры, только из этого поста.

  2. omnimod

    Спасибо, пополню свою копилку FUD’а, если когда-нибудь придется VSAN гнобить. Для «объективности» могу немного позащищать Virtual SAN. :)

    >Добавить еще SSD в систему можно только в создаваемую новую disk group.
    А чтобы добавить SSD в Nutanix надо купить еще одну ноду?

    >В VSAN отсутствует поддержка VCAI (View Composer API for Array Integration)
    Учитывая, что VCAI поддерживается только для NFS, а VSAN — это не NFS, то немудрено. Кстати, по ссылке http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vcai Nutanix тоже нет в списке.

    >Максимальный размер Write buffer — 600GB
    Это максимальный размер на одну дисковую группу. С учетом того, что кэш на запись составляет 30% от объема SSD, объем SSD должен быть >2 ТБ, чтобы упереться в данное ограничение.

    > при выходе из строя ноды кластера VSAN система ожидает его возвращения в строй 60 минут
    Это значение по умолчанию, которое может быть изменено (ClomRepairDelay).

    1. romx Автор записи

      >>Добавить еще SSD в систему можно только в создаваемую новую disk group.
      >А чтобы добавить SSD в Nutanix надо купить еще одну ноду?

      Да, то есть мы и не обещаем такого финта, а вот VSAN, который типа «самосбор», такое формально как бы и не запрещает, но по факту — это невозможно. И это может быть неприятным сюрпризом для сборщика VSAN. Мы в этом смысле сразу делаем следующий шаг, и не обещаем, и не делаем :)

      >>В VSAN отсутствует поддержка VCAI (View Composer API for Array Integration)
      > Учитывая, что VCAI поддерживается только для NFS, а VSAN — это не NFS, то немудрено. Кстати, по ссылке http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vcaihttp://www.vmware.com/resources/compatibility/search.php?deviceCategory=vcai Nutanix тоже нет в списке.

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

      >>Максимальный размер Write buffer — 600GB
      > Это максимальный размер на одну дисковую группу. С учетом того, что кэш на запись составляет 30% от объема SSD, объем SSD должен быть >2 ТБ, чтобы упереться в данное ограничение.

      Да, спасибо за уточнение. Но у нас уже топовая NX-3000 достигает этого предела, а у нас есть еще NX-8000 c 4 SSD и AllFlash системы.

      >> при выходе из строя ноды кластера VSAN система ожидает его возвращения в строй 60 минут
      > Это значение по умолчанию, которое может быть изменено (ClomRepairDelay).

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

      1. Nikolay

        Роман,
        >>Да, то есть мы и не обещаем такого финта, а вот VSAN, который типа «самосбор», такое формально как бы и не запрещает, но по факту — это невозможно.
        Добавить HDD можно, если дисковая группа изначально не забита под завязку? Можно. Добавить целую дисковую группу можно? Можно. Добавить SSD и перераспределить HDD по дисковым группам можно (причем для этого нужно просто сделать несколько кликов в веб-клиенте vSphere)? Можно. Добавить бездисковую ноду можно? Можно.
        Таким образом, возможность (и формальная, и фактическая) есть, хотя, разумеется, есть технические ограничения.
        Вы правда в ваших competitive разговорах с заказчиками используете формулировки «у конкурента X есть ограничения в реализации Y, правда, у нас всё еще хуже, т.е. никак»? Серьезно?

        >>Да, спасибо за уточнение. Но у нас уже топовая NX-3000 достигает этого предела, а у нас есть еще NX-8000 c 4 SSD и AllFlash системы.
        Как бы нет.
        600GB — ограничение ТОЛЬКО кэша на запись на SSD в каждой дисковой группе (о чем я вам писал в прошлом комментарии, который, кстати, ждут размещения уже почти две недели). Аналог у Nutanix — OpLog, который, вроде, максимум 100GiB на ноду (при любом количестве SSD и их максимального размера, согласно Nutanix Disk Usage Calculator).
        Для Hybrid, где отношение Write/Read space 30/70% для каждой отдельной кэширующей SSD, это означает, что SSD может быть до 2TB. Напомню, что Nutanix предлагает максимум 1.6 TB
        Для All-Flash, рекомендуемое отношение Cache-SSD к суммарному объему Capasity-SSD в рамках дисковой группы — 5% (для всех ВМ с FTT=1), таким образом, получаем, 12 TB на 7 дисков = 1.7 TB на SSD. Ну или 3 SSD по 4TB, например. Nutanix, опять же, предлагает максимум 1.6 TB и только 6 дисков (вместо 7+1 на дисковую группу умножить на кол-во дисковых групп (до 5) )

        >>Да, спасибо, хорошо, что это можно изменить, но эту особенность нужно помнить.
        Ну как бы, при проектировании/введении в эксплуатацию это надо просто один раз выбрать и всё (если значение по умолчанию не устраивает). Тем более, что это ни разу не секрет и достаточно прочитать KB2075456 или одну из десятков записей в блогах.

        >>Тем более, что не зря эта величина там такая стоит, не из пальца же она высосана.

        В той же KB и написано откуда оно берется:

        Installation of ESXi updates (if performing updates)
        ESXi host boot time (Including Power On Self Test)
        SSD Log recovery for Virtual SAN

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

        1. Maxim

          «строй за 60 минут и ребилд на самом деле не нужен.»

          зачем лукавить? все проще — при ребилде производительность VSAN уходит в ноль (буквально) — на тестах наших VM гостевые получают I/O error.

          почему? потому что нет data locality, и при ребилде 2x10G забиваются полностью на ребилд.

          ждать 60 минут «а вдруг нод вернется» — крайне глупое занятие, ввиду того что при легитимном выключении нода _это известно_. Или VMware не смогли догадаться нотифицировать менежмент стек о том что нод легитимно выключается / перегружается??

          Остальные «аргументы» примерно такого-же уровня качества

          «Добавить SSD и перераспределить HDD по дисковым группам можно (причем для этого нужно просто сделать несколько кликов в веб-клиенте vSphere)? Можно. Добавить бездисковую ноду можно? Можно.»

          В теории — да. На практике, любой «ребилд» (или расширение) — VSAN просто ложится. Наглухо. На многие часы обычно. В отличии от VMware, мы если анонсируем какой-то функционал — то он работает и его можно реально использовать под боевыми нагрузками.

          p.s. «Аналог у Nutanix — OpLog, который, вроде, максимум 100GiB на ноду (при любом количестве SSD и их максимального размера, согласно Nutanix Disk Usage Calculator)» — не читайте советских газет на ночь. Oplog размазывается по SSD и считается в %.

          Ну и не надо сравнивать _кэш_ с полноценным тирингом. Я понимаю желание притянуть осла за уши, но тут немного другой случай.

        2. romx Автор записи

          > Ну как бы, при проектировании/введении в эксплуатацию это надо просто один раз выбрать и всё

          Перед этим надо во-первых, знать о этой засаде. И именно это причина, почему я это перечислил в посте. Во-вторых, надо быть достаточно компетентным, чтобы оценить и выбрать верное значение. Многие сисадмины исходят из (вполне разумной) позиции, что «если не знаешь что это — не меняй значения по умолчанию». И это обычно работает.
          Я понимаю, что стояло за выбором идеи дать возможность ноде вернуться в строй без запуска ребилда. Но не вполне ясна причина выбора такого интервала. VMware считает, что риски того, что за время «60 минут, плюс время завершения ребилда» произойдет еще один отказ ноды — исчезающе низки и это можно проигнорировать? К тому же, как указал Maxim вчера, большой срок до начала ребилда на сильно загруженной системе приводит к накоплению большого объема изменений, что вызывает повышенную нагрузку на сеть (и, как следствие, может влиять на обработку workload traffic).

          1. Nikolay

            Роман,
            >>Перед этим надо во-первых, знать о этой засаде. И именно это причина, почему я это перечислил в посте. Во-вторых, надо быть достаточно компетентным, чтобы оценить и выбрать верное значение. Но не вполне ясна причина выбора такого интервала. VMware считает, что риски того, что за время «60 минут, плюс время завершения ребилда» произойдет еще один отказ ноды — исчезающе низки и это можно проигнорировать?
            Я с вами согласен про компетентность. И при этом я не считаю, что я более компетентным, чем целая компания типа VMware. Поэтому значению по умолчанию я вполне доверяю. А по каким критериям и как вы оцениваете вашу собственную компетенцию относительно компетенции самих разработчиков продукта?
            Причина выбора интервала есть в KB (время обновления HW/ESXi или сбой сервера + перезагрузка + запас) и, я думаю, VMware знает сколько это может занимать.
            Насчет рисков — это вопрос вероятности и статистики. К сожалению, я не могу найти публичных данных по доступности современных x86 серверов и их отдельных компонентов, но при этом, скорее всего, у вендоров эти данные есть. Поэтому я думаю, что VMware учитывала риски многократных сбоев при выборе такого решения. Если у вас есть какая-то статистка на этот счет или информация, которая это опровергает, то, пожалуйста, поделитесь — будет интересно посчитать.

            >>К тому же, как указал Maxim вчера, большой срок до начала ребилда на сильно загруженной системе приводит к накоплению большого объема изменений, что вызывает повышенную нагрузку на сеть (и, как следствие, может влиять на обработку workload traffic).
            Это не так. Смотрите, пусть есть ВМ с 100GB диском (FTT=1, stripe=1), заполненным на 50% и пусть за 60 минут ВМ переписывает 50% своих данных. Если мы начинаем ребилд сразу после сбоя, то там надо скопировать 50GB (ибо VSAN всегда thin). А если мы начали ребилд через 60 минут, то там надо все равно скопировать ровно 50GB данных, пусть и других. Но какая разница какие данные копировать? Ни на время ребилда, ни количество передаваемого данных, ни на нагрузку на сеть это никак не влияет.

    2. Maxim

      » а VSAN — это не NFS, то немудрено. » вы этим гордитесь? Сторонний продукт сторонней компании, фактически первая версия ПО, которая не поддерживает базовых протоколов акселерации и за счет этого в сотни раз дольше создает (например) клонированные виртуальные машины?

      Ну а про Nutanix + VCAI на самой же VMware писали еще в 2012 году ;) Когда VSANом и не пахло.

      Ибо мы поддерживаем 5.1 и выше, в отличии от VMware которая пытается заставить клиентов перейти на 6-ку чтобы наконец показать прелести первой худо-бедно рабочей версии VSAN

      http://blogs.vmware.com/vsphere/tag/vcai

      «NFS VAAI
      Nutanix have implemented the VAAI NFS Full Copy & File Clone primitives in this release. Nutanix/VMware VDI customers will be able to leverage VMware’s upcoming VMware View Composer Array Integration (VCAI) feature which is in tech preview for VMware View 5.1.»

      1. Nikolay

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

        >> зачем лукавить? все проще — при ребилде производительность VSAN уходит в ноль (буквально) — на тестах наших VM гостевые получают I/O error.
        Пруф, пожалуйста.
        С моей стороны, я готов предоставить следующее подтверждение, что вы не правы. Открываем документ «VMware Virtual SAN Stretched Cluster: Performance and Best Practices» (я специально не вставляю ссылки, чтобы комментарий разместился сразу), смотрим пункт «Single Disk Failure» и видим следующее:
        IOPS на ноду до сбоя ~19k.
        IOPS на ноду после сбоя HDD ~ 16k
        Время ребилда ~ 54 минуты
        Трафик ребилда ~15 MB/s в среднем с пиком в 33 MB/s
        IOPS после ребилда ~17k (т.к. потеряли один HDD)
        Теперь смотрим сбой всего сайта:
        OPM per VM до сбоя — 10k
        OPM per VM во время сбоя — ~10k
        OPM per VM при восстановлении ~9k
        Трафик при этом 310MB/s на протяжении 8 минут
        OPM per VM после восстановления ~10k

        >>почему? потому что нет data locality, и при ребилде 2x10G забиваются полностью на ребилд.
        Вообще-то, VSAN использует один vmkernel интерфейс, поэтому что вы делаете в своих тестах, чтобы забить еще и второй 10Gb линк — крайне интересно.
        И причем тут Data locality? Ребилд происходит практически со всех нод (т.к. объекты более-менее равномерно распределяются по всему кластеру) на все ноды. Именно потому, что никакого locality нет. При этом RDT — peer-2-peer протокол и все ноды общаются между собой напрямую. Таким образом, если у нас есть хотя бы 10 серверов в кластере с 10GbE, то мы получаем 100Gb/s пропускной способности или 12.5GB/s. Таким образом, «за много часов» (пусть хотя бы 2) мы можем скопировать 87 TB данных. Не слишком ли много для одной ноды?
        >>Или VMware не смогли догадаться нотифицировать менежмент стек о том что нод легитимно выключается / перегружается??
        Конечно может. Для этого смотрите Enter Maintenance Mode c VSAN. Только вот вопрос, как узнать прошло ли у нас все нормально при этом? Т.е. выключили-то мы легитимно, но значит ли это, что мы гарантированно вернемся в строй через X минут? Поэтому и есть Full Data Migration/Ensure Accessibility при переходе в Maintenance Mode.

        >>Остальные «аргументы» примерно такого-же уровня качества
        Если вам есть что сказать, я с удовольствием выслушаю ваше обоснованное и подкрепленное ссылками и документами мнение.

        >>На практике, любой «ребилд» (или расширение) — VSAN просто ложится. Наглухо. На многие часы обычно.
        Пруф, пожалуйста. Ну и см. выше.

        >>В отличии от VMware, мы если анонсируем какой-то функционал — то он работает и его можно реально использовать под боевыми нагрузками.
        Я не очень это люблю, но раз пошли такие аргументы, то расскажите, пожалуйста, как работает ваш Metro Сluster сейчас и, особенно интересно, как он работал c момента анонса в версии 4.1 до версии 4.6.

        >>не читайте советских газет на ночь. Oplog размазывается по SSD и считается в %.
        Это вы сейчас про Nutanix Bible, где на двух описанных примерах с SSD на 400GB и для 800 Oplog=100GB или Nutanix Disk Usage Calculator, который рекомендовал Роман в прошлом посте и который показывает максимальный размер OpLog при любом размере SSD в 100GB?
        В любом случае, если мы говорим про формулу 30%/numSSD*remaining space, то получается, что при максимально размере SSD у Nutanix в 1.6 TB и двух SSD в ноде, получается OpLog менее 240GB. Напомню, что претензия была в ограничении кэша на запись у VSAN в 600GB на SSD.
        Вторая претензия была в том, что отношение кэша на чтение к кэшу на запись — ровно 30% от доступной полезной емкости SSD (у VSAN — это вся SSD) и его нельзя поменять. Забавно получается, что у Nutanix это отношение равно ровно 30% или 15% (в зависимости от количества SSD) относительно доступной полезной емкости SSD (у Nutanix — SSD минус CVM-home+Cassandra metadata)
        В-третьих, все остальные расчеты, показывающие, что, на текущий момент, кэш на запись более 600GB не имеет практического смысла в силе.

        >>>Ну и не надо сравнивать _кэш_ с полноценным тирингом. Я понимаю желание притянуть осла за уши, но тут немного другой случай.
        Хм… Изначально вопрос был в кэше на запись у VSAN. У Nutanix кэш на запись — OpLog: «Key Role: Persistent write buffer»
        Поэтому причем тут осел и его уши — не очень ясно.

    3. Maxim

      По поводу VCAI я кажется понял.

      Дело в технической неграмотности собеседника…

      Дело в том что если «СХД» поддерживает VAAI — то это автоматически означает поддержку VCAI, ибо фактически это одно и то-же (VCAI это название технологии со стороны композера)

      «Horizon View 5.1 introduced VCAI as a Tech Preview feature that enabled customers to try VCAI with partner storage systems that support VAAI »

      «What are the steps to enable VCAI?

      See Using View Composer Array Integration with Native NFS Snapshot Technology (VAAI) in the VMware Horizon View Administration document for information about enabling and using VCAI.»

      https://pubs.vmware.com/view-51/topic/com.vmware.view.administration.doc/GUID-61ABF143-EE88-4688-AD84-056EBD0B918B.html

      http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=san&productid=39050&vcl=true

      «VAAI-NAS Native SS for LC, Space Reserve, File Cloning, Extended Stats nfs-vaai-plugin 2.0-5dfbc550»

      1. omnimod

        Максим, я нигде не говорил о том, что Nutanix не умеет в VAAI Native SS for LC. VMware поддерживает крайне ограниченный список СХД для VCAI, который я привел по ссылке выше. Nutanix может работать с VCAI, но со стороны VMware это будет неподдерживаемое решение.
        https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2061611

      2. Nikolay

        Максим,
        >>Сторонний продукт сторонней компании, фактически первая версия ПО, которая не поддерживает базовых протоколов акселерации
        Не базовых, а внешних протоколов акселерации. VSAN, разумеется, не поддерживает VAAI Native Snapshots for LC, но при этом, когда вы делаете «обычный» снепшот из vSphere делается VSANsparce снепшот (нативный для VSAN) вместо vmfsSparce. Вы можете почитать об этом в документе «vsanSparse — Tech Note for Virtual SAN 6.0 Snapshots». Таким образом, реализуется ровно тот же функционал без всяких VAAI.

        >>и за счет этого в сотни раз дольше создает (например) клонированные виртуальные машины?
        Вы имеете ввиду Nutanix Fast Clone? Это мне, если честно, напоминает самоуправляемый самокат — если я хочу сделать Full Clone, то я ожидаю полного клона, а не Linked на уровне СХД, со всеми вытекающими. И все СХД, поддерживающие VAAI File Cloning делают именно это. А если я захочу сделать Linked Clone, то я сделаю именно его из vCenter. Более того, если мне понадобиться сделать Instant Clone, то я точно так же сделаю его из vCenter. Я хочу, чтобы система вела себя так, как я прошу её это сделать, а не устраивала самодеятельность.

        >>Дело в технической неграмотности собеседника…
        >>Дело в том что если «СХД» поддерживает VAAI — то это автоматически означает поддержку VCAI, ибо фактически это одно и то-же (VCAI это название технологии со стороны композера)
        А мне кажется, что дело в умении читать на английском и здравом смысле. Есть отдельная сертификация под VCAI — при этом она более-менее актуальна, т.к. есть сертификации под Horizon 6.0. И Nutanix в этом списке нет, что позволяет мне сделать вывод, что Nutanix не поддерживает VCAI (хотя, может быть, он и работает). Более того, если мы перейдем по вашим же ссылкам на блоги VMware, то видим следующее:
        The following components are required for operationalizing the use of VCAI:

        VMware View 5.1
        VMware vSphere 5.0 or later
        NAS storage array that supports VAAI – The array needs to be certified for VAAI NAS primitives. Please consult your storage array vendor documentation on whether the storage hardware model and storage software version support the VAAI NAS native snapshot capability.
        NAS storage array vendor software plug-in on each vSphere server in the View Cluster.

        Т.е. по-мимо VAAI необходим какой-то плагин в каждый vSphere сервер. Может быть всё дело в нём? Кстати, в KB2061611 написано:
        The supported storage systems above have run a series of tests specified by VMware by using a combination of VMware Horizon View 5.3 and later, vSphere 5.1 or later, and the storage partner plugin (VAAI NAS plugin). The tests are intended to verify the interoperability of VCAI, vSphere, and the partner plugin. The tests cover the typical Horizon View desktop administration operations such as provisioning, refresh, recompose, and rebalance of 2000 View desktops.
        В свою очередь тесты на VAAI Native Snapshots не включают в себя тесты эти операции для 2000 десктопов. Там достаточно показать, что снепшоты делаются. Может быть всё дело в том, что Nutanix просто не делал необходимые тесты?
        В любом случае, если бы написали про то, что Nutanix поддерживает VAAI, то вопросов нет. Если вы пишите, что Nutanix поддерживает VCAI, то, пожалуйста, подтвердите это ссылкой на HCL.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *