VSAN: facts to know

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

Ранее, в публикациях про VSAN я уже упоминал тот факт, что, согласно документации VMware, объем кэша записи (спасибо за важную поправку Nikolay из комментов) дисковой группы для ноды в VSAN ограничен емкостью в 600GB, что, явно, выглядит недостаточным даже для современных емких SSD, таких, как наши 3.8TB, и уж точно мал для ожидаемых в будушем году Самсунгов на 16TB. С этим в комментах к предыдущим постам как-то вяло пытались спорить, но я так и не понял как предлагается это ограничение обходить в жизни, и почему оно, по поводу критиков моей позиции «не важно» (пояснение почему это так — в комментариях). Ограничение это оставалось и в v6.2, если верить официальному гайду:

http://www.vmware.com/files/pdf/products/vsan/virtual-san-6.2-design-and-sizing-guide.pdf

С учетом того, что там же, в документе, ниже, указывается, что основное правило в сайзинге кэша — кэш составляет 10% от хранимой usable (не raw) емкости (cache:capacity ratio) — что означает, что конфигурации размером более 6TB на ноду на дисковую группу будут, вероятно, испытывать недостаток пространства кэширования. (также смотри в комментарии о деталях)

Изменилось ли что-то тут в VSAN 6.5? Похоже, что нет:

http://pubs.vmware.com/Release_Notes/en/vsan/65/vmware-virtual-san-65-release-notes.html

VSAN все еще требует Multicast.

http://www.vmware.com/files/pdf/products/vsan/virtual-san-6.2-design-and-sizing-guide.pdf

Поменялось ли это? Нет, multicast по-прежнему нужен в VSAN 6.5

http://pubs.vmware.com/Release_Notes/en/vsan/65/vmware-virtual-san-65-release-notes.html

Готова ли у вас сеть к использованию в ней Multicast? Умеете его настраивать, отлаживать странности, понимает ли работу с ним ваши роутеры и иное оборудование в сети?

Дедупликация И компрессия. Я не зря ставлю тут «И», потому что в VSAN они включаются ТОЛЬКО ВМЕСТЕ, и на ВЕСЬ КЛАСТЕР целиком. И по-прежнему ТОЛЬКО на AllFlash.
Если у вас есть в кластере задачи, которые плохо переносят дедупликацию или компрессию, то вам придется выключить эти фичи для всего кластера целиком, даже если какие-то задачи и нуждаются в них.

Это соханилось в VSAN 6.5:

http://pubs.vmware.com/vsphere-65/topic/com.vmware.vsphere.virtualsan.doc/GUID-2285B446-46BF-429C-A1E7-BEE276ED40F7.html

Обоатите внимание также на warning, показываемый при включении deduplication & compression.

Документация подтверждает:

http://pubs.vmware.com/vsphere-65/index.jsp?topic=%2Fcom.vmware.vsphere.virtualsan.doc%2FGUID-5A01D0C3-8E6B-44A7-9B0C-5539698774CC.html

Про Data Locality.
Даже несмотря на то, что у VMware даже есть специальный документ по этому поводу: http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vsan/vmware-virtual-san-data-locality.pdf
просто взгляда на картинку со схемой размещения данных виртуальной машины достаточно, чтобы понять, что data locality в том смысле, в котором его понимает Nutanix, в VSAN нет.

Поэтому ничего удивительного в том, что в приведенном выше документе термин Data Locality VMware трактует иначе, и достаточно своеобразно:

Поддержка и обновления.
Поправьте меня, если я что-то понимаю не так, но из вот этой картинки следует, что обновления ПО у VxRail доступны только для Premium support:

Ну и, чтоб уж, как говорится, два раза не вставать, надо помнить, что, с точки зрения DellEMC покупатель VxRail НЕ МОЖЕТ смешивать их в одном кластере с «самосборными» нодами. То есть купили VxRail с поддержкой — продолжайте покупать их для расширения системы дальше. Но подключать в кластер из VSAN/VxRail самосборные ноды VSAN вы технически — можете, но поддерживаться эта конструкция на стороне DellEMC не будет. Помните об этом.

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

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

VSAN: facts to know: 20 комментариев

  1. Nikolay

    Роман, эти темы уже много раз с вами обсуждались в этом же блоге и я уже писал вам свои замечания/исправления и вы даже на них уже не возражали, а тут опять тоже самое.
    1.) «объем кэша дисковой группы для ноды в VSAN ограничен емкостью в 600GB»
    a) Не кэша, а кэша на запись. Что означает, что для гибрида подходят диски до 2TB на одну дисковую группу. (30%=600GB+70%=1400GB)
    b) Для All Flash действительно есть ограничение в 600GB для кэша на запись (хотя смысл использовать SSD диски под кэш большего размера, на самом деле есть), но это не значит, что вы не можете использовать SSD в 1.9, 3.8TB или больше. Вы их просто используете для хранения, т.к. эти диски относительно медленные на запись, зато дешевые, а под кэш ставите маленькие, но очень быстрые диски на запись, например, PCI NVMe типа Intel P3700.
    c) Посмотрите внимательно в Design and Sizing Guide на стр.12. Там 10% от полезной, а не сырой емкости. При зеркалировании это означает, что не 6TB, а 12TB на дисковую группу.
    d) 6/12TB — “ограничение” не на ноду, а дисковую группу. В ноде vSAN может быть много дисковых групп. Например, конфигурация All Flash ноды в 2U сервере — 5xP3700 PCIe NVMe 400GB+15×1.92TB SSD Samsung PM863 даст 28TB сырой емкости. При желании диски 1.92TB можно заменить на 3.84TB и остаться в рамках рекомендаций (если поставить 800GB под кэш), но это получится 56TB на узел, что ИМХО перебор. А теперь сравните GB/$ и производительность (обратите внимание, в первую очередь, на производительность на запись и, главное, latency) у этих дисков.
    e) У All Flash нет проблем с “недостатком пространства кэширования”. В All Flash кэш, в первую очередь, снижает latency на запись по сравнению со стандартными медленными/большими/дешевыми SSD, а во-вторых, уменьшает износ этих самых больших дисков. Об этом пишут на той же 12 странице.
    2.) «Готова ли у вас сеть к использованию в ней Multicast? Умеете его настраивать, отлаживать странности, понимает ли работу с ним ваши роутеры и иное оборудование в сети?»
    а) Что значит готова ли ваша сеть и понимают ли multicast ваши роутеры? Multicast/IGMP стандартный сетевой протокол из 1989 года. Любое сетевое оборудование умеет работать с multicast трафиком. С тем же эффектом можно спросить “а поддерживают ли ваши роутеры unicast и broadcast?”
    b) Multicast уже включен по умолчанию в большинстве коммутаторов.
    с) Единственный момент, когда вам нужно настраивать multicast, это когда вы разделяете кластер в разные L3 сегменты (например, растянутый кластер с L3 связанностью между ЦОД). Но, поверьте, в этом случае намного большей проблемой для вас будет обеспечить связанность ВМ по L2, что, очевидно, необходимо для корректной работы ВМ.
    d) Иное оборудования в сети и не должно ничего делать с multicast (хотя и умеет). В абсолютном большинстве случаев, vSAN network — отдельный VLAN, в котором ходит только vSAN трафик.
    3.) «Если у вас есть в кластере задачи, которые плохо переносят дедупликацию или компрессию, то вам придется выключить эти фичи для всего кластера целиком, даже если какие-то задачи и нуждаются в них.”
    Тут забавно — если задачи «плохо переносят дедупликацию или компрессию”, то это означает, что они просто не сжимаются/дедупятся и остаются по объему как есть. Поэтому если у вас такие задачи есть, то вы просто не получите для них выигрыша в сохранении объема, а остальные машины будут успешно дедупиться/сжиматься, т.е. ничего не изменить по сравнению со случаем, когда вы в ручную выключите дедуп/компрессию для таких ВМ. Поэтому ничего выключать на уровне кластера не нужно.
    4.) «data locality в том смысле, в котором его понимает Nutanix, в VSAN нет.»
    Никто никогда не говорил, что у vSAN есть Data locality, «в том смысле, в котором его понимает Nutanix”. И это замечательно, потому что за счет этого vSAN получает несколько преимуществ:
    a) чтение со всех копий данный/узлов/SSD
    b) отсутствие какого-либо влияния DRS/vMotion на производительность.
    c.) Возможность параллельно писать/читать на/с многих узлов подкручивая политику страйпинга для тех ВМ, которым это нужно (например, для пары «Monster VM” в кластере)
    d.) Возможность использования бездисковых нод, у которых производительность будет ровно такая же, как и для нод с дисками.
    e.) «Локальность данных” же у vSAN только там, где время похода по сети больше времени обращения к данным. Например, RAM Read Cache (где задержка RAM<<задержки по сети) или Stretched cluster (где по сети +5 мс к задержке)
    5.) "Поддержка и обновления."
    a.) Роман, вы определитесь про что вы пишите — vSAN или VxRail? Это принципиально разные вещи, хотя VxRail и построен на базе vSAN. Но раз в заголовке про vSAN, то давайте про него и продолжим:
    b.) Обновление (subcription) на vSAN идет с любой поддержкой, как и для любых других продуктов VMware.
    c.) Смешивать в кластере ноды разных вендоров/поколений/моделей/форм-факторов/набивки — можно и поддерживаемо. За исключением смешивания All Flash и Hybrid.
    d.) Более того, т.к. vSAN — чистое ПО, то вы можете переносить купленные лицензии на новое оборудование. Т.е., например, через 3 года вы обновляете сервера (будет больше ядер, больше памяти, больше/дешевле/быстрее SSD), а за новые лицензии vSAN и vSphere не платите, что уменьшает стоимость обновления системы в пару раз.

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

      Спасибо за длинный и подробный комментарий, я поправил в тексте про «кэш записи», и отвечу вас столько же развернуто и подробно завтра с утра.

    2. boredsysadmin

      классный ответ Николай.
      Я забыл написать про PCIe/NVMe SSD каш, который нутаникс не поддерживает пока что.

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

        Да, но NVMe будет поддерживаться уже в первом квартале следующего года.

        1. Nikolay

          Роман,
          Давайте не будем «продавать roadmap’ы», а остановимся на том, что доступно на данный момент. А то мало ли, что будет в vSAN в Q1. ;)

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

            Что мне может запретить? ;)
            Это мой собственный блог, и что тут писать решаю я сам.

        2. Maxim

          Рома, NVMe поддерживается в 5.0 уже.

          Так что даже не Q1.

          Ну и юмор в том что для VSAN из-за отсутствия data-locality — NVMe что мертвому припарка.

          1. Nikolay

            Эх, Максим, опять эти сказки про чудесность локальности данных.
            1.) Подскажите, пожалуйста, какова сетевая задержка между двумя хостами (гипервизорами) соединенных по 10GbE интерфейсу и какова сетевая задержка между двумя ВМ на одном хосте по сети? С тестами и пруфами, пожалуйста.
            2.) А что уже был GA 5.0? И какая конфигурация уже доступна с NVMe?

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

      Итак, после небольшой задержки, есть время покомментировать.

      > 1.) «объем кэша дисковой группы для ноды в VSAN ограничен емкостью в 600GB»
      a) Не кэша, а кэша на запись. Что означает, что для гибрида подходят диски до 2TB на одну дисковую группу. (30%=600GB+70%=1400GB)

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

      > c) Посмотрите внимательно в Design and Sizing Guide на стр.12. Там 10% от полезной, а не сырой емкости. При зеркалировании это означает, что не 6TB, а 12TB на дисковую группу.

      Спасибо, учел.

      > Что значит готова ли ваша сеть и понимают ли multicast ваши роутеры?

      То, что во многих сетях multicast не настроен и не используется, а включение и использование его может вызвать необходимость перенастройки в неочевидных местах.
      IPv6 формально является стандартным протоколом с 1998 года, с публикации RFC2460 (а разрабатывался и куда как раньше), но много ли вы знаете сетей, его использующих, и, более того, готовых немедленно на него перейти? «Стандартность» совсем не является синонимом отсутствия проблем. Желающих экспериментировать на продакшновой сети и заниматься перенастройкой того, что «и так работает» — немного.
      Не хочу сказать, что это полный gamestopper, конечно нет. Но пойдите-ка и предложите вашему сетевику «завтра перейти на IPv6 в вашей сети», а потом посмотрите на его глаза. ;)

      > Тут забавно — если задачи «плохо переносят дедупликацию или компрессию”, то это означает, что они просто не сжимаются/дедупятся и остаются по объему как есть.

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

      > Никто никогда не говорил, что у vSAN есть Data locality

      Неправда, можно поискать в комментах к какому-то из ранних постов, мне, как раз ссылаясь на существование этого документа, это и доказывали.

      > потому что за счет этого vSAN получает несколько преимуществ:
      > a) чтение со всех копий данный/узлов/SSD
      > c.) Возможность параллельно писать/читать на/с многих узлов

      И гораздо большую загрузку сетевого интерфейса, а, как следствие, влияние сетевых задержек на ввод-вывод чтения.
      А кроме этого — существенно больший трафик по сети в случае необходимости восстановить потерянные, например в случае выхода из строя ноды и накопившегося объема изменений, что может иметь поистине катастрофические последствия для «боевого» workload, на что уже натыкались пользователи, те же истории с «легшим» кластером с reddit.

      > Роман, вы определитесь про что вы пишите — vSAN или VxRail?

      Николай, я определился. VxRail это VSAN, поставленный на физическую платформу, и продаваемый как готовое решение совладельцем бизнеса VMware, компанией DellEMC. Ничего не напутал? Почему бы не говорить о нем рядом с VSAN? Или вы предпочтете, чтобы я написал отдельный текст про VxRail в добавок к тексту про VSAN? Так я могу, да ;)

      > Обновление (subcription) на vSAN идет с любой поддержкой, как и для любых других продуктов VMware.

      Вероятно это так для VSAN, но вот DellEMC почему-то показывает иное. Хотелось бы ясности, что имелось ввиду в приведенной картинке.

      > Смешивать в кластере ноды разных вендоров/поколений/моделей/форм-факторов/набивки — можно и поддерживаемо. За исключением смешивания All Flash и Hybrid.

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

      Резюмируя: спасибо за комментарии, думаю, они помогут сделать пост полезным и разъяснить некоторые темные моменты, которые в нем были. Рад, что читатете и комментируете, спасибо.

      1. Nikolay

        1.) «Спасибо за исправление, уже уточнил в посте, что речь идет про «кэш записи», составителям гайда, который я цитирую, тоже стоит быть более определенными.»
        Да не, там все ок. Надо просто посмотреть ровно на абзац выше:
        All-Flash Virtual SAN still has a write cache, and all VM writes hit this cache device. The major algorithm change, apart from the lack of read cache, is how the write cache is used. The write cache is now used to hold ‘‘hot’’ blocks of data (data that is in a state of change). Only when the blocks become ‘‘cold’’ (no longer updated/written) are they are moved to the capacity layer. In all-flash configurations, having a high endurance flash cache device can extend the life of the flash capacity layer. If the working sets of the application running in the virtual machine fits mostly in the flash write cache, then there is a reduction in the number of writes to the flash capacity tier.

        2.) «но много ли вы знаете сетей, его использующих, и, более того, готовых немедленно на него перейти?”
        a.) Покажите мне, пожалуйста, хоть один коммутатор выпущенный за последние 5 лет, которой не поддерживает multicast.
        b.) Multicast включен по-умолчанию. Если вдруг его все-таки специально выключали, то, например, на Cisco он включается «очень сложно”:
        configure terminal
        ip igmp snooping
        interface vlan 10
        ip igmp snooping
        ip igmp snooping querier x.x.x.x
        c.) Включение multicast в отдельном VLAN не влияет ни на что больше в сетевой инфраструктуре и не требует каких-либо других изменений.

        3.) «Не всегда, это может означать ухудшение производительности, неподдерживаемость производителем или проблемы с кэшированием.”
        a.) Поясните, пожалуйста, какие проблемы с кэшированием возникают при включении дедупликации/компрессии? Особенно, если учесть за дедуп/компресия у vSAN работает после кэша (в процессе сброса данных из кэша на диски хранения)
        b.) Приведите, пожалуйста, пример, какой производитель и чего официально не поддерживает дедуп/компрессию на СХД?
        c.) Включение дедупа/компрессии практически никак не влияет на производительность отдельной взятой ВМ. Запись все равно идет напрямую в кэш (дедуп движок тут не участвует) — задержки не растут, IOPS столько же. Чтение идет либо из кэша на запись (если данные еще «не опустились»), тогда и здесь движок дедупа тоже не участвует, либо с Capasity Tier — тут движок дедупа работает, но это не есть проблема, ибо со скоростью чтения все нормально, т.к. читаем со всех Capasity SSD + производительность на чтение даже у больших/дешевых SSD хорошая (в отличии от скорости записи).

        4.) «Неправда, можно поискать в комментах”
        a.) Ну смотрите, я поискал и вот, что я писал ранее:
        «Внимательно почитайте документ. Там достаточно подробно описывается, что есть у VSAN с т.з. Data Locality, чего там нет и почему инженеры VMware считают, что так лучше. Я же не говорил про терминологию и наличие самого факта «Data Locality» у VSAN. Я с вами соглашусь, что в VSAN нет аналогичной Nutanix’y Data Locality, но в документе есть точка зрения на то, почему это так и в чем могут быть плюсы такого подхода.»

        5.) «И гораздо большую загрузку сетевого интерфейса, а, как следствие, влияние сетевых задержек на ввод-вывод чтения.”
        Это миф. Запись у вас всегда идет по сети (потому что одна копия всегда удаленная, а запись синхронная), поэтому от локальности никаких выигрышей в задержках быть не может в принципе. Чтение — да, может идти по сети, а может и нет.
        a.) Только вот чтобы забить 1x10GbE нужно ~250-350k IOPS 4K на НОДУ. Если мало (что вряд ли, если честно в реальной жизни), то добавляйте второй 10GbE порт или ставьте 25/40GbE — это поддерживается.
        b.) Задержки SSD на чтении/записи под нагрузкой — 0.5-2мс. Задержки коммутаторов 10GbE единицы микросекунд. C учетом стека ESXi — 30-50 мкс (кстати, если две ВМ на одном хосте общаются по сети, т.е. ваш вариант, то задержка примерно 20-30мкс. посмотрите документ Network I/O Latency on VMware vSphere 5). В любом случае, разницы между 1.5мс и 1.55мс особо то и нет. А уж в гибриде, где latency прыгает до 5-15мс при кэш-миссe на HDD, то совсем все равно.
        c.) Это элементарно проверяется на любом демостенде. Берем ВМ с одной копией данных, размещаем её принудительно на той же ноде, что и её данные при помощи vMotion. Затем запускаем бенчмарк (хоть на чистое чтение), а потом делаем vMotion ВМ на другую ноду. Производительность останется ровно такой же.

        6.) А кроме этого — существенно больший трафик по сети в случае необходимости восстановить потерянные, например в случае выхода из строя ноды и накопившегося объема изменений, что может иметь поистине катастрофические последствия для «боевого» workload, на что уже натыкались пользователи, те же истории с «легшим» кластером с reddit.

        a.) Поясните, пожалуйста, как влияет локальность данных или её отсутсвие в сценариях ребилда при сбое ноды?
        b.) Хороший пример про истории с reddit. Если вы прочитаете что же там все-таки написано, то падали SAS RAID контроллеры, а не упирались в сеть. Т.е. сеть обеспечивала достаточно большую производительность, чтобы не быть узким местом.

        7.) «Ничего не напутал?”
        a.) Напутали. VxRail — appliance или integrated solution в терминалогии Gartner от DellEMC. vSAN — чистое ПО от VMware, а не готовое решение. (именно поэтому в Gartner нет vSAN). Вы же не будет говорить, что vBlock/FlexPod — это vSphere.
        b.) Вы покупаете VxRail и vSAN у разных компаний, через разные каналы под разными условиями и, разумеется, с разными ограничениями. У них даже минимумы/максимумы отличаются.
        c.) VxRail — это не vSAN. Это как минимум, дополнительные программные компоненты, сборки/заливке на заводе, дополнительные сервисы и функции. И у него есть как дополнительные ограничения, которых нет у vSAN, так и дополнительные плюшки, которых тоже нет у vSAN. Есть ведь еще, например, VxRack SDDC, в который тоже входит vSAN, но там еще много чего другого (от NSX до IaaS/PaaS), что делает его сравнение с vSAN (или даже Nutanix) — не корректным.
        d.) Основная разница — vSAN, как чистый софт, дает вам гибкость (железо, конфигурации, обновления в Day0 и т.д.). VxRail, как Integrated Solutions, ускоряет/упрощает ввод в эксплуатацию, обновления и т.д. А тут основной вопрос в том, что нужнее заказчику — у него есть выбор.

        8.) «Вероятно это так для VSAN, но вот DellEMC почему-то показывает иное.”
        Для DellEMC это так же. Это просто называется “Right to new releases of software” и включено в обе версии поддержки, как вы видите на том же слайде 5 строчками ниже.

  2. boredsysadmin

    «объем кэша дисковой группы для ноды в VSAN ограничен емкостью в 600GB»
    давай не путать х** с пальцем. vSan 6.5 говорит что каш ЗАПИСИ ограничен 600гб, там ничего не написано про каш чтенение.
    600 гб это очень много на каша записи и к тому же, это только для одной диск группы

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

      ДавайТЕ, для начала, вы оставите этот тон в фейсбучике или вконтактике, а здесь будете все же держать себя в руках в плане тона, хорошо?

      Я нигде и не говорю про кэш чтения. Но вот то, что кэш записи ограничен, и для сегодняшнего дня довольно небольшим объемом — вот на это стоит обратить внимание. Если вы считаете, что 600GB (то есть 6TB дисковой группы исходя из рекомендованного соотношения cache:capacity = 1:10) это много, так бывают и крупные задачи. И если VSAN нацелилась на Tier-1, то значит надо уже соответствовать.

      1. Nikolay

        Роман,
        Как я уже писал выше, не 6TB, а 6-12TB на одну дисковую группу (зависит от FTT, FTT Metod, свободного пространства на datastore (вы же не заполняете том на 90%-100% из соображений доступности)). Более того, если вы кэш в All Flash будет меньше 10%, то это не критично для производительности, потому что кэш-мисс не является проблемой. Просто будет больше перезаписей на SSD Capasity Tier и, возможно, они должны быть чуть быстрее или их должно быть чуть больше штук на дисковую группу.
        Нужно больше места в ноде — делайте больше дисковых групп (до 5). Нужно больше кэша на запись — делайте больше дисковых групп — 600GBx5=3TB на ноду. Я просто пока не могу понять проблематику.
        Давайте зайдем с другой (правильной стороны) — приведите пример задачи у гипотетического заказчика Tier-1 под крупные задачи? Сколько ему нужно ядер/памяти, полезного пространства, насколько приложение чувствительно к latency? На основании этих данных, я приведу вам в пример конфигурацию vSAN ноды, которая соответствует этим требованиям и архитектуре vSAN All Flash.

        1. Maxim

          Да простейший пример.

          Сертифицируемся с ЦФТ.

          Требуется 4 узла Oracle RAC, 400 тысяч транзакций в секунду (от RAC) — по IOPS это уже миллион+.

          Задержки по I/O менее миллисекунды.

          Мы — умеем (как раз на железе с NVMe).

          Очень интересно посмотреть на конфигурацию VSAN, особенно учитывая что при очень высоких скоростях I/O нагрузка на CPU легко 30% и выше получается на нем (за счет кривой реализации внутри ядра).

          1. Nikolay

            Максим, а можно пример теста с 100k tps (400k/4) на узел на Nutanix?
            1.) То, что я смог найти — это 21k tps на ВМ с latency 5ms на 4-х NX9040. http://www.slideshare.net/NEXTtour/databases-love-nutanix
            Для 400k tps требуется в 19 раз больше, т.е. 76 узлов. Как это согласуется с 4-я инстансами RAC и локальностью данных?
            2.) В данном тесте использовались 4-х сокетные сервера с ВМ загружающих 48 ядер. И даже если, вдруг, подсистема хранения стала невероятно быстрой, а масштабирование у нас полностью линейное, то для увеличения tps на инстанс в 5 раз нужно ~240 ядер на сервер. В какую вашу ноду можно засунуть 240 ядер?
            3.) Ну и, кстати, 0.9M IOPS 4K 70/30 R/W на 8-и узлах на vSAN в тесте от Intel — http://itpeernetwork.intel.com/vmware-virtual-san-6-2-sets-new-record/
            Т.е. 1.8M IOPS на 16 узлах.

      2. boredsysadmin

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

        Ты меня извини, но я представить себе ну никак не могу, какая такая задача может тормозить на «всего» 600гб PCIe SSD каша записи.

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

          Так и я плохо мысли читаю. Вот специально заскриншотил кусок, приведенный в тексте поста. Укажите мне там, пожалуйста, хотя бы одно слово «write»?
          Предполагается, возможно, что «кэш записи» подразумевается, но из текста это не следует, так что возвращаю вам упрек, и предлагаю переадресовать его составителям документа Virtual SAN 6.2 Design and Sizing Guide.

      3. Maxim

        600GB кэш на запись — это много?? Вы серьезно?

        Я так понимаю вы позиционируете (вполне кстати верно) vSAN как решение для SMB и tier-3 нагрузок?

        1. Nikolay

          Максим, 56TB сырой емкости на ноду. При этом строго в рамках рекомендаций по отношению cache/capasity для vSAN.
          56TB емкости на All Flash на ноду — это мало/smb/tier-3?

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

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