SSD на 3.8TB в Nutanix

С сегодняшнего дня у Nutanix появились доступные к заказу диски SSD емкостью 3.8TB (иногда их называют «4TB», но будем занудно-точными;). Это отличная новость, и, дайтобох, не последняя, потому что на горизонте уже диски SSD на 16TB (!), которые начал делать Samsung, и на которые уже облизывается весь дисковый энтерпрайз. Будут. Не сейчас, но скоро. А пока — новые диски, которые все более ясным делают поворот индустрии в целом, и Nutanix в частности, в сторону AllFlash систем. Уже сегодня AllFlash конфигурация у нас может быть совсем незначительно дороже, чем та же по объему дисков конфигурация но в гибридном виде, HDD+SSD, а плюсов довольно много.

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

UPD:
35 usable TB в 2U на 4 нодах в AllFlash!

2016-08-10_09-23-36

SSD на 3.8TB в Nutanix: 30 комментариев

  1. Yahont

    Добрый день, у Нутаникса очень интересная технология кэширования. : OpLog — кэш на запись (постоянный буфер записи) и Unified Cash — кэш на чтение. Но это все расчитано на использование в гибриде, когда SSD-кэш ускоряет медленные HDD. А как будет работать кэш в ваших all-flash узлах?

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

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

      1. yahont

        Я почему спросил — потому что vSan ВМварин на олфлэше использует выделенный диск под write-cash в дисковой группе.
        All-flash clusters have two types of flash: very fast and durable write cache, and more capacious and cost-effective capacity flash. Here cache is 100% allocated for writes, as read performance from capacity flash is more than sufficient. Many more writes are held by the cache and written to the capacity layer only when needed, extending the life of the capacity flash tier.
        В таком подходе есть логика.
        У вас тоже под кэш будут выделяться более быстрые и долгоживущие SSD? Или все SSD узла будут одинаковы?

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

          > vSan ВМварин на олфлэше использует выделенный диск под write-cash в дисковой группе.

          Да, но у нас другая организация использования дисков, у них SSD это кэш, а у нас — полноценный tier хранения.

          > У вас тоже под кэш будут выделяться более быстрые и долгоживущие SSD? Или все SSD узла будут одинаковы?

          Они все одинаковые, быстрые и долгоживущие.

          1. yahont

            просто если все носители одинаковые по характеристикам, то какой смысл в кэше? просто логика работы oplog и unified cash чтобы сохранялась?

  2. yahont

    Добрый день. Помогите разобраться в том как произволится запись основной копии данных на локальный узел и их репликация на удаленные узлы. Для простоты рассмотрим вариант RF=2.
    Свое представление я формировал по данным с оф. сайта, The Nutanix Bible и публикациям Нутаникса на русском (ваш сайт и на хабре).

    1. Везде написано, что в репликации участвуют все узлы кластера. Но есть пара утверждений, чтоданные пишем на целевой узел локально, а реплику пишем на другой узел. Про OpLog тоже написано, что реплика уходит на 1 удаленный узел, просто узлы выбираются произвольно и нагрузка распределяется.
    Так вот непонятно: мы имеем 2 реплики на 2х узлах, в смысле основной экстент и его реплика на 1 удаленном узле (тогда каким боком тут участвует весь кластер) или реплика размазывается по всем узлам кластера (кроме того где записан основной экстент) в виде сетевого raid-0, т.е страйп из N-1 кусочков, где N = число узлов кластера?

    2. Непонятно как пишется экстент на локальный узел (основная копия данных). Он пишется на 1 локальный диск или raid-0 по всем локальным дискам узла? Или можно выбрать так или эдак?

    Ну и реплики соответственно пишутся на 1 локальный диск удаленных узлов или также raid-0 по всем локальным дискам (сетевой_raid-0+локальный_raid-0)?

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

      > Везде написано, что в репликации участвуют все узлы кластера

      да, это так.

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

      И это верно, не вижу противоречий тут, поясните, что вас смутило.

      > Так вот непонятно: мы имеем 2 реплики на 2х узлах, в смысле основной экстент и его реплика на 1 удаленном узле

      Верно.

      > (тогда каким боком тут участвует весь кластер)

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

      > или реплика размазывается по всем узлам кластера (кроме того где записан основной экстент) в виде сетевого raid-0, т.е страйп из N-1 кусочков, где N = число узлов кластера?

      Нет, реплика не страйпится. Операции — страйпятся, а блок записи — нет, он целиком попадает на какую-то конкретную ноду.

      > 2. Непонятно как пишется экстент на локальный узел (основная копия данных). Он пишется на 1 локальный диск или raid-0 по всем локальным дискам узла? Или можно выбрать так или эдак?

      На один диск, диски просто физические диски вида /dev/sda1, /dev/sdb1 и так далее, никак не объединенные в самом CVM. Они соединятся в общую логическую структуру хранения уже уровнем выше, когда соберутся в NDFS и когда презентуются в гипервизор как контейнер-датастор.

      Точно также и на удаленной ноде.

  3. yahont

    Спасибо большое, теперь все стало понятно!

    Только 1 момент про raid-0, вот абзац из документа Nutanix_Tech_Notes_Performance:
    All disks on a particular tier are leveraged by the local Controller VM for I/O. This
    distribution of writes fully utilizes the bandwidth available for all disks, for both reads and writes. It also provides ‘RAID-0 like’ level performance, but without the downside risk of an entire node becoming unavailable if a single disk failure occurs.
    Каким образом мы получаем ‘RAID-0 like’ производительность, но при этом не теряем данные ноды при отказе 1 диска?
    Вот есть у нас vDisk, он соотвтствует диску ВМ, которая крутится на данной ноде. Если данные внутри ноды не страйпятся, то файл VMDK (vDisk) будет целиком лежать на 1 HDD (если размер HDD его вместит?
    This distribution of writes fully utilizes the bandwidth available for all disks — как это реализовано если данные не страйпятся? Или тут что-то другое имелось ввиду?

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

      > Каким образом мы получаем ‘RAID-0 like’ производительность, но при этом не теряем данные ноды при отказе 1 диска?

      Потому что диски все используются под запись, но одна операция записи — атомарна, и попадает только на один диск, не страйпится.

      > Вот есть у нас vDisk, он соотвтствует диску ВМ, которая крутится на данной ноде.

      Нет, не обязательно, один vmdk может состоять из нескольких vDisk Nutanix.

      1. yahont

        Дак есть распараллеливание записи на все диски узла или нет? Если на узле количество ВМ равно количеству дисков, то наверное все будет распараллелено и одновременно запись будет идти на все диски? А если на узле всего 1 ВМ, то как?

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

          > Дак есть распараллеливание записи на все диски узла или нет?

          Насколько я знаю — нет.

          > Если на узле количество ВМ равно количеству дисков

          Один файл виртуального диска VM может лежать больше чем на одном vDisk у Nutanix. И вот они уже могут быть на разных HDD.

  4. yahont

    Добрый день, подскажите ещё про настройку сети, в частности для Вари. Я все перелопатил, тольком ответов не нашел.

    1. В мануалах на картинках настроек сети Вари рисуют: vSwitchNutanix standard virtual switch — причем у него нет физических сетевух. Это что такое? там 2 группы портов именами iSCSI-pg. это datapath между esxi и cvm (локально внутри хоста)? она по iSCSI работает?
    2. Везде написано то для вари рекомендуется использовать NFS, но почемуто на тех же картинках, нет группы портов со словами NFS, есть группа портов Nutanix — vlan 10 (что это?), также группы под управление, vmotion, FT, трафик VM, но NFS нет.
    3. Как работает auto-path? В мануале написано что для Вари необязательно настраивать вирткальный IP для кластера, а как тогда? Вы пишете что у вас распределенное хранилище, а каждая CVM является точкой доступа к нему, как это реализовано с точки зрения IP адресов и их переключения на случай падения локальной CVM (Если у меня локальная CVM упала или патчится, как ВМ с этого узла достучатся до DSF)?
    Пока не поднимется локальная CVM — ВМ данного узла будут вести в/в со всем множеством узлов где разбросаны реплики или путь пойдет к локальным данным узла, но через удаленную CVM?

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

      Ну как-то у вас все больше вопросов, и все длиннее :)

      Начну с конца. Про auto-path поищите в nutanixbible.com строку «192.168.5» (она там несколько раз встречается) и вокруг нее почитайте. Это наша внутренняя подсеть CVM-ов, обеспечивающая все это.

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

      По первому и второму вопросам так написано, что ничего не понятно. )

      1. yahont

        Ладно. Вот есть хост ESXi, нам надо ему настроить сети, заходим в соответствующие настройки, там можно под разный трафик и подсети создать отдельные vSwitch (к ним привязываются физические порты Eth) или группы портов внутри vSwitch.
        Так вот, смотрю я ваш мануал: Nutanix_TechNote-VMware_vSphere_Networking_with_Nutanix. Там есть картинки с описанием этих настроек.
        1. есть отдельный vSwitch под названием «vSwitchNutanix standard virtual switch» — у него нет физических сетевух. Что он делает? Там 2 группы портов с именами «iSCSI-pg». Это datapath между esxi и cvm (локально внутри хоста)? Она по iSCSI работает?
        2. Есть еще 1 vSwitch, на нем много групп портов: Nutanix — vlan 10 (что это за сеть?), также группы под управление, vmotion, FT, трафик VM, но NFS нет. Везде написано, что для вари рекомендуется использовать NFS в вашей инфраструктуре, но такой группы портов (с таким именем) я на картинке не нашел.
        Т.е. мне не понятно как правильно на уровне ESXi настроить сетевое подклюсение к хранилищу вашему. Вроде как нужно 2 отдельные сети: одна для локального доступа к хранилищу узла, вторая — для репликации и взаимодействием с DSF (остальные узлы кластера).

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

          К хранилищу не надо подключаться отдельно, оно и так уже подключено после установки ESXi в ходе инсталляции Nutanix. Забудьте о сторадже, он уже подключен когда у вас есть хост с ESXi.

  5. yahont

    Предыдущий мой пост можно пропустить, я частично прояснил его в Нут_биб. Вот что я там нашел:

    Each ESXi host has a local vSwitch which is used for intra-host communication between the Nutanix CVM and host. For external communication and VMs a standard vSwitch (default) or dvSwitch is leveraged.
    The local vSwitch (vSwitchNutanix) is for local communication between the Nutanix CVM and ESXi host. The host has a vmkernel interface on this vSwitch (vmk1 — 192.168.5.1) and the CVM has an interface bound to a port group on this internal switch (svm-iscsi-pg — 192.168.5.2). This is the primary storage communication path.
    The external vSwitch can be a standard vSwitch or a dvSwitch. This will host the external interfaces for the ESXi host and CVM as well as the port groups leveraged by VMs on the host. The external vmkernel interface is leveraged for host management, vMotion, etc. The external CVM interface is used for communication to other Nutanix CVMs. As many port groups can be created as required assuming the VLANs are enabled on the trunk.

    1. Теперь понятно, что такое vSwitchNutanix. Но непонятно почему svm-iscsi-pg, тут по какому протоколу идет обмен: по iSCSI? Просто я читал, что с варей идет взаимодействие по NFS (и гипервизор видит нутаникс как NFS-хранилище). Тогда причем тут iSCSI?

    2. external CVM interface is used for communication to other Nutanix CVMs. Ну понятно, что у CVM есть еще и внешний интерфейс, который живет на другом vSwitch, который имеет доступ к физическим сетевухам узла и позволяет общаться CVM с другими узлами кластера. external CVM interface — это же интерфейс ВМ, это же не vmkernel? Для этого используется IP из выделенной подсети где живут такие внешние интерфейсы всех CVM кластера? По какому протоколу идет обмен в этом интерфейсе (подсети)?

  6. yahont

    про auto-path в Нут_биб написано вот это:

    In the event of a local CVM failure, the local 192.168.5.2 addresses previously hosted by the local CVM are unavailable. DSF will automatically detect this outage and will redirect these I/Os to another CVM in the cluster over 10GbE. The re-routing is done transparently to the hypervisor and VMs running on the host. This means that even if a CVM is powered down, the VMs will still continue to be able to perform I/Os to DSF. Once the local CVM is back up and available, traffic will then seamlessly be transferred back and served by the local CVM.
    In the event of a CVM «failure” the I/O which was previously being served from the down CVM, will be forwarded to other CVMs throughout the cluster. ESXi and Hyper-V handle this via a process called CVM Autopathing, which leverages HA.py (like “happy”), where it will modify the routes to forward traffic going to the internal address (192.168.5.2) to the external IP of other CVMs throughout the cluster. This enables the datastore to remain intact, just the CVM responsible for serving the I/Os is remote.
    Once the local CVM comes back up and is stable, the route would be removed and the local CVM would take over all new I/Os.

    1. Каким образом реализуется всё это волшебство: «DSF will automatically detect this outage and will redirect these I/Os to another CVM » и «Autopathing, which leverages HA.py (like “happy”), where it will modify the routes to forward traffic going to the internal address (192.168.5.2) to the external IP of other CVMs throughout the cluster.
    The local vSwitch (vSwitchNutanix) is for local communication between the Nutanix CVM and ESXi host. The host has a vmkernel interface on this vSwitch (vmk1 — 192.168.5.1) and the CVM has an interface bound to a port group on this internal switch (svm-iscsi-pg — 192.168.5.2). This is the primary storage communication path. ESXi жестко привязан к этому адресу 192.168.5.2, как он переключится на внешний IP?

    2. Для сопряжения ESXi и СХД необходимо кроме настроек сети (вкладка Networking) еще настроить вкладку Storage для NFS или поднять программный iSCSI инициатор. В вашем случае как?

    3. Пока не поднимется локальная CVM — ВМ данного узла будут вести в/в со всем множеством узлов где разбросаны реплики или путь пойдет к локальным данным узла, но через удаленную CVM?

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

      > ESXi жестко привязан к этому адресу 192.168.5.2, как он переключится на внешний IP?

      Не вполне понятен вопрос. Подсеть 192.168.5.0 — это наша внутренняя подсеть, через которую работает auto-path.

      > Для сопряжения ESXi и СХД необходимо кроме настроек сети (вкладка Networking) еще настроить вкладку Storage для NFS или поднять программный iSCSI инициатор. В вашем случае как?

      Когда вы создаете контейнер в Nutanix, он монтируется в ESXi как датастор как часть процесса его создания. Гипервизор на Nutanix ставится в процессе его инсталляции, это не «внешняя» процедура у нас.

      > 3.

      Через удаленную к локальным

  7. yahont

    In the case of a node or disk failure, the data is then re-replicated among all nodes in the cluster to maintain the RF.

    Если реплики размазаны по всем узлам, то ВМ с отказавшего узла или диска будет вынуждена вести в/в со всеми узлами кластера по которым размазана реплика данных потерянного узла или диска. Что происходит с принципом дата-локалити в этом случае?

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

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

      Я вам сейчас пересказываю Nutanix Bible :)

      Если VM переехала с отказавшего узла, то к части данных VM действительно начнется доступ по сети. Nutanix увидит это, и начнет миграцию всех «потроганных» блоков на локальный SSD, при этом параллельно также перераспределяя блоки на другие ноды для соблюдения избыточности. Через какое-то время, обычно это минуты с момента начала операций с блоками, активные блоки собираются локально и этот сетевой трафик сходит на минимум. Неактивные блоки остаются нелокальными, пока их VM не «потрогает». Холодные блоки остаются на SATA распределенно, так как latency для сети всегда лучше чем latency у SATA. То есть data locality это прежде всего для SSD. Для SATA он не так уж и важен. Так что весь объем vDisk-ов мигрировавшей VM мы не таскаем.

      1. yahont

        Вот этот ответ просто офигенный! Полезный. Сильно сомневаюсь что это явно написано в Нут_биб, там максимум написана одна треть этого, да ещё и размыто.

        Ответьте пожалуйста на мой пост: 22/08/2016 в 07:19

      2. yahont

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

        А нет обратного процесса когда ВМ следует за данными, а не наоборот? Допустим узлы заполнены оченнь неравномерно и отработала процедура disk balancing. Врезультате данные ВМ уехали, а она осталась.

  8. yahont

    Выдержка из Нут_биб: Extents are dynamically distributed among extent groups to provide data striping across nodes/disks to improve performance.

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

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

      Когда мы друг другу противоречим, более верным является вариант Nutanix Bible :)

  9. yahont

    Дорогой коллега, я наверное вас уже достал, но у меня еще вопрос:

    Существует ли возможность для 1 ВМ утилизировать производительность ресурсов хранения нескольких узлов кластера, как в плане IOPS (производительность), так и в плане объема? Т.е. если ВМ уперлась по скорости доступа в потолок возможностей локального узла, сможет ли она увеличить скорость и удовлетворить аппетит за счет ресурсов удаленных узлов? Можно ли сделать так, чтобы одной ВМ кроме локального хоста свою производительность хранилища отдавали удаленные узлы: один или 2 или весть кластер понемногу? А про объем: теоретически можно допустить наличие такой большой ВМ, что для её дисков не хватит локального хранилища 1 узла, её можно размазать по нескольким узлам кластера? В первую очередь конечно интересует вопрос IOPS.

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

      Достали, но что ж делать :) Я скорее переживаю, что комменты это не очень удобный формат для вопросов и ответов. Это, скорее, форумные темы. Тут даже, в теории, поднят форум, но там никого нет, поэтому никто туда и не ходит.
      Вы можете писать мне на rhmelevsky@nutanix.com, если что, а то что мы оффтопим тут.

      > Существует ли возможность для 1 ВМ утилизировать производительность ресурсов хранения нескольких узлов кластера

      Для холодных данных — да, холодные данные на SATA могут лежать нелокально, у нас для этого даже есть специальная нода — NX-6035C, она подключается в кластер, и на ней нет никаких VM кроме CVM на AHV. Но ее емкость SATA становится расширением локальных SATA нод кластера, и может использоваться через кластерный интерконнект.
      Для горячих — только как аварийный случай и нештатная ситуация, типа выхода из строя локального CVM или внезапного исчерпания локального SSD (при этом, если есть в другой ноде недоиспользованный SSD то система, прежде чем «встать», сперва попробует начать писать на него)

  10. yahont

    И подскажите пли, где мне еще можно задавать свои вопросы? Форум хороший, ресурс, можно буржуйский. Лишьбы отвечали хорошо. А то мне уже неудобно вас пытать…
    А за ответы большое спасибо!

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

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