Nutanix «под крышкой»: Производительность

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

Nutanix Tech Note
Производительность

Nutanix Virtual Computing Platform обеспечивает работу гостевых виртуальных машин (guest VM), предоставляя им сервис хранения данных и уникальную степень масштабируемости, равно как и высокую производительность.
Эта беспрецедентная комбинация обеспечивается с помощью Nutanix Distributed Filesystem (NDFS), которая обеспечивает адаптивную реакцию на рабочую нагрузку и обеспечивает наивысшую возможную производительность для каждой из VM, но при этом не жертвуя емкостью, стоимостью, простотой или богатством функциональных возможностей.

Конвергентная платформа

NDFS обеспечивает работу с наивысшей производительностью за счет того, что размещает ресурсы хранения (например диски) к которым обращаются VM локально для них, на том же хосте, то есть использует DAS, direct attached storage. Это означает, что локальный контроллер хранилища (это VM, одна на узел Nutanix) может предназначить свои ресурсы для обслуживания операций ввода-вывода VM, выполняющихся на том же физическом серверном узле. Другие контроллеры, запущенные в кластере, обслуживают операции ввода-вывода своих, расположенных локально уже для них, виртуальных машин. Такая конвергентная архитектура контрастирует с привычным традиционным устройством сетевой системы хранения, когда контроллер хранилища расположен «на том конце» сети, удаленно для потребителей данных, а данные доступны для локальных VM через сеть (SAN или NAS).

Архитектура Nutanix имеет сразу несколько преимуществ с точки зрения производительности. Во-первых, так как ресурсы хранения локальны для хоста, запросы на запись и чтение не передаются по сети, что кардинально улучшает latency, или «задержки операций», так как из пути ввода-вывода устраняются все компоненты сети передачи данных, драйвера и сетевые карты, или HBA, очереди команд, коммутаторы, и так далее. Во-вторых, хост VM (то есть узел [node] Nutanix) использует свой собственный виртуальный контроллер хранения (virtual storage controller, Controller VM или CVM), что устраняет узкое место, обычно возникающее в случае использования совместно используемых, сетевых систем хранения. Когда вы добавляете в кластер новый узел Nutanix, с ним добавляется и его контроллер хранилища, что позволяет сохранить предсказуемую и линейно увеличивающуюся производительности при расширении кластера. Масштабируемая архитектура Nutanix обеспечивает не просто стабильную, но и пропорционально растущую производительность при увеличении числа узлов кластера.

Эффективные средства Data Tiering

NDFS следит и оценивает паттерны доступа, и умеет обрабатывать разные типы нагрузки разным образом, чтобы обеспечить оптимальную производительность каждой гостевой VM. Данные с частым и произвольным (random) к ним доступом (иначе «горячие»), хранятся на наиболее быстрой части хранилища: оперативной памяти или flash-SSD. Менее активно читаемые («холодные») и данные с преимущественно последовательным доступом к ним, перемещаются на HDD с высокой емкостью, при этом для всех типов данных сохраняется избыточность и защита от отказов.

Данные с произвольным доступом пишутся в выделенную для этого область на локальном SSD, в так называемый Oplog. Oplog, или operational log, это расположенный на SSD кэш записи, использующийся для приема и размещения операций записи. Он записывает на себя поступающие данные, и быстро рапортует VM об успешном завершении записей, обеспечивая как низкие задержки, так и высокую производительность.

Одновременно с записью в локальный Oplog, данные также посылаются по сети на CVM другого узла кластера, где он записывается в Oplog также и этого узла. После того, как данные записаны в Oplog двух различных узлов кластерной системы, отправляется уведомление об успешной записи к VM, инициировавшей эту операцию. В результате, любое уведомление о завершившейся записи, что пришло на guest VM, гарантирует, что данные записаны на диск и, следовательно, защищены от возможных отказов питания, SSD, сбоя или отказа узла-хоста, и могут быть прочитаны спустя всего миллисекунды, после того, как уведомление о записи принято.

После того, как данные записаны в Oplog, и VM уведомлена об успешном завершении операции, данные комбинируются и последовательно сбрасываются в так называемый Extent Store. Хранилище Extent Store содержит в себе так называемые «экстенты», или области данных vDisk переменной длины (иначе: файлы NDFS) лежащие как на SSD, так и HDD. Содержимое Oplog постоянно сливается в Extent Store для того, чтобы иметь достаточно места для размещения последующих операций записи, и обеспечивать максимальный уровень производительности.

Данные, которые записываются последовательно, однако, минуют Oplog, и поступают непосредственно на Extent Store. Это сделано потому, что последовательно записываемые данные обычно последовательно же и размещаются на дисках, и могут эффективно записываться прямо на диски, большими блоками, без потерь производительности. Кроме этого, с последовательно записываемыми данными связано меньше записей метаданных, поэтому и на запись метаданных таких данных тратится меньше времени.

NDFS может быть также сконфигурирована так, чтобы последовательно записываемые данные полностью миновали SSD, и вместо этого сразу шли на запись на HDD. Высокая производительность в данном случае достигается тем, что данные уже помещены при этом на HDD, и NDFS может при этом использовать большее число дисков, то есть физических «шпинделей».
Запись последовательных данных прямо на HDD также снижает объем занятого места на SSD, сохраняя емкость SSD для более важных, произвольных (random) данных, и увеличивая их срок службы.

Данные в Extent Store остаются на уровне «горячих» данных, с наивысшей производительностью, пока к ним осуществляется активный доступ. Если частота доступа к данным снижается, то они помечаются для миграции на «холодный» уровень хранилища. Оценка того, какие данные будут признаны «холодными», выполняется системным компонентом, называемым Curator, который, как указывает его имя, курирует задачи файловой системы, выполняя фоновые задачи, обеспечивая бесперебойность работы кластера.

Каждый Controller VM имеет размещенный в памяти хоста кэш чтения, называющийся Extent Cache. Часто запрашиваемые данные помещаются в этот локальный кэш чтения, позволяя обслуживать запросы к ним самым быстрым путем — из оперативной памяти, это позволяет поддерживать крайне низкую латентность для таких запросов.

Curator использует серию операций Map Reduce для эффективного сканирования метаданных распределенным образом, анализируя различные порции их на каждом узле кластера. Он управляет множеством операций файловой системы, включая data tiering, ребалансировку загрузки дисков, дефрагментацию, восстановление избыточности хранимых данных при отказе диска или узла кластера, и многое другое. Curator запускается раз в час и немедленно после возникновения критического события. Примером такого критического события могут быть отказ диска или узла кластера, заполнение SSD выше заданного порога, или заполнение диска (HDD или SSD) уровнем более, чем другие диски.

Наоборот, данные могут быть перенесены с уровня HDD на высокоскоростной уровень SSD, если частота обращений к данным выросла. Данные переносятся на SSD в случае, если к ним осуществляется доступ трижды на протяжении 20 минут, и если промежуток между всеми тремя чтениями составляет от 10 секунд до 10 минут. Это позволяет корректно мигрировать данные на SSD без нежелательной ситуации, когда миграция могла бы быть инициирована простым повторным обращением к данным в очень короткий промежуток времени.

Локальный Controller VM использует для ввода-вывода все диски на соответствующем уровне. Это позволяет равномерно «разбросать» записи по дискам, равномерно нагрузив их и полностью использовав доступную дискам полосу, как на чтение, так и на запись. Это также обеспечивает «RAID-0 like» уровень производительности, но без нежелательного риска потери всей информации узла в результате отказа одного из дисков. Аналогичным образом, все Controller VM кластера участвуют в репликации Oplog и Extent Store.

Размещение данных

Как правило, в кластере виртуальных машин его VM мигрируют с хоста на хост этого кластера, и могут делать это в зависимости от нагрузки, оптимизируя загрузку CPU хостов, и ресурсов памяти. Так как NDFS обслуживает данные локально для гостевых VM, и использует для этого direct-attached диски, необходимо, чтобы данные VM следовали за ней, при перемещении ее с хоста на хост.

В случае использования традиционного сетевого хранилища, данные остаются доступны за счет доступа к ним по сети, так что данные VM остаются на своем месте (на этом центральном сетевом совместно используемом хранилище), даже если VM перемещается внутр кластера по его хостам. Распределенная и масштабируемая архитектура Nutanix, однако, хранит данные VM как можно «ближе» к ней, чтобы обеспечивать максимальную производительность и минимальный сетевой трафик и уровень задержек.
После того, как VM завершила операцию vMotion, системный Controller VM на хосте, получившем VM, получает также права владения (ownership) на ее файлы данных (файлы vDisks на NDFS), и начинает обслуживать все операции ввода-вывода к этим vDisks. Соответственно и записи будут писаться через локальный Controller VM на локальное хранилище, чтобы обеспечить производительность записи неизменной, как и до начала миграции VM.

Запросы на чтение для записанных после миграции данных будут обслуживаться локально, а данные, которые были записаны до операции миграции VM, будут переадресованы на Controller VM хоста-источника, на котором VM находилась до операции миграции. В фоне процесс Curator начнет динамически перемещать данные с удаленного для VM хоста, на локальный для нее узел Nutanix, чтобы все операции чтения выполнялись локально, без передачи их по сети.

Высокопроизводительные снэпшоты и клоны данных

Обычные снэпшоты VMware при их использовании ведут к снижению производительности системы и обычно не рекомендуются для использования в «продакшн»-системе. Снижение производительности вызывается тем, что гипервизор имеет минимальные знания (или вовсе не знает) о том, что происходит с данными на бэкенд-хранилище.
Вследствие этого он должен использовать существующие конструкции хранилища — файлы VMDK, который фактически являются просто файлами на диске. Когда берется снэпшот VMware, VMDK помечается как read-only и просто фиксируется на своем месте в отныне неизменном виде. Последующие за этим записи пойдут в другой файл, называемый «delta».

Когда берется следующий снэпшот, то этот delta-файл рассматривается как оригинальный VMDK и помечается как read-only. Для дальнейших записей создается новый файл delta, и так далее.
Проблема с производительностью заключается в том, что записи, делаются в delta-файл, в форме лога изменений, когда записывается каждое изменение файла, с момента взятия снэпшота.
Из этого следует, что для того, чтобы считать данные нужно прочитать не только последний по времени изменения delta-файл, в который был записан блок данных, но также каждое изменение, сделанное с исходными данными. Больше снэпшотов — больше измененных данных, в результате производительность работы с данными последовательно ухудшается.

Снэпшоты Nutanix разработаны для использования в «продакшн»-условиях, позволяют использовать все преимущества «снэпшотов VMware», но не вызывают характерных для них последствий в виде снижения производительности.
Nutanix отслеживает данные с помощью распределенной базы метаданных, разработанной для эффективного использования снэпшотов, что было одним из ключевых требований при ее разработке. Nutanix использует алгоритм redirect-on-write, что принципиально улучшает эффективность работы системы при выполнении снэпшотов.

Во-первых, вместо записи данных в «лог изменений», данные пишутся в выделенный новый блок. Не требуется процесс поиска существующего на дисках блока данных. Во-вторых, система интеллектуально обрабатывает дерево снэпшотов и их метданные для оптимизации как пространства размещения, так и производительности, что минимизирует системный оверхед. Когда в какие-либо блоки внутри группы пишутся данные в дочерние объекты, то дочерний vDisk получает копию родительских метаданных для группы экстентов (то есть Extent Group). Это радикальным образом устраняет любой оверхед при росте цепочки снэпшотов, так как каждый кон имеет их собственную копию.

Дополнительно, система метаданных позволяет обращаться к нескольким vDisk-ам одним запросом. Это радикально уменьшает объемы поиска в метаданных и его оверхед для блоков, которые не были унаследованы (потому что в них пока ничего не писалось). Когда дерево снэпшотов расширяется за пределы пяти ветвей, дерево обрезается, что вызывает копирование оставшихся родительских метаданных в дочерние vDisk-и. Это важно для данных, сходных с файлами OS, которые в основном читаются, а не пишутся. Иными словами, иначе их метаданные не могли бы быть унаследованы.

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

Nutanix «под крышкой»: Производительность: 7 комментариев

  1. Anton

    Архитектура Nutanix имеет сразу несколько преимуществ с точки зрения производительности. Во-первых, так как ресурсы хранения локальны для хоста, запросы на запись и чтение не передаются по сети, что кардинально улучшает latency, или «задержки операций», так как из пути ввода-вывода устраняются все компоненты сети передачи данных, драйвера и сетевые карты, или HBA, очереди команд, коммутаторы, и так далее.
    __
    Поскольку в системе «синхронная репликация на запись между нодами/хостами», то запросы на запись передаются по сети, со всеми вытекающими, а чтение — да, локально.

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

      Anton:
      > Поскольку в системе «синхронная репликация на запись между нодами/хостами», то запросы на запись передаются по сети, со всеми вытекающими, а чтение — да, локально.

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

  2. Vlad

    При перемещении VM на другую ноду сначала необходимо перенести на неё данные? Т.е. ко времени переезда нужно добавить время для предварительной репликации данных? И выбор новых нод ограничен свободным местом на локальных дисках?

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

      Vlad:
      Нет, не сначала, потом.
      Существуют две различных возможности.
      1. Вы переносите VM на ноду, на которой уже есть реплика данных. Тогда (через короткое время) доступ перемаршрутизируется на эту реплику, которая становится «мастер-данными».
      2. Вы переносите VM на ноду, где нет данных этой VM. При этом работа продолжается немедленно, но с доступом по сети, к дискам той ноды, где есть данные, а процесс Curator начинает перенос на эту ноду данных VM, примерно как это происходит при Storage VMotion. После завершения переноса данных, также как в варианте 1, происходит перемаршрутизация путей доступа, и доступ продолжается локально. В этот сравнительно небольшой период, пока данные VM не перемещены на новую ноду, наблюдается latency, характерный для сетевого хранилища, после окончания переноса latency падает до обычных значений.

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

  3. Vlad

    Выходит что размер хранилища на нодах должен быть кратен размеру дисков выделенных VM. Иначе будет проявляться фрагментация доступного пространства на дисках нод в больших кластерах. В отличие от централизованного хранилища здесь необходимо распределять VM не только по процессорам и памяти но и по доступному размеру дисков на нодах. Необходим какой-то механизм для «дефрагментации» расположения VM на серверах. Что-то вроде команды hbal есть в похожем «кластере без выделенного хранилища» ganeti — https://code.google.com/p/ganeti/

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

      Вообще это довольно дискуссионная и неоднозначная тема, насколько фрагментация влияет на характеристика 100% рандомного доступа. В некоем другом блоге я довольно много на эту тему понаписал за несколько лет, включая результаты тестов, которые показывают крайне незначительный эффект от фрагментации (даже очень сильной) на характеристики рандомного доступа.

      1. Vlad

        Возможно я неправильно использовал термин фрагментация. Поскольку весь образ VM хранится на ноде целиком то при размещении нескольких образов на ноде остается свободное место равное размеру локального хранилища минус сумма размеров образов. Если VM много и они разного размера то подобные остатки появятся на всех нодах, уменьшая полезную емкость хранилища. Поэтому нужен процесс который собирает эти остатки путем перераспределения VM по нодам. Как это реализовано в Nutanix?

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

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