Архив за месяц: Июнь 2015

Nutanix Acopolis: как работает High Availability (HA)?

Несмотря на то, что, строго говоря, Nutanix Acropolis, наша встроенная управлялка, «vCenter for KVM», стал доступен пользователям еще в январе, его официальное объявление было задержано, в первую очередь потому, что мы хотели отладить и добавить несколько важных функций, без которых современная подобная система немыслима. Одна из них — функциональность High Availability (HA) для VM на KVM.
Теперь она у нас есть, и вот как это работает.
Сперва — для чего этот HA вообще нужен?

Читать далее

Erasure Coding (EC-X) в вопросах и ответах

Чем отличается Nutanix EC-X от других алгоритмов и реализации Erasure Coding?

Алгоритм оптимизирован для работы на распределенной системе. Использование распределенности, присущей Nutanix, позволяет обрабатывать ситуации с отказом дисков и восстановлением данных быстрее, и с меньшим влиянием на загрузку отдельной ноды кластера.

EC-X также реализован как «постпроцессный» механизм. При записи данные записываются на диски традиционным уже для Nutanix способом Replication Factor, а процессы Erasure Coding, высвобождающие место, начинают работать в фоне, что позволяет свести к минимуму нежелательное влияние дополнительной загрузки CPU системы для основной рабочей нагрузки по вводу-выводу данных.

Как EC-X совместим с другими технологиями уменьшения storage footprint на Nutanix, например дедупликацией и сжатием данных?

EC-X совместим с ними, и может использоваться на том же контейнере, где уже используется дедупликация или компрессия, позволяя еще немного сэкономить объем хранения.
Вот пример:
CapacityOptimization

А вот на контейнере с компрессией:
CompplusECXhighlighted

EC-X работает только для capacity tier (SATA)?

Нет, он работает на всех дисках системы, и на SATA (capacity tier), и на SSD (performance tier).

Алгоритм EC-X обрабытывает только «холодные» данные?

Как уже было сказано выше, алгоритм работает так: данные поступают на диск, и, как и раньше, записываются локально, и, синхронно, куда-то еще в кластере, обеспечивая избыточную копию. Пока все происходит также, как и раньше, это то, что мы называем «метод Replication Factor». Наконец блоки данных перестали активно писаться. Этот этап называется у Nutanix «Write Cold». Они могут продолжать активно читаться пр этом, главное, чтобы экстент, длиной 4MB, перстал именно писаться. После этого он поступает в распоряжение алгоритма EC-X.
Если этот экстент расположен на SSD, то он будет обработан алгоритмом EC-X, и место на диске будет освобождено, даже в случае, если данные в этом экстенте активно читаются, и, значит,расположены на SSD.

Как использование EC-X влияет на производительность?

Так как работа EC-X это постпроцессный алгоритм, он не влияет заметно на производительность операции записи. За единственным исключением, когда записываемые данные последовательно и многократно перезаписываются, уже после первоначальной их записи. Такое поведение вызывает бОльшую загрузку системы, когда они пишутся на контейнер с EC-X, чем когда они писались на контейнер с RF (традиционным методом Replication Factor).
Если вы прогнозируете именно такое поведение записываемых данных, то рекомендуем продолжать использовать RF, и не включать EC-X, или же с бОльшей внимательностью отнестись к профайлингу рабочей нагрузки на системе.
При своей работе алгоритм стремится хранить блоки данных на SSD, а блоки парити — на SATA, что увеличиваеи эффективность именно SSD (performance tier системы), и положительно сказывается на общей производительности системы.

Какие гипервизоры поддерживаются с EC-X?

EC-X это внутренняя функциональность платформы Nutanix, она не зависит от типа гипервизора, и остается доступной для пользователя на любом используемом гипервизоре из поддерживаемых, то есть на VMware ESXi (vSphere), Microsoft Hyper-V и Linux KVM.

Сохраняется ли при использовании EC-X принцип Data Locality (хранение данных VM «рядом с ней», на локальных дисках ноды, где она исполняется)?

Да, Data Locality сохраняется, это также одна из особенностей используемого алгоритма.

Какие типы нагрузок Nutanix лучше подходят для контейнера с EC-X, а какие не подходят?

Во-первых, следует принять во внимание, что на момент написания этого текста, «первая публикация» EC-X в версии NOS 4.1.3 является technical preview, и компания не рекомендует ее для использования в бизнес-критичном продакшне. По всей вероятности к концу года мы опубликуем окончательный релиз EC-X.
Во-вторых, очевидно, что максимум выгоды при минимуме побочных нежелательных эффектов EC-X принесет таким задачам, как файловые сервера, резервные копии и архивы, ISO-репозитории, хранилища электронной почты, разделы для записи и хранения логов.
Нежелательно использовать, или же следует особо внимательно следить за возможными нежелательныи эффектми на разделах, на которых приложения активно перезаписывают уже записанные данные в небольшой промежуток времени.
Однако помните, что EC-X можно назначить на уровне отдельного vDisk Nutanix, что позволит вам достаточно гибко выбирать вариант хранения для данной VM, например один VMDK данной VM может храниться с использованием RF, а другой — с EC-X.

Let’s war begin! EVO:RAIL vs. Nutanix

Ниже перевод оригинального Description к ролику от автора:

Моя компания тестировала гиперконвергентные платформы Nutanix и EVO:RAIL. Хочу поделиться некоторыми результатами тестов, которые я запускал.

Очень простой тест … сколько времени займет развертывание на платформе 50 VM из шаблона (Windows 2008 R2 Enterprise, судя по имени, прим.romx). Шаблон состоит их одного ThickEagerZeroed vmdk размером 60GB. VM разворачивались через скрипт в PowerCLI. У Nutanix это заняло чуть более 1 минуты 35 секунд на все 50 VM. EVO:Rail финишировал за 1 час 45 минут. Сумасшедшая разница!

Nutanix — NX-3050
Четыре ноды, на каждой:
Dual Intel Ivy Bridge E5-2650v2 [16 cores / 2.6 GHz]
256 GB RAM
2x 800 GB SSD, 4x 1 TB HDDs
2x 10 GbE, 2x 1 GbE, 1x 10/100 BASE-T RJ45

В качестве EVO:RAIL по всей видимости фигурировала первая и стандартная модель EVO:RAIL с VSAN 5.0 (напомню, что VSAN 6 до сентября недоступна партнерам для установки в EVO:RAIL), то есть вот такая:
Четыре ноды, на каждой:
• Two Intel E5-2620v2 six-core CPUs
• 192GB of memory
• One SLC SATADOM or SAS HDD for the ESXi™ boot device
• Three SAS 10K RPM 1.2TB HDD for the VMware Virtual SAN™ datastore
• One 400GB MLC enterprise-grade SSD for read/write cache
• One Virtual SAN-certified pass-through disk controller
• Two 10GbE NIC ports (configured for either 10GBase-T or SFP+ connections)
• One 1GbE IPMI port for remote (out-of-band) management

Да, чуть меньше памяти, да, существенно слабее процессор и сильно меньше ядер, пусть SAS, вместо SATA, но вчетверо меньше SSD, все равно разрыв слишком огромен. Скорее всего сказывается отсутствие поддержки VAAI. У VSAN приходится делать полную физическую копию шаблона в VMDK целевой машины, и параллельные процессы копирования быстро забивают канал к дискам доверху, в то время, как у Nutanix за счет copy offload и функции быстрого клонирования процесс почти моментален, и вот результат.
Да, в VSAN 6 многое поправлено, да, будут больше SSD, но удастся ли наверстать такой огромный разрыв?.. «Покажет время» (с)

Пока же я видел вот такую табличку сравнения на Microsoft Jetstress 2013:

VSANvNutanix

Nutanix CE: иллюстрированное руководство по настройке

Допустим, вы уже получили ссылку и скачали вождеденный ce-2015.06.08-beta.img.gz.
Но что с ним делать дальше?

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

Поэтому вот вам наш Nutanix Community Edition: Getting Started Guide

Nutanix Acropolis: клонируем и запускаем виртуалки с помощью скрипта через RESTful API

В блоге Dwayne Lessner-а показывается, как можно за секунды склонировать сотню VM через вызов REST API, и запустить их командой Acropolis CLI.

Nutanix OS 4.1.3 — что нового

На прошлой неделе я уже мельком упомянул, в посте про Erasure Coding, о том, что выходит в релиз новая версия Nutanix OS (NOS) версии 4.1.3
Вот что в ней заметного из новостей:

Ну, во-первых, это вот он, Erasure Code. Это есть, работает, можно использовать там, где это нужно, но помните, рекомендации Nutanix пока указывают однозначно: это не для production data. Официальный статус фичи — Tech Preview. Это не означает, что это ненадежно или сломано. Нет, это работает, просто для критичных, продакшн данных мы по прежнему рекомендуем использовать для защиты данных Redundancy Factor (RF), то есть хранение копии (одной — RF=2 или двух — RF=3) блока данных. Erasure Code при выходе из строя диска, может вызывать повышенную нагрузку на CPU, как при любом восстановлении из кода избыточности, а это может негативно сказаться на работающем критичном приложении. Увеличивается время восстановления и нагружается процессор.
Однако отметьте, что при обычной работе Erasure Code не приводит, судя по нашим данным, к существенному влиянию на скорость доступа. Вышесказанное, про повышенную нагрузку, относится только к процессу восстановления.
Erasure Coding можно произволно назначать для контейнера, причем можно будет переключать между RF и EC «на ходу».

Появилась синхронная репликация для гипервизора Hyper-V. Теперь можно использовать это для создания катастрофоусточивых структур контейнеров «растянутых» по площадкам между разными кластерами Nutanix.
Однако обратите внимание, при использовании Syncronous Replication под Hyper-V пока не поддерживается работа VSS.

Теперь в Nutanix OS 4.1.3 поддерживается VMware vSphere 6.0

В Acropolis встроен Image Service, который поможет при миграции из vSphere в KVM, о котором я писал в посте на прошлой неделе. В 4.1.3 все становится еще чуть проще и «однокнопочнее» :)

acro-image-service

В KVM Acropolis появился полноценный HA (High Availability), теперь VM на остановившейся ноде автоматически перезапустится на живой. У HA есь два режима работы, это режимы «Best Effort» и «Reserve Space». Эти режимы призваны решить ситуацию, когда у нас на работающих нодах просто нет места для запуска на них VM с остановившейся ноды (например, у нас есть три ноды с 80% загрузкой, и одна нода встает. На оставшизся просто нет места для всех VM отказавшей, как быть?). Подробный рассказ о этих режимах стоит отдельной заметки, пока только упомяну, что они есть. Статус HA пока — Tech Preview.

В Acropolis теперь есть свой Volume Manager. Эта фича пока также в Tech Preview и не рекомендуется к применению в продакшн.

Пофиксены текушие security vulnerabilities и баги там и сям.

Наконец-то дошли руки сделать возможность отключения разлогинивания консоли PrismUI после 15 минут неактивности в ней. %)

Nutanix CE: совместимое железо

Итак, Nutanix CE (Community Edition) официально запустился. У меня, как сотрудника, уже появился доступ к специальному подфоруму на next.nutanix.com, и там уже появились люди, правда пока неясно, есть ли доступ у кастомеров. Если у кого уже пришел доступ после регистрации — пишите.
В одной из тем форума выложен, собственно, образ Nutanix CE, в виде полуторагигового tar.gz
У меня — скачивается. Ждем подтверждения от кастомеров, что им это тоже доступно.
А пока — вот вам в одной из тем официальный список compatible hardware.

nutanix-ce-compat-hw

Erasure code — больше пространства хранения на Nutanix

«Теперь об этом можно написать» (с) :)
Текст был написан, и даже опубликован несколько месяцев назад на Хабре, однако нам надавали по шапке за фальстарт и упоминание еще не зарелизенной фичи, и мы были вынуждены материал убрать. На .NEXT вчера ночью про Erasure Coding было объявлено официально, как и про то, что он выходит в релиз в версии NOS 4.1.3, так что теперь эта статья имеет право на публикацию.

Если вы уже читали мой рассказ ранее про то, как устроена NDFS, Nutanix Distributed File System, основа того, как оно все сделано в Nutanix, то наверняка отметили, что расход дискового пространства в NDFS, он, в общем, довольно «щедрый».

Напомню, что мы не используем RAID, в его классическом понимании, когда, например, для диска держится его зеркальная копия (RAID-1), или когда для группы дисков рассчитан дополнительный код избыточности (RAID-5 или 6). Вместо этого, мы храним блок записанных на дисках данных в двух (или даже трех) местах на разных дисках и даже разных нодах. Эта схема называется у нас RAIN (Redundant Array of Independent Nodes, в пику RAID, который то же само, но …Disks). Но, с точки зрения емкости дисков системы, RF=2, то есть вариант, когда для каждого блока хранится его копия, расход места эквивалентен RAID-1, то есть под данные нам доступны 50% raw-емкости (минус еще какой-то, переменный, процент на служебные структуры и информацию, но это опустим тут).

Да, отказоустойчивость, надежность, быстрое (минуты) восстановление при сбоях, все это так. Но все равно расход довольно большой. Особенно для людей, все еще привычно мыслящих про диски в величинах емкости raw или RAID-5. И можно сколько угодно говорить, что RAID-5 — плох и ненадежен, что он медленный на запись, что, наконец, при нынешних ценах на HDD, плата за повышенную надежность и производительность гигабайтами, отдаваемыми на отказоустойчивость, невелика, в сравнении с тем, что нам дается взамен за них. Все равно. «У нас стоит в системе четыре терабайтных диска. Почему же у нас остается даже меньше двух терабайт под наши данные?»

Вот поэтому у Nutanix появилась идея, которая сейчас активно воплощается. Занимается ей в Nutanix, кстати, «наш», русскоязычный программист.
Это то, что называется «erasure code». Как это часто бывает у инженеров, название «несамоописывающее», и прижилось уже никто не знает почему. По-русски это будет, правильнее всего — «код избыточности». Вот как это работает.

Если у нас есть данные, которые нас жаба давит держать на «RAID-1», то есть в режиме Replication Factor (RF) = 2, то мы можем переключить для этих данных режим хранения с RF=2(или =3) на erasure code. При этом, у нас начинает работать специальный фоновый процесс, похожий на то, как у нас осуществляется дедупликация в кластере, и, через какое-то время, вместо блока-и-копии у нас на дисках начинает храниться на дисках кластера нодов блок-блок-блок-…-и_избыточная_информация_для_них, которая позволяет однозначно восстановить содержимое блока в этой цепочке, если он будет утерян, например в результате отказа диска одной из нод.
И когда этот процесс заканчивает обработку в фоне, вместо блока и его копии в кластере, у нас начинает храниться множество блоков, объединенных в группу, плюс отдельный блок и кодом избыточности. И в том контейнере данных, где мы включили erasure code вместо RF, мы получаем тот же объем хранящейся информации, и при этом больше свободного места для новой.
Опять же, это немного похоже на postponed deduplication.

Наверняка вы уже готовы тут сказать: «Ну, вы просто «изобрели» велосипед RAID-5!», не совсем так на математическом уровне, но отдаленно принцип похож, да.

«Расплата» тут (ничего без расплаты не бывает, как мы помним) состоит в том, что за больше места на дисках для данных мы платим более высокой загрузкой CPU, в случае необходимости восстановления данных. Понятно то, что, вместо простого копирования, тут нам придется восстанавливать содержимое блока из содержимого прочих блоков данных и избыточного кода, и это существенно более ресурсоемкая процедура.

Важно также то, что, с помощью Erasure Code, избыточности достаточно, чтобы восстановиться при отказе двух дисков, нод, или прочих компонентов кластера, то есть это, с точки зрения уровня отказоустойчивости, эквивалент RF=3, для которого на дисках объем usable равен около 33% от raw.
А в случае erasure code?
Это зависит от размеров кластера. Чем он больше по числу нод — тем выгоднее, тем больше величина разницы.

Для 4-нодового кластера на 80TB raw получается примерно 40TB usable при RF=2. При переключении контейнера в erasure coding пространство usable составит — 53TB.
На 5 нодах — 100 — 50 — 75, на 6 нодах — 120 — 60 — 96, на 7 — 140 — 70 — 116. Как видите, с увеличением размеров кластера, «эффективность хранения» для erasure code также растет.

Для чего и куда это можно применить?

Прежде всего, это позволяет понизить стоимость хранения ($/GB), что особенно актуально для «cold storage»и capacity nodes, в особенности на больших кластерах, в том случае, если вы храните на Nutanix информацию, пусть и ценную, но не слишком «горячую», активную. И готовы за большее свободное пространство заплатить повышенной загрузкой CPU и более длительным временем восстановления.
При этом, обратите внимание, в штатном режиме, при обычной работе с данными под erasure code, загрузка CPU при обращении к данным существенно не повышается, только при восстановлении.
Вы также вольны выбирать, как именно защищать избыточностью ваши данные. Вы можете на одном кластере держать разные контейнеры для данных, одни — с RF=2, другие — RF=3, а какие-то — с erasure code. Для данных, достаточно горячих и критичных, вы можете выбрать какой-то из RF, а для не таких «горячих», и лежащей на нодах, где повышенная нагрузка CPU при восстановлении не критична для нас — Erasure Code.
Опять же: выбор режима для хранения данных — за вами, и зависит от вашего выбора и зависит от ваших приоритетов.

Erasure Code появится в доступности в очередном релизе Nutanix OS, который приедет на ваши системы Nutanix со штатным обновлением. Обновление Nutanix, кстати, не приводит к остановке работы виртуальных машин и недоступности данных, и система обновляется Over-The-Air, «как айфон», но об этом — в следующем посте.

Как перенести VM из VMware ESXi в Nutanix KVM?

Я уже упоминал про то, что мы, в Nutanix, можем легко мигрировать виртуальные машины из VMware vSphere в среду KVM, без необходимости заново создавать их. Просто переносом файла виртуального диска этой виртуальной машины и запуском новой, с использованием содержимого этого виртуального диска, но уже из KVM. Такая простая процедура может помочь при миграции из платного VMware в бесплатный и свободный KVM, так как нет необходимости заново создавать виртуальную машину, инсталлировать OS, переносить приложения, и так далее. В результате миграция занимает минуты, вместо часов, и может даже быть автоматизирована.

Я даже писал тут краткий гайд по такому переносу. Однако гайд получился уж совсем краткий. И сегодня я публикую перевод подготовленного в Nutanix подробного пошагового плана процесса переноса виртуальных машин из vSphere в KVM, на примере VM с Windows.
Читать далее