"Главная книга" Nutanix *

русский перевод


Данная страница представляет собой перевод Nutanix Bible, создаваемой и поддерживаемой Стивом Пойтрасом,
архитектором и евангелистом компании Nutanix

Данный перевод призван помочь русскоязычным пользователям поближе познакомиться с решениями компании Nutanix

Перевод стал возможным благодаря компаниям:

  • Navicadata LTD. - дистрибьютор технологий Nutanix в РФ
  • Alex
  • Roman
  • Maxim
  • Оглавление


    Введение


    Добро пожаловать в Библию Nutanix!

    Я работаю с платформой Nutanix постоянно, пытаясь найти решения различных проблем, а также проверить решения в своей лаборатории.

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

    Существуют следующие локализованные версии:

  • English (Оригинал)
  • Japan
  • Краткий экскурс в историю


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

    Эволюция датацентров

    В самом начале все имело врожденную конвергентность…

    Эра мэйнфреймов

    Мэйнфреймы господствовали на протяжении многих лет и сформировали основные очертания тех систем, которые существуют в настоящее время. Это позволяло компаниям достигать своих возможностей

    Ключевые характеристики мэйнфреймов:

    • Врожденная конвергентность CPU, памяти и устройств хранения;
    • Внутренняя архитектурная избыточность.

    А так же они имели и следующие проблемы:

    • Высокой стоимости;
    • Унаследованной сложности;
    • Отсутствию гибкости и чрезмерной изоляции систем друг от друга.

    Атака «пицца-боксов»

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

    Серверы обладали следующими ключевыми характеристиками:

    • Имели CPU, память и жесткие диски или напрямую подключенное устройство хранения (DAS);
    • Имели большую гибкость чем мэйнфрейм;
    • Обеспечивали доступ через сеть.

    Но при этом имели ряд проблем:

    • Увеличивалось число установленных систем;
    • Низкая или несбалансированная загрузка ресурсов;
    • Сервер часто становился единой точкой отказа (Single Point Of Failure) для вычислительных ресурсов и ресурсов хранения.

    И появилось централизованное хранение данных…

    Бизнес заинтересован в получении прибыли, и данные являются ключевым компонентом в процессе ее получения. При использовании DAS организации желали или А) Больше свободного места, чем было доступно на локальных дисках или Б) Нуждались в том чтобы данные оставались доступными в случае выхода сервера из строя.

    Централизованное хранение данных позволило удовлетворить обе потребности. Бизнес получил большие разделяемые пулы хранения данных, которые так же обеспечивали защиту данных.

    Централизованное хранение данных обладает следующими ключевыми характеристиками:

    • Объединенные ресурсы хранение улучшают утилизацию ресурсов хранения;
    • Централизованная защита данных с помощью RAID обеспечивает доступность данных в случае выхода сервера из строя;
    • Операции ввода/вывода осуществляются через сеть.

    Однако у централизованного хранения данных есть следующие недостатки:

    • Потенциально решение является более дорогим, однако стоимость данных существенно больше
    • Сложность решения (SAN-фабрика, WWPN, RAID-группы, тома, жеские диски и т.д)
    • Различные инструменты управления, разные команды администраторов.

    Появление виртуализации…

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

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

    Ключевые преимущества виртуализации:

    • Абстракция операционной системы от оборудования (виртуальные машины);
    • Эффективное использование вычислительных ресурсов путем консолидации нагрузок;

    Однако у виртуализации есть ряд недостатков:

    • Большее количество элементов управления и сложность управления;
    • В случае отсутствия режима высокой доступности для VM, выход сервера из строя оказывает влияние на большее количество информационных систем;
    • Отсутствие возможности объединять ресурсы;
    • Другие инструменты управления, другая команда администраторов.

    Виртуализация становится более зрелой…

    Гипервизоры становятся очень эффективными и предлагают большое количество функциональных возможностей. С появлением таких возможностей, как например vMotion, HA, DRS у VmWare, пользователи получили возможность обеспечивать режим высокой доступности для виртуальных машин, а так же обеспечивать динамическое перераспределение нагрузки.

    Единственный нюанс  - это зависимость от централизованного хранения данных, в результате чего этапа развития объединяются.

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

    Ключевые преимущества:

    • Объединение и кластеризация вычислительных ресурсов;
    • Возможность динамически распределять нагрузку между вычислительными узлами (технологии DRS/vMotion)
    • Технологии высокой доступности для виртуальных машин позволяют защититься от выхода из строя одного сервера
    • Необходимость централизованного хранения данных

    К недостаткам можно отнести:

    • Более высокие требования к хранению данных при увеличении количества ВМ
    • Требования к масштабированию оборудования хранения приводят к увеличению сложности и увеличению количества оборудования
    • Увеличение стоимости хранения $/Гб
    • Возможность возникновения конфликтов/очередей при доступе к данным
    • Существенное усложнение процесса дизайна систем хранения в связи с необходимостью учитывать:
      • Соотношение количества VM на хранилище / LUN;
      • Количество жестких дисков для обеспечения возможности обработать поток операций ввода/вывода

    SSD – вот спасение!

    SSD помогают минимизировать возможные узкие места в операциях ввода/вывода, обеспечивая существенно большую производительность ввода/вывода, без необходимости устанавливать большое количество обычных жестких дисков.

    Однако, контроллеры и сеть еще не позволяют в полной мере раскрыть возможности возросшей производительности ввода/вывода.

    Ключевые преимущества SSD:

    • Существенно более высокая производительность ввода/вывода чем у традиционных жестких дисков
    • Существенное сокращение времени поиска

    Недостатки:

    • Узкое место смещается с операций ввода/вывода диска на контроллеры/сеть;
    • Изоляция;
    • Сложность конфигурации систем хранения.

    Взгляд на важность задержек (латентности)

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

    Операция

    Значение

    Наносекунды

    Значение

    Миллисекунды

    Доступ к кэш-памяти L1

    0,5

    нс

     

     

    Brach misperdict

    5

    Нс

     

     

    Доступ к кэш-памяти L2

    7

    Нс

     

     

    Mutex блокировка/разблокировка

    25

    нс

     

     

    Доступ к оперативной памяти

    100

    Нс

     

     

    Сжатие 1Кб с помощью Google Snappy

    3 000

    Нс

     

     

    Отправка 1 Кб через сеть 1 Гбит/с

    10 000

    Нс

    0,01

    мс

    Чтение 4 Кб случайных данных с SSD

    150 000

    нс

    0,15

    Мс

    Последовательное чтение 1 Мб данных из памяти

    250 000

    нс

    0,25

    Мс

    RTT в пределах одного ЦОД

    500 000

    Нс

    0,5

    Мс

    Последовательное чтение 1 Мб данных c SSD

    1 000 000

    Нс

    1

    Мс

    Поиск данных на жестком диске

    10 000 000

    Нс

    10

    Мс

    Последовательное чтение 1 Мб данных c HDD

    20 000 000

    Нс

    20

    Мс

    Пересылка пакета данных Калифорния- Нидерланды-Калифорния

    150 000 000

    Нс

    150

    мс

    Из таблицы видно, что CPU может обеспечить доступ к кэш-памяти за 0,5 – 7 нс (L1 – L2). Для оперативной памяти это время составляет порядка 100 нс, в то время как для операции чтения с SSD при размере блока 4K значение составляет порядка 150 000 нс или 0,15 мс.

    Проведем некоторые вычисления…

    Если мы возьмем обычный SSD корпоративного уровня (в нашем случае Intel S3700 - SPEC), то он способен обеспечить следующее:

    • Случайные операции ввода/вывода
      • Случайные операции чтения блоками по 4К: до 75 000 IOPS;
      • Случайные операции записи блоками по 4К: до 36 000 IOPS.
    • Пропускная способность при последовательной записи:
      • Постоянный процесс последовательного чтения: До 500 Мб/сек;
      • Постоянный процесс последовательной записи: До 460 Мб/сек.
    • Латентность:
      • Чтение: 50 нс.
      • Запись: 65 нс.

    Итак, для начала давайте посмотрим на пропускную способность каналов…

    Для подключения классических систем хранения используется несколько основных типов каналов связи:

    • Fiber Channel (FC)
      • 4- , 8-, 16Гбит
    • Ethernet (FCoE)
      • 1-, 10-, (40-Гбит Infiniband),

    Для расчетов, производимых ниже, будем использовать пропускную способность в 500 Мб/сек для чтения и 460 Мб/сек для записи, доступные при использовании Intel S3700.

    Сделанные расчеты получились следующие:

    numSSD = ROUNDUP((numConnections * connBW (in GB/s))/ ssdBW (R or W))

    где,

    • NumSSD – необходимое количество SSD-дисков;
    • numConnections – количество установленных соединений;
    • connBW – пропускная полоса соединений;
    • ssdBW – пропускная способность SSD-диска

    примечание: Округление вверх производится по причине того, что SSD-диск не может быть использован лишь частично.

    Этот расчет так же не учитывает необходимость доступности CPU для обработки всех I/O запросов, и в расчетах используется неограниченная мощность процессора на контроллере

    Пропускная способность сети

    Кол-во SSD необходимых для максимальной пропускной способности сети

    Тип подключения

    Доступная пропускная способность

    Чтение

    Запись

    2-х портовый 4 Гбит FC

    8 Гбит == 1 ГБ

    2

    3

    2-х портовый 8 Гбит FC

    16Гбит == 2 ГБ

    4

    5

    2-х портовый 16 Гбит FC

    32Гбит == 4 ГБ

    8

    9

    2-х портовый 1 Гбит Eth

    2 Гбит == 0,25 Гб

    1

    1

    2-х портовый 10 Гбит Eth

    20 Гбит == 2,5 Гб

    5

    6

           

    Т.е. если вы попытаетесь получить максимум производительности от SSD, сеть может стать узким местом.

    Теперь давайте посмотрим на влияние латентности обеспечиваемой оперативной памятью…

    Обычная латентность для оперативной памяти составляет порядка 100 нс (может меняться), мы можем осуществить следующие расчеты:

    • Латентности локальной оперативной памяти = 100 нс + [накладные расходы ОС/гипервизора]
    • Латентность оперативной памяти доступной через сеть = 100нс + сетевой RTT +  [2х накладные расходы ОС/гипервизора]

    Если мы предположим, что типовое значение RTT в сети составляет примерно 0,5 мс (зависит от производителя сетевого оборудования)или 500 000 нс, то получим:

    • Латентность оперативной памяти доступной через сеть = 100нс + 500 000 нс +  [2х накладные расходы ОС/гипервизора]

    Если мы теоретически будем считать что у нас очень быстрая сеть с RTT равным 10 000 нс, мы получим:

    • Латентность оперативной памяти доступной через сеть = 100нс + 10 000 нс +  [2х накладные расходы ОС/гипервизора]

    Это значит, что теоретически быстрая имеет накладных расходов на 10 000% больше, чем локальный доступ к оперативной памяти. С медленной сетью это значение может достигать 500 000%.

    Для уменьшения этих накладных расходов, и появились технологии кэширования на стороне сервера.

    Смысл всего этого…

    Надеюсь, что приведенные выше расчеты не были скучными, чистая математика, а объективно это некоторые ключевые факторы, которые позволяют понять причины почему мы находимся сейчас здесь.

    Итого:

    1. Неэффективность использования вычислительной мощности привела к появлению виртуализации
    2. Возможности виртуализации, такие как vMotion, HA и DRS нуждаются в централизованном хранилище
    3. Увеличение числа VM привело к увеличению нагрузки и конфликтов на СХД
    4. SSD появились чтобы уменьшить эти негативные моменты, но привели к смещению узких мест на уровень контроллеров/сети
    5. Доступ к кэшу/памяти через сеть приводят к огромным накладным расходам, существенно снижая эффективность их использования
    6. Сложность конфигураций массивов не изменилась
    7. Появление кэша на стороне сервера приводит к снижению нагрузки на систему хранения/ влияния на сеть, однако появляется дополнительный компонент в системе
    8. Nutanix призван обеспечить преимущество таких возможностей как vMotion, HA и DRS используя локальные SSD и HDD
    9. Использование локальных компонент помогает уменьшить влияние узких мест и накладных расходов, которые обязательно возникают при использовании ресурсов через сеть.
    10. Смещает акцент от инфраструктуры, в сторону упрощения решения и упрощения управления.

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

    И вот появляются веб-технологии…

    Книга Web-Scale


    Этот раздел содержит информацию, позволяющую понять основные принципы концепции “web-scale” инфраструктуры и доводы, почему стоит ее стоит использовать.

    Прежде чем начать, хотел бы сразу сразу отметить – web-scale не означает, что вы должны быть гигантом вроде Google, Facebook, Microsoft. Такие решения применимы и будут полезными в любом масштабе (от 3х узлов до бесконечности.)

    Перед тем как мы начнем, давайте зафиксируем некоторые ключевые проблемы, исходя из исторического опыта:

    • Сложность, сложность, сложность;
    • Необходимость постоянного роста;
    • Желание иметь гибкость.

    Вот несколько основных моментов, о которых стоит сказать, когда мы говорим о Web-Scale.

    - гиперконвергентность;

    - построение на базе программно-определяемой архитектуры

    - распределенные автономные системы

    - инкрементальное и линейное масштабирование

    А так же:

    • Основанная на API автоматизация и широкие возможности по аналитике
    • Возможность самовосстановления (“Self-healing”)

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

    Гиперконвергентность

    Наверняка вы уже слышали множество мнений, что же такое гиперконвергентность. Эти мнения часто основаны на компонентах, которые включают в данное понятие. (Сеть, виртуализация или что-то еще).

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

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

    Что все это значит:

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

    Преимущества:

    • Масштабируется типовыми блоками
    • Локализованное I/O
    • Устраняет традиционные вычислительные ресурсы и ресурсы хранения, путем их объединения в единое устройство.

    Построение на базе программно-определяемой архитектуры

    Программно-определяемая архитектура реализует ключевую логику обычного проприетарного или специализированного железа (ASIC/FPGA) в ПО, работающем на стандартном (commodity) серверном оборудовании x86.

    В Nutanix мы перенесли логику традиционных систем хранения данных (дедупликация, компрессия и прочее) в ПО, которые выполняется на каждой CVM, на стандартном серверном оборудовании x86.

    Что все это значит:

    - Перенос ключевой логики с оборудования на уровень ПО, работающем на стандартном серверном оборудовании.

    Преимущества:

    • Частые обновления
    • Исключение зависимости от проприетарного оборудования
    • Использование стандартного серверного оборудования x86 для лучшей экономии

    Распределенная автономная система

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

    Обычно производители говорят, что оборудование должно быть надежным. Зачастую так и есть. Однако, ключевая идея распределённой системы заключается в том, чтобы система «прозрачно» и без прерывания функционирования обрабатывала ошибки, когда оборудование все же выходит из строя. Распределенная система спроектирована, как приспособленная к устранению возникающих ошибок, обеспечивая самовосстановление (self-healing) и автономность.

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

    Еще один способ «положить» систему – порча «мастера», для программных компонент системы, которые использует модель мастер-слейв. На такую ситуацию распределенная система отреагирует выбором нового «мастера» и продолжит функционировать. Для организации распределения процессов компоненты спроектированы с использованием концепции MapReduce.

    Что все это значит:

    • распределение ролей и обязанностей на все узлы системы;
    • использование концепции MapReduce для распределения процессов и задач;
    • использование переопределения в случае, если компонент требует выделенного «мастера»;

    Преимущества:

    • Исключение единой точки отказа (SPOF);
    • Распределение нагрузки для исключения любых узких мест;

    Инкрементальное и линейное масштабирование

    Инкрементальное и линейное масштабирование обеспечивает возможность начала работы   с использованием определенного набора ресурсов, и позволяет линейно увеличивать производительности системы при необходимости. Все конструкции, описанные выше, критичны для реализации такого подхода. Например, традиционно у вас есть три уровня компонентов, для размещения виртуальных машин: серверы, система хранения данных и сеть – все они будут масштабироваться по отдельности, т.е. если вы добавили серверов, вы не добавили производительности системе хранения данных. А при использовании гиперконвергентной платформы такой как Nutanix, когда вы добавляете новый Узел вы масштабируете:

    • количество гипервизоров / вычислительных модулей;
    • количество контроллеров хранилища;
    • производительность и объем хранилища;
    • производительность вычислительных модулей;
    • количество узлов участвующих в распределенных операциях кластера;

    Что все это значит:

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

    Преимущества:

    • возможность начала работы с оборудованием на малом наборе ресурсов, с последующим масштабированием;
    • устранение любых узких мест в инфраструктурном обеспечении;
    • единую и согласованную производительность в любом масштабе.

    Книга Nutanix


    Архитектура

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

    Решение Nutanix, это конвергентное решение объединяющее хранилище и вычислительные модули, которое использует локальные компоненты и создает распределенную платформу виртуализации (или virtual computing platform). Решение представляет собой  поставляемый в едином комплекте аппаратное обеспечение и ПО. Каждое устройство (Block)  состоит из 2 узлов (Nodes)(для устройств 6000/7000 серии) или 4 узлов (для узлов 1000/2000/3000/3050/3060 серий), и имеет  размер 2U.

    Каждый Узел обеспечивает запуск стандартных гипервизоров (на данный момент ESXi, KVM, Hyper-V) и Nutanix Controller VM (CVM). Именно на CVM выполняется ПО Nutanix и обслуживаются все операции I/O для гипервизоров и ВМ размещенных на Узле. Для Узлов Nutanix с запушенной VMware vSphere контроллер  SCSI, который управляет устройствами SSD и HDD, напрямую презентуется в CVM, используя VM-Direct Path (Intel VT-d). В случае с Hyper-V, устройства хранения напрямую презентуются в CVM. Ниже пример логической организации типового узла:

    Вместе, группа Узлов Nutanix формирует распределенную платформу, называемую Nutanix Distributed Filesystem (NDFS).

    NDFS предоставляется Гипервизору, как централизованное хранилище данных, однако все операции ввода/вывода (I/O) выполняются локально для обеспечения максимальной производительности. Подробности того, как на базе  этих Узлов формируется распределенная система можно будет найти далее. Вот пример, как Узлы Nutanix формируют NDFS:

    Компоненты кластера

    Платформа Nutanix состоит из следующих высокоуровневых компонент:

    Cassandra

    Ключевая роль: Распределенное хранилище метаданных

    Описание: Cassandra хранит и управляет всеми метаданными кластера, в распределенной, кластерной структуре типа «кольцо», на основе сильно модифицированной Apache Cassandra. Алгоритм Paxos используется для соблюдения целостности данных. Данный сервис запускается и функционирует на каждом Узле кластера Nutanix. Доступ к Cassandra осуществляется средствами программного интерфейса называемого Medusa.

    Zookeeper

    Ключевая роль: Управление конфигурацией кластера

    Описание: Сервис хранит всю информацию о настройках кластера - входящие в состав кластера Узлы и Блоки, их ip-адреса, статус и прочую информацию. Реализован данный сервис на базе Apache Zookeeper. Сервис запускается минимум на трех Узлах кластера Nutanix, одна из копий назначается лидером. Лидер принимает все запросы и распределяет по остальным копиям сервиса. Если лидер становится недоступным, происходит автоматический выбор нового основного экземпляра (лидера) из существующих копий. Сервис доступен через программный интерфейс именуемый Zeus.

    Stargate

    Ключевая роль: Менеджер операций I/O

    Описание: Stargate отвечает за управление всеми данными и операциями ввода/вывода и является точкой доступа к данным для Гипервизора (посредством NFS, iSCSI или SMB). Сервис работает на всех Узлах кластера Nutanix для локализации операций ввода/вывода.

    Curator

    Ключевая роль: распределенный сервис управления и обслуживания кластера на базе технологий Map Reduce

    Описание: Curator отвечает за операции управления и распределения нагрузки внутри кластера, включая распределение нагрузки между дисками, проактивной очистки данных и так далее. Curator запускается и функционирует на всех Узлах кластера Nutanix, при этом выбирается основной экземпляр сервиса, отвечающий за назначение задач остальным копиям сервиса.

    Prism

    Ключевая роль: пользовательский интерфейс и API

    Описание: Prism представляет собой интерфейс для управления и мониторинга кластера Nutanix и его компонент. Включает в себя Ncli (Nutanix command line interface),  графический интерфейс на базе HTML5  и  REST API. Prism выполняется на всех Узлах кластера, с выделенным основным экземпляром, так же как и у других компонент Nutanix.

    Genesis

    Ключевая роль: Управление сервисами и компонентами кластера

    Описание: Genesis представляет собой процесс, который запускается на всех Узлах кластера Nutanix и отвечает за любое взаимодействие сервисов (запуск, остановку, и т.д), а так же за их начальную конфигурацию.  . Компонент работает независимо от остальных сервисов кластера и не требует того чтобы кластер был сконфигурирован/запущен. Единственным требованием для функционирования Genesis является  запущенный и работающий сервис Zookeeper. Страницы конфигурации кластера cluster_init и cluster_status так же отображаются данным сервисом.

    Chronos

    Ключевая роль: Планировщик задач

    Описание: Chronos отвечает за выполнение  и управление задачами выдаваемыми компонентой Curator, а так же получением информации о их выполнении на узлах. Запуск и выполнение процесса происходит на каждом Узле кластера Nutanix, и контролируется узлом с выборной ролью Chronos Master, которая отвечает за назначение задач и  располагается на том же самом узле что и Curator Master.

    Cerebro

    Ключевая роль: Управление репликацией и DR

    Описание: Cerbero отвечает за репликацию и возможности аварийного восстановления NDFS.  Это включает в себя задачи создания снимков ВМ, репликации на удаленные площадки, миграцию площадки  и процесс обратного восстановления площадки. Cerebro выполняется на каждом Узле кластера Nutanix, таким образом все Узлы участвуют в процессе репликации на удаленные площадки/кластеры.

    Pithos

    Ключевая роль: Управление конфигурацией vDisk.

    Описание: Pithos отвечает за конфигурацию vDisk (файла размещенного в рамках NDFS). Запускается на каждом Узле кластера Nutanix. и работает  поверх Cassandra.

    Структура данных

    Nutanix Distributed FileSystem состоит из следующих высокоуровневых структур:

    Storage Pool (Пул хранения)

    Ключевая роль: Группа физических устройств

    Описание: Пул хранения представляет собой группу PCIe SSD, SSD и HDD устройств, размещённых в рамках Узлов кластера Nutanix. Пул хранения может быть распределен по всем узлам кластера, в случае масштабирования кластера масштабируется и пул хранения. Для достижения максимальной производительности и отказоустойчивости рекомендуется создание единого пула в рамках кластера Nutanix.

    Container (Контейнер)

    Ключевая роль: Группа виртуальных машин/файлов

    Описание: Контейнер является логическим сегментом Storage Pool и содержит группы виртуальных машин и/или файлов. Для контейнера может быть настроен уровень отказоустойчивости (Replication Factor), определяющий сколько копий данных одновременно храниться в рамках NDFS.  Контейнер обычно сопоставляется 1 к 1  с хранилищем данным , ( в случае предоставления доступа по протоколам NFS и SMB).

    vDisk

    Ключевая роль: vDisk

    Описание: vDisk представляет собой любой файл, размещенный в рамках Контейнера, размером более 512Кб, включая vmdk и жесткие диски виртуальных машин. vDisk состоит из экстентов (extent), которые хранятся на диске в виде групп экстентов (extent group).

    Ниже представлена схема взаимодействия NDFS и Гипервизора:

    Extent

    Ключевая роль: Логическая последовательность данных

    Описание: фрагмент логически непрерывных данных, размером 1 Мб, который состоит из N смежных блоков ( зависит от размера блока используемого гостевой ОС). Чтение, запись и изменение экстентов осуществляется на базе суб-экстентов (частей), для обеспечения лучшей гранулярности данных и эффективности хранения. Часть экстента может быть сокращена при перемещении в кэш, в зависимости от количества читаемых/кэшируемых данных.

    Extent Group

    Ключевая роль: Физические непрерывные хранимые данные

    Описание: физический сегмент непрерывных данных, размером 1 или 4 Мб. Эти данные хранятся как файл, на устройстве хранения, управлемом средствами CVM. Экстенты динамически распределяются между группами, для обеспечения распределения данных между разными узлами кластера и дисками, для обеспечения высокой производительности.

    Примечание: С версии 4.0 группы экстентов могут быть размером или 1МБ или 4 МБ, в зависимости от дедупликации.

    Ниже представлена схема взаимодействия данных компонент с различными файловыми системами.

    Еще одна схема представляющая логическую взаимосвязь данных компонент:

    Обзор процессов ввода/вывода

    Процесс обработки операции ввода/вывода в Nutanix состоит и следующих высокоуровневых компонент:

    OpLog

    Ключевая роль: постоянный буфер записи.

    Описание: Oplog идентичен журналу файловой системы и обеспечивает объединение данных генерируемых случайными операциями ввода/вывода, для последующий их консолидации и дальнейшей записи на Extent Store.

    В процессе записи, данные хранящиеся в OpLog синхронно реплицируются в OpLog N узлов CVM, процедура подтверждения записи происходит после осуществления репликации данных и получения ответов от CVM, что данные записаны. Все CVM OpLog принимают участие в процессе репликации и выбираются динамически в соответствии с загрузкой  на конкретный момент времени.

    Для обеспечения максимальной производительности при выполнении операций  ввода/вывода OpLog размещается на SSD дисках презентованных CVM, главным образом это используется для случайных операций I/O.

    Для последовательных операций I/O Oplog не используется и запись происходит напрямую на ExtenStore. Если данные находятся в OpLog и не были сброшены на диск, все запросы на чтение будут напрямую выполненяться из Oplog, до того как данные будут выгружены в ExtenStore /content cache.

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

    Extent Store

    Ключевая роль: постоянное хранилище данных

    Описание: постоянное хранилище объемных данных NDFS, охватывающее SSD и HDD. Хранилище является расширяемым, для облегчения добавления новых устройств или изменения уровней хранения.

    Данные попадающие на данное хранилище могут быть:

    А) консолидированные OpLog

    B) последовательные данные, записанные напрямую минуя OpLog

    Процесс управления жизненным циклом данных Nutanix, динамически определяет уровень, на котором должны быть расположены данные, в зависимости от профиля ввода/вывода, а так же осуществляет перемещение данных между уровнями хранения.

    Content Cache

    Ключевая роль: динамический кэш на чтение

    Описание: Content Cache (или “Elastic Dedupe Engine”) представляет собой дедуплицированный кэш на чтение, реализованный на базе оперативной памяти CVM и SSD .

    Запросы на чтение данных, не находящихся в кэше  помещаются в специальный пул данного кэша - single-touch, который полностью находится в оперативной памяти и использует LRU (Least recently used), пока не будут извлечены из кэша.

    Любые последующие запросы на чтение будут перемещать (фактического перемещения данных не происходит, перемещаются только метаданные кэша) данные в специальный пул - multi-touch который находится в оперативной памяти и на SSD.

    Таким образом возникают два цикла LRU: один для данных находящихся в памяти (пул single-touch), после перемещения данных в multi-touch выполняется второй цикл хеширования.

    Любой запрос на чтение перемещает данные наверх пула multi-touch, где им присваивается новый счетчик LRU.

    Хеширование настраивается на уровне контейнера через UI и по умолчанию отключено. Ниже представлена схема функционирования данного кэша.

    Extent Cache

    Ключевая роль: кэш на чтение, расположенный в оперативной памяти

    Описание: Extent Cache – представляет собой  кэш на чтение, который полностью находится в памяти CVM. Хранит в себе не хешированные экстенты, для тех контейнеров, для которых функция дедупликации была отключена. Начиная с версии 3.5 этот кэш хранится отдельно от Content Cache, однако они могут быть объединены в последующих релизах.

    Разбивка дисков

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

    ВНИМАНИЕ: Вся емкость использует технологию Base 2 Gigibyte (GiB) вместо Base 10 Gigibyte (GiB). Форматирование дисков с использованием файловой система и связанные с этим накладные расходы также принимаются во внимание.*

    Устройства SSD.

    Устройства SSD хранят несколько ключевых компонентов, описанных выше:

    • Nutanix Home (ядро CVM)
    • Cassandra (хранилище метаданных) – подробнее
    • OpLog (постоянный буфер записи) – подробнее
    • Extent Store (постоянное хранилище) – подробнее

    Ниже представлена схема использования SSD диска Узлом Nutanix:

    ВНИМАНИЕ: Начиная с версии 4.0.1 объем OpLog может динамически изменяться, что позволяет extent store динамически расти. Используемые значения позволяют полностью утилизировать OpLog. Необходимо учитывать, что схематичное графическое изображение и пропорции не соблюдаются на приведенных рисунках. Вычисление емкости Remaining GiB осуществляется сверху вниз.

    Например, Remaining GiB используемые для расчета OpLog будет рассчитан относительно оставшейся емкости, после выделения форматированного пространства SSD-диска для домашней директории Nutanix и Cassandra. Большинство моделей поставляется с 1 или 2 SDD, однако такая же конструкция используется и для моделей с большим количеством SSD-дисков. Т.е. если мы применим данным пример для Узлов 3060 или 6060, которые укомплектованы 2x 400 Гб SSD мы получим 100GiB для OpLog, 40GiB для Content Cache и примерно 440Gib для Extent Store для каждого Узла кластера.

    Для Узлов 3061, которые имеют 2х 800Гб SSD будет выдано 100GiB для OpLog, 40GiB для Content Cache и примерно 1.1 TiB для Extent Store SSD для каждого Узла.

    Устройства HDD.

    Поскольку устройства HDD  используются для хранения больших объемов данных их разбивка намного проще:

    • Зарезервированное пространство Curator (Хранилище Curator) - ПОДРОБНЕЕ
    • Extent Store (постоянное хранилище)

    Например, если мы применим данный пример к Узлам 3060, которые содержат 4х1Тб HDD мы получим 80GiB зарезервированных для Curator, и 3,4 TiB для Extent Store, для каждого Узла.

    Для Узлов 6060 имеющих 4x4TB HDD мы получим 80 GiB заразервированных для Curator и примерно 14 TiB  для Extent Store HDD, для каждого Узла.

    ВНИМАНИЕ: Приведенные значения актуальны для релиза 4.0.1 и могут отличаться от релиза к релизу.

    Как это работает

    Защита данных

    Платформа Nutanix в настоящее время использует коэффициент отказоустойчивости, иначе называемый фактор репликации (replication factor - RF) и контрольные суммы для обеспечения избыточности и доступности данных, в случае сбоя или повредждения дисков или Узлов. Как было описано выше, Oplog функционирует как область для консолидации входящих операций записи на высокопроизводительных SSD дисках.

    После записи данных на локальный Oplog данные синхронно реплицируются на OpLog одной или двух CVM (зависит от RF), только после выполнения данной операции возвращается подтверждение (Ack) о том, что данные успешно записаны на хост. Такой подход гарантирует наличие данных, как минимум в двух или трех независимых местах для обеспечения отказоустойчивости.

    ВНИМАНИЕ: Для RF3 требуется минимум 5 узлов, поскольку метаданные будут иметь уровень репликации RF5. Уровень RF для хранения данных настраивается через Prism и назначается на уровне контейнера. Все Узлы участвуют в репликации OpLog для исключения любых "горячих узлов" и обеспечения линейного прироста производительности при масштабировании. Пока данные записываются для них вычисляются контрольные суммы, которые сохраняются как часть метаданных. Затем данные асинхронно пермещаются на Extent Store где неявно поддерживается RF. В случае выхода их строя диска или Узла данные будут перереплецированы между всеми Узлами для поддержания RF. Каждый раз, когда данные считываются для них вычисляется контрольная сумма, чтобы убедиться что данные являются целостными. В случае, если контрольная сумма и данные не соответствуют реплике данных - данные будут прочитаны из копии и ими будет заменена недействительная копия данных. Ниже приведен пример данного процесса и то как логически это выглядит.

    Распределение данных

    Так как платформа Nutanix является конвергентной (вычислительные мощности + хранилище), локализация ввода/вывода и хранение данных являются ключевым элементом  к производительности кластера и функционирующих на нем виртуальных машин. Как было сказано в разделе "Обзор процессов ввода/вывода" все операции чтения/записи обслуживаются локальной CVM расположенной на каждом гипервизоре рядом с обычными ВМ. Данные виртуальных машин обслуживаются локально через CVM и располагаются на локальных дисках, находящихся под контролем CVM.

    Когда ВМ перемещается с одного Узла на другой (или в случае события HA) данные недавно мигрировавшей ВМ будут обслуживаться локальной CVM, расположенной на новом Узле. В процессе чтения старых данных (расположенных теперь на удаленном Узле/CVM) операции I/O будут перенаправлены локальной CVM на удаленную CVM. Все операции записи будут осуществляться локально. NDFS определит операции чтения/записи поступающие с другого Узла и запустит фоновый процесс миграции данных с удаленного узла на новый узел, для того, чтобы процессы чтения/записи выполнялись локально. В первую очередь будут перемещены те данные, для которых выполняются операции чтения, чтобы не нагружать сеть.

    Ниже представлена схема, отражающая каким образом данные следуют за ВМ, в процессе ее перемещения между Узлами.

    Масштабируемые метаданные

    Метаданные это ядро любой интеллектуальной системы и имеют критически важное значение для любой файловой системы или системы хранения данных.  С точки зрения NDFS есть несколько ключевых структур являющихся критичными для  функционирования системы:

    - метаданные должны быть целостными 100% времени (строго консистентными)

    - метаданные должны быть масштабируемы

    - метаданные должны обеспечивать обработку параллельных запросов

    Как было сказано выше (в разделе Архитектура), NDFS использует структуру "ring like" такую как хранилище ключ-значение, которое хранит основные метаданные хранимых данных и другие метаданные платформы (такие как статистика, и прочее). Для обеспечения доступности и отказоустойчивости метаданных RF используется нечетное количестве Узлов (3, 5 и так далее).

    Во время записи или обновления метаданных, строка записывается на Узел в кольце, и затем реплицируются на n-узлов (где n зависит от размера кластера). Большинство узлов должны дать согласие используя алгоритм Паксос перед тем, как что-либо будет записано в хранилище метаданных. Это обеспечивает строгое соответствие для всех данных и метаданных хранимых как часть платформы. Ниже представлен пример вставки/обновления метаданных для кластера из 4 узлов.

    Производительность при масштабировании еще одна важная структура для метаданных NDFS. В отличие от традиционных моделей с двумя контроллерами или моделей с выделенным "мастером", каждый Узел Nutanix отвечает за подмножество всех метаданных платформы. Это позволяет избежать традиционных узких мест, позволяя всем Узлам кластера работать с метаданными. Последовательная система хеширования используется, чтобы свести к минимуму перераспределение ключей во время изменения размеров кластера (добавление или удаление узлов). Когда кластер масштабируется (например с 4 до 8 узлов), узлы вставляются по кольцу между уже существующими узлами, для обеспечения "осведомленности блоков" (“block awareness”) и надежности. Ниже приведен пример кольцо метаданных, и то как оно масштабируется.

    Shadow Clones (Теневые клоны)

    NDFS имеет функцию называемую ‘Shadow Clones’, что позволяет обеспечить распределенное кэширование данных отдельных vDisk или данных ВМ в сценарии  с большим количеством одновременных операций чтения («multi-reader»). Хорошим примером является процесс массового развертывания VDI, путем создания множества линкованных клонов ('linked clones') для которых запросы на чтение будут перенаправляться центральному мастеру или базовой ВМ ('Base VM'). В случае VMWare View это называется репликой диска, чтение с которого осуществляется всеми связанными клонами, а в случае использования XenDesktop - MCS Master VM.

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

    Локализация данных и операций ввода/вывода являются ключевыми факторами для обеспечения максимально возможной производительности ВМ и ключевыми элементами NDFS. При использовании теневых клонов, NDFS будет следить за тенденциями доступа к vDisk, аналогично тому, как это происходит при распределении данных.

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

    В случае с VDI это подразумевает реплика может быть закеширована на каждом узле и все запросы на чтение для базовой ВМ будут выполняться локально.

    Внимание: Данные будут перемещены только для чтения для того, чтобы не нагружать сеть и обеспечить эффективную утилизацию кэша. В случае, если Базовая ВМ изменяется, Теневые клоны будут сброшены и процесс начнётся снова. Теневые клоны включены по умолчанию (начиная с 4.0.2) и могут быть включены/выключены с использованием команды NCLI: ncli cluster edit-params enable-shadow-clones=<true/false>. Ниже приведен пример, как работает технология теневых клонов и обеспечивается распределенное кэширование.

    Elastic Dedupe Engine (Content Cache)

    Elastic Dedupe Engine представляет собой функцию NDFS обеспеченную на программном уровне, позволяющую обеспечить дедупликацию данных на уровнях хранения HDD (объем) и SSD/Memory (производительность). В процессе получения потоки данных хэшируются с использованием алгоритма SHA-1, с гранулярностью 16K. Данный хэш создается в процессе получения данных, а затем постоянно хранится как часть записанных блоков метаданных.

    Внимание: Изначально для хэшей использовалась гранулярность 4K,  однако тестирование выявило, что 16K предлагает наилучшее сочетание дедупликации и сокращения нагрузки на метаданные. При дедупликации данные попадают в кэш при размере 4K. В отличие от традиционных подходов, которые используют фоновое сканирование, требующее повторного чтения данных, Nutanix выполняет хеширование на лету, в момент получения данных. Для копий данных которые могут быть дедуплицированы на SATA-HDD данные не требуют повторного чтения или сканирования, т.е. в принципе дублирующие копии могут быть удалены. Ниже представлен пример как Elastic Dedupe Engine масштабируется и обеспечивает локализацию запросов чтения/записи:

    Создание хэшей выполняется в процессе приема данных, размер которых 64K или более. Для вычисления SHA-1 используются встроенные функции процессоров Intel, что позволяет минимизировать накладные расходы на CPU. В случаях когда создание хэшей не выполняется в процессе получения данных (например, когда размер данных мал), хэширование может быть выполнено как фоновый процесс. Elastic Deduplication Engine распределяется между всеми уровнями хранения - HDD (объем) и SSD (производительность).

    Когда задублированные данные определены, фоновый процесс будет удалять дубликаты данных используя возможности NDFS Map Reduce (curator), основываясь на наличии  множества копий одинаковых хэшей. Данные, для которых выполняется процесс чтения, будут перенесены в NDFS Content Cache который является кэшем расположенным на всех уровнях хранения. Любые последующие запросы для данных имеющих тот же хэш будут осуществляться напрямую из кэша. Для того, чтобы узнать больше о Content Cache и структуре пулов, пожалуйста вернитесь к разделу Обзор процессов ввода/вывода и посмотрите подсекцию Content Cache (ссылка). Ниже представлен пример, как Elastic Dedupe Engine взаимодействует с процессами ввода/вывода NDFS.

    Вы можете проверить коэффициент дедупликации через Prism, на странице Storage>Dashboard.

    Компрессия

    Nutanix Capacity Optimization Engine (COE) отвечает за выполнение преобразования данных для увеличения эффективности хранения данных на диске. На данный момент, компрессия является одной из ключевых особенностей COE,  обеспечивающих оптимизацию данных.  NDFS предоставляет возможность выполнения компрессии как «на лету» так и в виде постобработки данных, чтобы наилучшим образом удовлетворить потребности заказчика в зависимости от типа хранимых данных. Онлайн компрессия будет осуществлять сжатие последовательных потоков данных или больших операций ввода/вывода в памяти, перед записью их на диск. Постобработка, в свою очередь, предполагает запись данных на диск как обычно (в несжатом виде), а затем использует процесс Curator для выполнения сжатия данных в рамках всего кластера.

    Когда онлайн компрессия включена, но потоки ввода/вывода являются случайными, данные будут записаны в несжатом виде в OpLog, объединены и затем сжаты в памяти, перед осуществлением записи на Extent Store. Используемая библиотека сжатия Google Snappy обеспечивает хорошие показатели сжатия при минимальной нагрузке на вычислительные мощностей и очень высокую скорость компрессии/декомпрессии. Ниже представлен пример, как онлайн сжатие взаимодействует с процессами ввода/вывода NDFS:

    При компрессии в виде процесса постобработки, все новые операции записи будут записаны без сжатия, как обычные потоки ввода/вывода NDFS. Через определенный промежуток времени (задержка компрессии), который настраивается, данный становятся «холодными» и перемещаются  на уровень SATA-HDD посредством ILM. После завершения данного процесса данные будут готовы для сжатия. Процесс постобработки использует библиотеку Curator MapReduce. В процессе выполнения компрессии данных задействуются все Узлы . Процесс сжатия данных останавливаются  процессом Chronos. Ниже показан пример того как процессы постобработки взаимодействуют с процессами  ввода/вывода NDFS, во время записи.

    В процессе чтения, данные сначала декомпрессируются в памяти, а затем передаются в поток чтения. Для данных, к которым осуществляется множество запросов на чтение выполняется декомпрессия на уровне хранения HDD, затем данные могут быть переданы ILM для перемещения на уровень SSD, и будут храниться в кэше. Ниже представлен пример того, как декомпрессия взаимодействует с процессами ввода/вывода  NDFS, во время чтения.

    Вы можете проверить уровень компрессии через Prism, на странице Storage>Dashboard.

    Сеть и процессы ввода/вывода

    Платформа Nutanix не использует никакой выделенный бэкплейн для взаимодействия между узлами, а использует стандартную телекоммуникационную сеть с пропускной способностью 10G.. Для выполнения всех операции чтения/записи при взаимодействии с хранилищем данных из виртуальных машин, функционирующих на узле Nutanix, гипервизор использует выделенную приватную сеть. Таким образом запросы на чтение и запись отправляются гипервизором на приватный ip-адрес локальной CVM. Затем, CVM выполняет репликацию данных с другими узлами Nutanix через интерфейс с IP-адресом из внешней сети 10G. Операции чтения, в основном, выполняются локально и не загружают сеть; таким образом основную нагрузку на данную сеть генерируют процессы репликации и сетевого взаимодействия ВМ. Однако, в случае когда локальная CVM недоступна или данные находятся на других узлах, CVM будет перенаправлять запросы на другие CVM кластера Задачи запускаемые на всех узлах кластера, например такие как балансировка нагрузки на диски, будут временно генерировать операции ввода/вывода через сеть 10GbE. Ниже представлена схема отражающая использование публичной и приватной сетей 10GbE  потоками чтения/записи ВМ.

    Отказоустойчивость потоков данных

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

    В отличие от традиционной архитектуры, построенной вокруг идеи о том, что оборудование является надежным, Nutanix предлагает другой подход: он предполагает, что в конечном итоге возникнет ситуация, когда оборудование сломается.  Основываясь на таком подходе предполагается, что система должна легко и без прерывания сервиса обработать такую ситуацию.

    Внимание: Это не значит, что используемое оборудование имеет проблемы с  качеством, просто используется другой концептуальный поход. Команды Nutanix, отвечающие за выбор аппаратной платформы и тестирование продукта проводят исчерпывающие тесты контроля качества используемого оборудования.

    Потенциальные уровни отказа

     

    Являясь распределенной, система NDFS, обеспечивает отказоустойчивость компонент, сервисов и CVM на нескольких уровнях:

    • Отказ диска;
    • «Отказ» CVM;
    • Отказ Узла.

    Отказ диска

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

    Воздействие на ВМ:

    • Событие HA: нет
    • Ошибки ввода/вывода: нет
    • Задержки: не влияет

    В случае отказа диска, Curator немедленно выполняет сканирование (MapReduce Framework). Он будет сканировать метаданные (Cassandra) и осуществлять поиск данных на узлах/дисках хранящих реплику данныхкоторые ранее хранились на отказавшем диске,.

    После того, как данные для восстановления и повторной репликации будут обнаружены, Curator выдаст задачи на репликацию их по всем Узлам кластера.

    Стоит подчеркнуть важный момент, что данные распределены между всеми Узлами / CVM/ дисками в платформе Nutanix. Соответственно, все Узлы / CVM/ диски будут принимать участие в повторной репликации данных.

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

    «Отказ» CVM

    «Отказ» CVM может быть охарактеризован, как отключение питания CVM, которое повлекло за собой временную ее недоступность. Система разработана таким образом чтобы обработка такого события была максимально прозрачной. В случае отказа CVM, все операции чтения/записи будут перенаправлены другим CVM в кластере. Механизм выполнения данной операции будет отличаться для разных Гипервизоров.

    Механизм обновления Nutanix, фактически использует этот  механизм, последовательно обновляя все CVM в кластере, при этом в текущий момент времения происходит обновление только одной CVM.

    Воздействие на ВМ:

    • Событие HA: нет
    • Ошибки ввода/вывода: нет
    • Задержки: Потенциально могут  возрасти, в связи с тем что операции ввода/вывода будут осуществляться через сеть.

    В случае «Отказа» CVM все процессы ввода/вывода, которые обслуживались отказавшей CVM будут перенаправлены на другие  CVM в кластере. ESXi и Hyper-V выполняют это посредством процесса, называемого CVM Autopathing который использует HA.py (как “happy”), который выполняет изменение маршрутов, для перенаправления траффика идущего к внутреннему адресу (192.168.5.2) к внешнему IP других CVM в кластере. Таким образом хранилище остается доступным, просто используется удаленная CVM для обслуживания операций ввода/вывода.

    После того, как локальная CVM снова станет доступной и стабильной, временный маршрут будет удален и локальная CVM начнет обслуживать все новые операции ввода/вывода.

    В случае с KVM, для iSCSI  multi-pathing основным является путь к локальной CVM, и два резервных пути для удаленных CVM. В случае если CVM по основному пути будет недоступен, один из резервных путей станет активным.

    Так же как и для ESXi и Hyper-V, при восстановлении локальной CVM будет восстановлен и основной путь.

    Отказ Узла

    Воздействие на ВМ:

    • Событие HA: да
    • Ошибки ввода/вывода: нет
    • Задержки: не влияет

    В случае отказа Узла, событие HA выполнит перезапуск виртуальных машин на других Узлах кластера виртуализации. После перезапуска ВМ продолжат выполнять операции чтения/записи, которые будут обслуживаться их локальной CVM, как обычно.

    Так же как и при отказе диска будет выполнен процесс повторной защиты данных, но для всех дисков Узла.

    В случае когда Узел недоступен продолжительное время, CVM расположенная на нем будет удалена из кольца метаданных. Она будет добавлена обратно в кольцо метаданных, когда Узел будет снова стабильно работать.

    Распределение данных (Disk Balancing)

    NDFS спроектирована как очень динамичная платформа, которая может обеспечивать функционирование различных типов нагрузки. Обеспечивается это использованием узлов различных типов: увеличенные вычислительные мощности (3050 и пр.) и увеличенные ресурсы хранения (60Х0 и пр.) которые могут быть смешаны в одном кластере. Обеспечение равномерного распределения данных является важным моментом, при использовании узлов предоставляющих большие объемы хранения. NDFS имеет встроенную функцию Disk Balancing, которая используется для равномерного распределения данных по кластеру.  Disk Balancing функционирует основываясь на данных о утилизации локальной емкости Узлов и интегрирован с NDFS ILM. Целью его работы является обеспечение равномерного распределения данных между Узлами, при достижении порогового значения объема хранимых на одном из узлов. Ниже представлен пример смешанного кластера (3050+6050) в “несбалансированном” состоянии:

    Disk Balancing использует библиотеки NDFS Curator и запускается как запланированный процесс, в момент когда превышается пороговое значение наполненности дисков (использование локальной емкости узла более, чем n %).  В случае когда данные не сбалансированы между узлами, Curator определит какие данные нуждаются в перемещении и  распределит задачи между Узлами кластера. В случае когда используются одинаковые узлы (например 3050) утилизация будет достаточно однородной.  Однако, если какие-то, работающие на узле, виртуальные машины будут записывать существенно больше данных, чем другие, то может произойти перекос использования дискового пространства между узлами кластера. В таком случае будет запущен Disk Balancing и холодные данные, размещенные на таком интенсивно используемом узле будут распределены между другими узлами кластера. В случаях, когда используются гетерогенные узлы (например 3050 + 6020/50/70), или когда узел используется в режиме “только хранилище” (“storage only”, нет запущенных ВМ, только данные), вероятнее всего будет требоваться перемещение данных. Ниже представлен пример, где показано как выглядит смешанный кластер, после выполнения операции балансировки данных, когда кластер будет находиться в «сбалансированном» состоянии.

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

    Архитектура программно-определяемого контроллера

    Как упоминалось выше, платформа Nutanix является решением основанным на программном обеспечении, которое поставляется в виде единого комплекта ПО + аппаратная платформа. CVM, представляющая собой большую часть ПО разработанного Nutanix и обеспечивающая большую часть логики всего решения, была изначально разработана в соответствии с принципами модульной и расширяемой архитектуры. Основным преимуществом решения является программно-определяемая архитектура и независимость от аппаратной платформы или ее конструктивных особенностей. Учитывая тот факт что функционирование не зависит от каких либо аппаратных компонент или специализированных чипов типа ASIC/FPGA, новые возможности могут быть добавлены простым обновлением ПО. Это значит, что появление новых возможностей (например, дедупликации) может быть осуществлено в процессе обновления на новую версию ПО Nutanix. Это так же позволяет использовать новые возможности ПО, используя ранее закупленные версии оборудования. Например, если вы используете старые версии ПО Nutanix на предыдущем поколении аппаратной платформы (например 2400). Используемые на нем версии ПО не предоставляют возможности дедупликации, однако ее использование могло бы существенно повысить эффективность работы для существующих нагрузок. Для получения данной возможности вы выполняете обновление ПО Nutanix, прямо во время работы платформы и вуаля - теперь у вас есть дедупликация. Это действительно просто.

    Аналогично реализуется и способность создания новых "адаптеров" или интерфейсов для NDFS, которые являются другой ключевой возможностью. Когда продукт впервые был представлен он имел возможность организации чтения/записи из гипервизора только посредством iSCSI, затем появилась возможность доступа посредством NFS и SMB. В будущем вероятно появятся новые адаптеры для различных типов нагрузки и гипервизоров (HDFS и пр.). Опять же, такие возможности добавляются посредством обновления ПО. Это противоречит подходу большинства стандартных инфраструктур, где обновление аппаратной платформы или приобретение ПО является нормальным требованием для получения "новейших и величайших" функций. С Nutanix все иначе, так как все функции обеспечиваются программным обеспечением они могут функционировать на любой аппаратной платформе, любом гипервизоре и могут быть добавлены путем простого обновления ПО. Ниже мы покажем логическую схему того, что из себя представляет Software-Defined Controller.

    Многоуровневое хранение данных и приоретизация

    Раздел Disk Balancing рассказывал  о том, как емкость хранилища объединяется из доступных ресурсов всех узлов кластера Nutanix и о том, что ILM используется для размещения горячих данных локально. Похожая концепция применима к уровням хранения (SSD и HDD) распределенных по всем узлам кластера, где NDFS ILM так же отвечает за выполнение задач перемещения данных. Локальные SSD-диски узлов кластера всегда имеют высший приоритет для всех операций ввода/вывода, создаваемых виртуальными машинами, размещенными на данном узле, однако все ресурсы всех SSD дисков доступны всем узлам кластера. Уровень SSD всегда будет явятся важнейшим компонентом для гибридных хранилищ, так как они предлагают наилучшую производительность. Приоритет уровней хранения может быть отображен так:

    * Последовательная запись может быть сконфигурирована таким образом, что запись будет осуществляться сразу на HDD, минуя SSD.

    Специфические типы ресурсов (такие как SSD, HHD и др.) собраны вместе и формируют хранилище  распределенное между всеми узлами кластера. Это предполагает, что все узлы кластера могут использовать все доступное дисковое пространство, вне зависимости от того расположено оно локально или нет. Ниже приведен пример как организованы пулы уровней хранения:

    Напрашивается вопрос - что происходит, когда локальные SSD на узле будут заполнены данными? Как сказано в разделе Disk Balancing, ключевая концепция - постараться сохранить равномерное использование устройств, в пределах уровней хранения. В случае, когда локальные SSD-диски узла становятся практически полностью заполненными, механизм балансировки переместит самые холодные данные с локальных SSD на удаленные SSD расположенные на других узлах  кластера. Это позволит освободить пространство на локальных SSD для обеспечения возможности локального узла записывать на локальные SSD, избегая передачи данных по сети. Ключевым моментом, который стоит упомянуть, является что все CVM и SSD используются для таких удаленных операций ввода/вывода позволяя исключить появление любых  потенциальных узких мест и улучшить эффективность при выполнении операций чтения/записи через сеть.

    В других случаях, когда совокупная утилизация уровня хранения достигает определенного порогового значения [curator_tier_usage_ilm_threshold_percent (Default=75)], NDFS ILM посредством Curator выполнит задачу, которая выполнит перемещение данных с уровня SSD на HDD. Это позволит привести уровень утилизации хранилища к значению указанному выше, или же может быть выполнена операция освобождения пространства на размер, в соответствии с  другим пороговым значением [curator_tier_free_up_percent_by_ilm (Default=15)], в зависимости от того, какое из двух значений больше. Данные для миграции с SSD на HDD будут выбраны относительно времени последнего доступа к ним. Т.е. когда уровень заполненности SSD составляет 95%,  то 20% данных с SSD будут перемещены на HDD (95% –> 75%). Однако, если заполненность SSD равна 80%, то только 15% данных будут перемещены на HDD используя минимальное значение высвобождаемого пространства.

    NDFS ILM будет постоянно выполнять мониторинг профиля операций ввода/вывода и при необходимости, осуществлять перенос данных с SSD на HDD и обратно, таким же образом как выполняется перенос горячих данных на локальный узел

    Уровни хранения и Монитогинг

    Платформа Nutanix выполняет мониторинг хранилища на нескольких уровнях, начиная с ВМ/Гостевой ОС вплоть до физических дисков. Имея информацию о всех типах уровней хранения и то, как они взаимодействуют, очень важно иметь решения мониторинга, позволяющее увидеть полную картину происходящего.  Ниже описаны различные уровни и возможные уровни детализации параметров мониторинга об основных операциях на данных уровнях, за которыми происходит наблюдение.

    Уровень виртуальных машин (Virtual Machine Layer)

    Ключевая роль: метрики предоставляемые гипервизором о состоянии ВМ

    Описание: Метрики Виртуальной машины или гостевой ОС получаемые напрямую из гипервизора и отражающие состояние производительности отслеживаемой ВМ и отображает производительность операций чтения/записи.

    Когда использовать: В процессе решения проблем или для уточнения детального состояния на уровне ВМ.

    Уровень гипервизора (Hypervisor Layer)

    Ключевая роль: метрики представляемые гипервизором(ами)

    Описание: метрики уровня гипервизора поступают напрямую с гипервизоров и предоставляют наиболее точную информацию собираемую самими гипервизорами. Эти данные представлены как для каждого гипервизора отдельно, так и для кластера целиком. Этот уровень обеспечивает получение наиболее точных и полных  данных, которые отражают производительность системы и должны использоватьсяя в большинстве случаев. В определенных сценариях гипервизор может сочетать или разделять операции поступающие от виртуальных машин , которые могут показать разницу в метриках, поступающих с ВМ и Гипервизора. Получаемые значения также включают в себя показатели использования кэша, обслуживаемого CVM.

    Когда использовать: В большинстве случаев, этот уровень мониторинга представляет наиболее детальные и ценные метрики.

    Уровень контроллера (Controller Layer)

    Ключевая роль:  метрики предоставляемые CVM

    Описание: метрикиуровня контроллера поступают напрямую с CVM (например страница Stargate на порту 2009) и предоставляют собой данные о том, что front-end получает от NFS/SMB/iSCSI и информацию о любых операциях на back-end (ILM, disk balancing, и т.д.). Собираемые данные могут быть рассматриваться как для одной CVM, так и для всех CVM кластера в агрегированном виде. Метрики доступные на уровне контроллера, обычно соответствуют тем данным, что можно увидеть на уровне гипервизора., однако будут включать в себя все любые операции совершаемые на back-end (ILM, disk balancing, и т.д.). Данные включают в себя информацию о использовании кэша в памяти.  В некоторых случая метрики, такие как IOPS могут не совпадать с данными получаемыми от клиента (NFS / SMB / iSCSI), так как большие операции ввода/вывода могут быть разделены на более мелкие. Однако, такие метрики как, информация о общей нагрузке должна совпадать.

    Когда использовать: Также как и метрики получаемые на уровне гипервизора, метрики получаемые на уровне CMV могут быть использованы для получения данных о нагрузке back-end.

    Уровень диска (Disk Layer)

    Ключевая роль:  метрики предоставляемые дисками

    Описание: Метрики уровня дисков поступают напрямую от физических дисков (через CVM) и предоставляют информацию о происходящем на back-end. Метрики включают в себя информацию о использовании OpLog и ExtentStore, когда операции чтения/записи выполняются на диске. Данные могут быть представлены как для одного диска, так и для всех дисков узла или кластера в целом. В большинстве случаев количество операции ввода/вывода на диск должны совпадать с количеством поступающих операций записи, а так же операций чтения, которые совершаются не из кэша, находящегосяв памяти. Операции чтения, обслуживаемые кэшем в памяти не будут отображены в данных метриках.

    Когда использовать: когда нужно посмотреть как много операций ввода/вывода обслуживается кэш памятью или попадает на диск.

    API и интерфейсы

    Являясь ссновой любой динамичной или программно-определяемой среды,  Nutanix предлагает огромный массив интерфейсов для простого программирования и взаимодействия. Вот основные интерфейсы:

    • REST API
    • NCLI
    • Интерфейсы для автоматизации

    Основой этого является REST API, который предоставляет доступ ко всем функциональным возможностям   и данным доступным  через Prism UI, и позволяет осуществлять возможность простой оркестрации или автоматизации различных операций по упрвалению Nutanix. Это позволяет такому ПО, как VMware’s vCAC или Microsoft’s System Center Orchestrator без труда создавать и автоматизировать рабочие процессы, а Nutanix. Также наличие REST API подразумевает, что любые сторонние разработчики смогут создать собственные пользовательские интерфейсы и передавать команды в Nutanix через  REST. Ниже представлен внешний вид интерфейса предоставляющего доступ разработчикам к API.

    Операции разбиты по типам объектов с которыми они работают. По каждой операции можно просмотреть детальную информацию и примеры вызовов REST.

    Availability Domains

    Домены доступности или “awareness node/block/rack” является ключевой структурой для распределенных систем, в соответствии с которой определяется размещение компонентов и данных NDFS обычно использует информацию о количестве используемых блоков и узлов, однако с ростом кластера может появиться информацию и о используемых стокйках.  Nutanix относится к «блокам» как к шасси, содержащему один, два или четыре «узла». Внимание: Для реализации функциональности Block awareness должно быть использовано не менее 3 блоков, в противном случае будет по умолчанию активирован механизм "node awareness". Для того чтобы быть уверенным в том что механизм block awareness будет активирован, необходимо использовать равномерно заполненные блоки.

    Большинство сценариев и уровней «awareness» (осведомленности) можно найти в начале данного раздела. Три блока требуется для организации кворума. Для примера 3450 является блоком, содержащим 4 узла. Распределение ролей или данных между блоками обеспечивает непрерывную работу, в случае когда происходит отказ блока или есть необходимость в проведении работ на системе. Внимание: Внутри блока только блоки питания и блок вентиляторов являются общим компонентом. Awareness может быть разбита на следующие компоненты:

    • Данные (Данные ВМ)
    • Метаданные (Cassandra)
    • Данные конфигурации кластера (Zookeeper)

    Данные

    Реплики данных NDFS будут записаны на другие блоки  кластера для обеспечения доступности данных, в случае выхода отказа блока или планового отключения блока. Такой подход будет актуален для сценариев RF2 и RF3, а так же для случаев отказа блоков. Хорошим сравнением будет “node awareness” где реплика данных должна быть скопирован на другой узел для обеспечения защиты данных в случае отказа узла. "Block awareness" предоставляет еще лучшую защиту, так как обеспечивает доступность данных в случае выхода из строя блока целиком. Ниже представлена схема как располагаются реплики данных в кластере из трех блоков.

    В случае выхода блока из строя, защита на уровне «block awareness» будет функционировать и осуществит репликацию между работоспособными блоками кластера.

    Метаданные

    Как сказано в разделе Масштабируемые метаданные, Nutanix использует сильно модифицированную платформу Cassandra для хранения метаданных и другой основной информации. Cassandra использует структуру подобную кольцу (ring-like) и реплицируется на N узлов в кольце, для обеспечения целостности и доступности данных. Ниже представлен пример кольца Cassandra для кластера из 12 узлов:

    Cassandra осуществляет репликацию между узлами по часовой стрелке по кольцу. "Block awareness" обеспечивает распределение узлов кластера Cassandra по блокам таким образом, чтобы две одинаковых копии данных Cassandra не располагались в одном блоке Nutanix. Ниже мы приводим пример реализации кольца Cassandra между блоками Nutanix.

    По своей природе  «block awareness» будет обеспечивать наличие минимум двух копий данных, даже в случае отказа блока. (При RF3 для метаданных. В больших кластерах может быть использован RF5). Ниже представлена схема репликации между всеми узлами, для формирования кольца.

    Данные конфигурации кластера

    Nutanix использует Zookeeper для хранения основных конфигурационных данных кластера. Эта роль также является распределённой между блоками для организации доступности в случаях отказа блоков. Ниже представлена схема, отображающая размещение 3 узлов Zookeeper в рамках кластера из трех блоков.

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

    Ниже мы приведем примеры конфигураций и определим, какие уровни "awareness" будут использоваться:

    • < 3 блоков -> "Node awareness"
    • 3+ блоков используемых равномерно -> "Block + Node awareness"
    • 3+ блоков используемых неравномерно
      • если уровень SSD отличается между блоками и > max распределение -> "NODE awareness"
        • например 2x3450 + 1x3150
      • если уровень SSD отличается между блоками и < max распределение -> "Block + Node awareness"
        • например 2х3450 + 1х3350

    Внимание: максимальный уровень распределения вычисляется как 100/(RF+1)

    Например 33% для RF2 или 25% для RF3

    Снимки и клоны

    NDFS предоставляет встроенную поддержку создания снимков и клонов которая может использоваться посредством VAAI, ODX, ncli, REST, Prism и пр. И снимки и клоны используют алгоритм redirect-on-write, являющийся наиболее  эффективным. Как было подробно описано в разделе Структура данных, виртуальные машины состоят из файлов (vmdk/vhdx) которые являются vDisk-ами в платформе Nutanix. vDisk состоит из экстентов, которые являются логически непрерывными блоками данных, хранящимися в виде групп экстентов, представляющих собой физические данные хранящиеся на дисках в виде файлов.

    Когда создается снимок или клон, базовый vDisk помечается как неизменный и создается другой vDisk доступный для операций чтения/записи. Ключевым моментом является то, что обав этот момент vDisk имеют одну и ту же карту блоков, а метаданные привязаны к соответствующим экстентам.

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

    Ниже мы приводим пример как работает создание снимков.

    Тот же метод применяется когда снимок или клон создается с недавно созданного снимка или клона.

    Тот же метод используется для снимков и/или клонов ВМ или vDisk-ов. Когда ВМ или vDisk клонируется, текущая карта блоков блокируется и создается клон. В этот момент просто обновляются метаданные, никаких операций ввода/вывода не происходит.

    Аналогичный метод применяется для клонов клонов; по существу недавно склонированная ВМ функционирует как "Base vDisk", блокируется карта блоков, создаются два "клона": один для склонированной ВМ, а второй для нового клона. Они оба наследует карту блоков, однако потоки ввода/вывода будут направлены в индивидуальные карты блоков.

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

    Любой последующий клон или снимок ВМ/vDisk использует оригинальную карту блока на чтение, а так же вновь созданную для осуществления чтения и записи.

    Катастрофоустойчивость

    Nutanix представляет встроенную функцию аварийного восстановления и репликации данных, основанной на технологии создания снимков и клонов (см. раздел Снимки и клоны). Cerebro является компонентом, отвечающим за управление процессами аварийного восстановления и репликации в рамках NDFS. Cerebro выполняется на каждом узле, с выделенным мастер-процессом (как NFS-master) который отвечает за управление задачами репликации. В случае когда CVM не может связаться с мастер-процессом Cerebro, происходит выбор нового мастер-процесса из выполняемых процессов Cerebro. Страница Cerebro доступна по адресу <CVM ip-адрес>:2020. Функции аварийного восстановления могут быть разбиты на несколько ключевых областей:

    • топология репликации
    • используемые объекты
    • глобальная дедупликация

    Топология репликации

    Традиционно существует несколько ключевых топологий: Один к одному (Site to site), многие к одному (Hup and spoke), многие ко многим (Full and/or Partial mesh). В отличие от стандартных решений которые позволяют использовать только Site to site и Hup and spoke, Nutanix предоставляет модель все-со-всеми или гибкую модель многие ко многим.

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

    Жизненный цикл репликации

    Для репликации Nutanix использует сервис Cerbero, описанный ниже. Сервис Cerbero делится на 2 части:

  • «Мастер Cerbero», функционирующий на одной CVN в кластере, которая выбирается динамически;
  • «Вторичный Cerbero», функционирующий на каждой CVM.
  • В случае, когда на CVM являющейся «Мастером Cerbero» происходит сбой, выбирается новый Мастер. «Мастер Cerbero» отвечает за управление задачами для «вторичных Cerbero» в кластере и координации с удаленным «Мастером(мастерами) Cerbero», в случае удаленной репликации. В процессе репликации «Мастер Cerbero» определяет какие данные должны быть реплицированы, и назначает задачи по репликации данных «Вторичным Cerbero», которые потом сообщают сервису Stargate какие данные и куда должны быть реплицированы. Ниже показана схема процесса репликации:

    При настройке репликации на удаленный сайт, можно использовать прокси, который будет выступать единой точкой для всего трафика репликации и координации процесса репликации, исходящего от кластера Совет: Когда выполняете настройку репликации на удаленный сайт с использованием прокси, всегда используйте IP-адрес кластера, который всегда обслуживается Prism Leader и всегда доступен в случае если CVM(ы) будет недоступна. Ниже показана схема процесса репликации при использовании прокси.

    В некоторых случаях так же является возможным использование SSH-туннеля для настройки репликации на удаленный сайт. В этом случае весь траффик будет идти между двумя CVM Совет: Данный вариант репликации должен использоваться только для решений не являющихся продуктивными, и должен использоваться IP-адрес кластера, для обеспечения доступности Ниже показана схема процесса репликации при использовании SSH-туннеля.

    Используемые объекты

    Аварийное восстановление Nutanix оперирует следующими объектами:

    Remote Site (Удаленная площадка)

    Ключевая роль: Удаленный кластер Nutanix

    Описание: Удаленный кластер Nutanix, используемый как целевой объект для процессов резервного копирования или процессов аварийного восстановления.

    Совет: Убедитесь, что удаленный кластер имеет достаточные ресурсы хранения и вычислительные мощности, для обеспечения отказоустойчивости, в случае выхода из строя основного кластера. Это утверждение актуально и в случае, если удаленный кластер располагается в том же ЦОД, что и основной.

    Protection Domain / PD ( Защищенный домен )

    Ключевая роль: Группа виртуальных машин и/или файлов для защиты

    Описание: Группа ВМ и/или файлов, которые будут реплицироваться на удаленную площадку вместе на основании определенного  расписания. PD может осуществлять защиту контейнера целиком или можно выбрать конкретные ВМ и/или файлы для защиты.

    Совет: Создавайте множества различных PD для разных уровней защиты, определяя разные параметры RPO/RTO. Так же можно создать группу для файлов, требующих распространения между кластерами (образы ВМ, ISO и так далее).

    Consistency Group / CG (Группа консистенции)

    Ключевая роль: Подгруппа ВМ/файлов в PD, для которых необходимо обеспечить взаимное согласованное состояние в случае аварий

    Описание: ВМ и/или файлы являющиеся частью Защищенного домена, которые нуждаются в сохранения взаимного  согласованного состояния в процессе создания мгновенных снимков . Это гарантирует, что при восстановлении данные ВМ/файлы будут в согласованном состоянии. Каждый Защищенный домен может содержать несколько групп консистенции.

    Совет: Группы организуются по признакам ВМ, обеспечивающих реализацию сервиса или приложения, для которого важно сохранить согласованное состояние данных ВМ. Например, сервер приложений и база данных.

    Replication Schedule (Расписание репликации)

    Ключевая роль: Расписание создания клонов и выполнения репликации

    Описание: Расписание создания клонов и выполнения репликации настраивается для ВМ входящих в PD или CG.

    Совет: График выполнения заданий создания снимков должен соответствовать требуемому RPO.

    Retention Policy (Политика хранения)

    Ключевая роль: Количество хранимых локальных и удаленных снимков

    Описание: Политика хранения определяет сколько будет храниться локальных и удаленных снимков. ВНИМАНИЕ: Удаленная площадка должна быть настроена для удаленной репликации.

    Совет: Политика хранения должна соответствовать требуемому количеству точек восстановления для ВМ/файлов.

    Ниже представлена схема логических связей между PD, CG и ВМ/файлами для одного сайта.

    Важно отметить, что для упрощения процесса весь контейнер может быть защищен, однако платформа обеспечивает возможность детализации защищаемых объектов вплоть до ВМ и/или файла.

    Глобальная дедупликация

    Как было сказано в разделе Elastic Dedup Engine ранее, NDFS может осуществлять дедупликацию данных путем обновления указателей метаданных. Такая же концепция применена для организации аварийного восстановления и репликации. Перед отправкой данных по сети, NDFS запросит удаленный сайт есть ли на нем хэши (метаданные), если хэши уже существуют – значит данные уже есть и никаких реальных данных передано не будет, произойдет только обновление метаданных. Если же данных и их хэшей не существует – данные будут сжаты и переданы на удаленный сайт. В данный момент данные существуют на обоих сайтах и используются для дедупликации. Ниже мы покажем пример,  когда существует три сайта и каждый содержит один или несколько PD.

    Взаимодействие с Облаком (Cloud Connect)

    Основываясь на функциональных возможностях NDFS, таких как DR/репликация, CloudConnect обеспечивает реализацию взаимодействия с облачными провайдерами (на текущий момент только Amazon Web Services). В настоящий момент эта возможность обеспечивает функциональность резервного копирования/репликации. Процесс создания «Облачного удаленного сайта» очень похож процессу создания удаленного сайта для использования его для DR/репликации. Когда создается удаленный сайт в облаке, Nutanix автоматически развернет свой экземпляр в EC2 (на текущий момент только m1.xlarge) для использования в качестве узла на удаленном сайте. Образ Виртуальной машины, запущенной в AWS, основан на той же самой версии NOS что используется в локальном кластере. Это означает что могут быть использованы все функциональные возможности используемые при репликации данных (например, глобальная дедубликация, репликация основанная на вносимых изменениях). В случае, когда несколько кластеров Nutanix используют режим CloudConnect они могут илспользовать либо один экземпляр виртуальной машины запущенной в облаке (для конкретного региона) или же развернуть новый экземпляр. Ниже показана логическая схема использования удаленного сайте на базе AWS, используемого опцией Cloud Connect

    Так как удаленный сайт на базе облака (AWS) аналогичен любому другому удаленному сайту Nutanix, кластер может реплицировать свои данные в несколько регионов, в случае если необходимо обеспечить повышенную доступность данных (так как данные будут оставаться доступными в случае полного выхода региона из строя):

    Аналогичные правила по репликации/хранению данных используются для репликации данных используя Cloud Connect. Если данные или моментальные снимки становятся устаревшими, CVM расположенная в AWS удалит их при необходимости в соответствии с существующими политиками. Если репликация осуществляется не часто (например, ежедневно или еженедельно), платформа может включать CVM расположенную в AWS перед выполнением репликации и выключать после завершения регистрации. Данные которые реплицированы в любой регион AWS, так же могут быть получены обратно и восстановлены на любой существующий или вновь созданный кластер Nutanix, который имеет сконфигурированный облачный удаленный сайт в AWS.

    Администрирование

    Важные страницы

    Кроме стандартного пользовательского интерфейса, Nutanix имеет технические страницы для наблюдения за детальной статистикой и метриками. Адреса страниц имеют следующий формат: http://<Nutanix CVM IP/DNS>:<Port/path (указанные ниже)>, например http://MyCVM-A:2009, Внимание: Если у вас адрес в сети отличной от сети CVM, то вам придётся отключить IPtables, для получения доступа к этим страницам.

    # 2009

    Это страница Stargate используемая для наблюдения  за back-end хранилища, должна использоваться только продвинутыми пользователями. В дальнейшем я расскажу, что же отображается на данной странице.

    # 2009/latency

    Страница Stargate используемая для наблюдения задержек на уровне back-end’а

    # 2009/h/traces

    Эта страница Stargate используется мониторинга активности операций

    # 2009/h/vars

    Страница для наблюдения за различными счетчиками

    # 2010

    Страница Curator используется для наблюдения за функционированием процессов curator

    # 2010/master/control

    Страница используется для ручного запуска задач Curator

    # 2011

    Страница Chronos которая предоставляет информацию о задачах назначенных Curator-ом

    # 2020

    Страница Cerebro которая отображает защищенные домены (PD), статус репликации и DR

    # 2020/h/traces

    Страница Cerebro используемая для мониторинга активности операций с PD и репликации

    Команды кластера

    # Проверка статуса кластера

    # Description: Check cluster status from the CLI
    cluster status

    # Проверка статуса локальных сервисов CVM

    # Description: Check a single CVM's service status from the CLI
    genesis status

    # Обновление кластера Nutanix

    # Description: Perform rolling (aka "live") cluster upgrade from the CLI
    # Upload upgrade package to ~/tmp/ on one CVM
    # Untar package
    tar xzvf ~/tmp/nutanix*
    # Perform upgrade
    ~/tmp/install/bin/cluster -i ~/tmp/install upgrade
    # Check status
    upgrade_status

    # Перезапуск кластера из консоли

    # Description: Restart a single cluster service from the CLI
     # Stop service
     cluster stop Service_Name
     # Start stopped services
     cluster start  #NOTE: This will start all stopped services

    # Запуск кластера из консоли

    # Description: Start stopped cluster services from the CLI
    # Start stopped services
    cluster start  #NOTE: This will start all stopped services
    # OR
    # Start single service
    Start single service: cluster start  Service_Name

    # Перезапуск локальных сервисов из консоли

    # Description: Restart a single cluster service from the CLI
    # Stop Service
    genesis stop Service_Name
    # Start Service
    cluster start

    # Старт локальных сервисов из консоли

    # Description: Start stopped cluster services from the CLI 
    cluster start #NOTE: This will start all stopped services

    # Добавление узла в кластер из консоли

    #Description: Perform cluster add-node from CLI
    ncli cluster discover-nodes | egrep "Uuid" | awk '{print $4}' | xargs -I UUID ncli cluster add-node node-uuid=UUID

    # Определение количества vDisk- ов

    #Description: Displays the number of vDisks
    vdisk_config_printer | grep vdisk_id | wc -l

    # Определение ID кластера

    #Description: Find the cluster ID for the current cluster
    zeus_config_printer | grep cluster_id

    # Открытие порта

    #Description: Enable port through IPtables
    sudo vi /etc/sysconfig/iptables
    -A INPUT -m state --state NEW -m tcp -p tcp --dport PORT -j ACCEPT
    sudo service iptables restart

    # Отображение теневых клонов

    #Description: Displays the shadow clones in the following format: name#id@svm_id
    vdisk_config_printer | grep '#'

    # Сброс статистики по задержкам, страница 2009

    # Description: Reset the Latency Page (CVM_IP:2009/latency) counters
    for i in `svmips`;do wget $i:2009/latency/reset;done

    # Отображение текущего количества vDisk на NDFS

    #Description: Find the current number of vDisks (files) on NDFS
    vdisk_config_printer | grep vdisk_id | wc -l

    # Запуск процесса сканирования Curator из консоли

    #Description: Starts a Curator full scan from the CLI
    for i in `svmips`;do wget -O - "http://$i:2010/master/api/client/StartCuratorTasks?task_type=2"; done

    # Сжатие данных в кольце метаданных

    #Description: Compact the metadata ring
    for i in `svmips`; do echo $i;ssh $i `nodetool -h localhost compact`;done

    # Определение версии NOS

    #Description: Find the NOS  version (NOTE: can also be done using NCLI)
    for i in `svmips`;do echo $i;ssh $i 'cat /etc/nutanix/release_version';done

    # Определение версии CVM

    #Description: Find the CVM image version
    for i in `svmips`; do echo $i;ssh $i `cat /etc/nutanix/svm-version`;done

    # Ручной режим создания хэша vDisk

    #Description: Create fingerprints for a particular vDisk (For dedupe)  NOTE: dedupe must be enabled on the container
    vdisk_manipulator –vdisk_id=vDisk_ID --operation=add_fingerprints

    # Вывод содержимого Factory_Config.json для всех узлов кластера

    #Description: Echos the factory_config.jscon for all nodes in the cluster
    for i in `svmips`; do echo $i; ssh $i "cat /etc/nutanix/factory_config.json";

    # Обновление версии NOS на одном узле кластера

    #Description: Upgrade a single node's NOS version to match that of the cluster
    ~/cluster/bin/cluster -u NEW_NODE_IP upgrade_node

    # Установка NCC (Nutanix Cluster Check)

    #Description: Installs the Nutanix Cluster Check (NCC) health script to test for potential issues and cluster health
    # Download NCC from the Nutanix Support Portal (portal.nutanix.com)
    # SCP .tar.gz to the /home/nutanix directory
    # Untar NCC .tar.gz
    tar xzmf ncc_.tar.gz_file name --recursive-unlink
    # Run install script
    ./ncc/bin/install.sh -f ncc_.tar.gz_file name
    # Create links
    source ~/ncc/ncc_completion.bash
    echo "source ~/ncc/ncc_completion.bash" >> ~/.bashrc

    # Запуск NCC

    #Description: Runs the Nutanix Cluster Check (NCC) health script to test for potential issues and cluster health.  This is a great first step when troubleshooting any cluster issues.
    # Make sure NCC is installed (steps above)
    # Run NCC health checks
    ncc health_checks run_all

    NCLI

    Внимание: Все данные команды могут быть выполнены через HTML5 GUI. Я просто использую эти команды при создании скриптов bash, для автоматизации рутинных рабочих процессов.

    # Добавить подсеть в белый список NFS

    #Description: Adds a particular subnet to the NFS whitelist
    ncli cluster add-to-nfs-whitelist ip-subnet-masks=10.2.0.0/255.255.0.0

    # Показать версию Nutanix

    #Description: Displays the current version of the Nutanix software
    ncli cluster version

    # Показать скрытые настройки NCLI

    #Description: Displays the hidden ncli commands/options
    ncli helpsys listall hidden=true [detailed=false|true]

    # Показать список дисковых пулов

    #Description: Displays the existing storage pools
    ncli sp ls

    # Показать список контейнеров

    #Description: Displays the existing containers
    ncli ctr ls

    # Создать контейнер

    #Description: Creates a new container
    ncli ctr create name=NAME sp-name=SP_NAME

    # Показать список ВМ

    #Description: Displays the existing VMs
    ncli vm ls

    # Показать список публичных ключей

    #Description: Displays the existing public keys ncli cluster list-public-keys

    # Добавить публичный ключ

    #Description: Adds a public key for cluster access
    # SCP private key to CVM
    # Add private key to cluster
    ncli cluster add-public-key name=myPK file-path=~/mykey.pub

    # Удалить публичный ключ

    #Description: Removes a public key for cluster access
    ncli cluster remove-public-keys name=myPK

    # Создать защищенный домен

    #Description: Creates a protection domain
    ncli pd create name=NAME

    # Создать удаленный сайт

    #Description: Create a remote site for replication
    ncli remote-site create name=NAME address-list=Remote_Cluster_IP

    # Создать PD для всех ВМ в контейнере

    #Description: Protect all VMs in the specified container
    ncli pd protect name=_PD_NAME ctr-id=Container_ID cg-name=NAME

    # Создать PD для конкретной ВМ

    #Description: Protect the VMs specified
    ncli pd protect name=PD_NAME vm-names=VM_Name(s) cg-name=NAME

    # Создание PD для файлов NDFS ( vDisk )

    #Description: Protect the NDFS Files specified
    ncli pd protect name=PD_NAME files=File_Name(s) cg-name=NAME

    # Создание снимка PD

    #Description: Create a one-time snapshot of the protection domain
    ncli pd add-one-time-snapshot name=PD_NAME retention-time=_seconds_

    # Создание расписания создания снимков и репликации на удаленный сайт

    #Description: Create a recurring snapshot schedule and replication to n remote sites 
    ncli pd set-schedule name=PD_NAME interval=_seconds- retention-policy=POLICY_NAME remote-sites=REMOTE_SITE_NAME

    # Показать статус репликации

    #Description: Monitor replication status
    ncli pd list-replication-status

    # Мигрировать PD на удаленный сайт

    #Description: Fail-over a protection domain to a remote site
    ncli pd migrate name=PD_NAME remote-site=REMOTE_SITE_NAME

    # Активация PD

    #Description: Activate a protection domain at a remote site
    ncli pd activate name=PD_NAME

    # Включение теневого клонирования NDFS

    #Description: Enables the NDFS Shadow Clone feature
    ncli cluster edit-params enable-shadow-clones=true

    # Включение дедупликации для vDisk

    #Description: Enables fingerprinting and/or on disk dedup for a specific vDisk
    ncli vdisk edit name=VDISK_NAME fingerprint-on-write=true/false on-disk-dedup=true/false

    PowerShell CMDlets

    Ниже будут рассмотрены Nutanix PowerShell CMDlets, как их использовать, а так же некоторые базовые вещи по Windows PowerShell.

    Основы.

    Windows PowerShell это мощная командная оболочка со встроенным скриптовым языком основанным на .NET framework. Это очень простой язык, созданный чтобы быть интуитивным и интерактивным. PowerShell оперирует следующими конструкциями:

    CMDlets

    CMDlets  представляют собой команды или классы .NET выполняющие определенные операции. Они используют методологию запрос/ответ. Например: Get-Process, Set-Partition и так далее.

    Piping или Pipelining (Конвеер)

    Piping это важная конструкция в PowerShell (как и в Linux) и может очень многое упростить при правильном использовании. По сути вы осуществляете передачу результата вывода одной команды в другую. Конвеер может быть сколь угодно длинным. Простейшим примером использования Конвеера будет получение списка процессов, поиск среди процессов тех которые находятся в состоянии Running и сортировка полученного результата в алфавитном порядке.

    Get-Service | where {$_.Status -eq "Running"} | Sort-Object Name

    Конвеер может использоваться вместо конструкций «for-each»


    # For each item in my array
    $myArray | %{
    # Do something
    }

    Более подробно можно почитать тут: http://technet.microsoft.com/en-us/library/ee176927.aspx

    Ключевые типы объектов

    PowerShell использует несколько ключевых типов объектов. Вы можете с легкостью получать тип объекта, используя метод .getType(), например: $someVariable.getType() вернет тип для объекта .Variable


    $myVariable = "foo"
    #NOTE: You can also set a variable to the output of a series or pipeline of commands:
    $myVar2 = (Get-Process | where {$_.Status -eq "Running})
    # In this example the commands inside the parentheses will be evaluated first

    Массив


    $myArray = @("Value","Value")
    # Note: You can also have an array of arrays, hash tables or custom objects

    Таблица хэшей


    $myHash = @{"Key" = "Value";"Key" = "Value"}

    Полезные команды


    # Get the help content for a particular CMDlet (similar to a man page in Linux)
    Get-Help CMDlet_Name
    # Example: Get-Help Get-Process
    # List properties and methods of a command or object
    _Some expression or object_ | Get-Member
    # Example: $someObject | Get-Member

    Ключевые CMDlests Nutanix и их использование.

    CMDlests Nutanix могут быть скачаны напрямую из пользовательского интерфейса Prism (начиная с версии 4.0.1), они нахоятся в ниспадающем меню, в правом верхнем углу.

    # Установка оснастки Nutanix (Необходимо запускать после запуска инсталлятора CMDlets , сейчас идут работы чтобы сделать это часть инсталлятора)


    # CD to .NET directory containing InstallUtil.exe
    cd [System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory()
    # Install NutanixCmdletsPSSnapin.dll
    .\InstallUtil.exe "C:\Program Files (x86)\Nutanix Inc\NutanixCmdlets\Modules\NutanixCmdletsPSSnapin.dll"

    # Загрузка оснастки Nutanix


    # Check if snappin is loaded and if not, load
    if ( (Get-PSSnapin -Name NutanixCmdletsPSSnapin -ErrorAction SilentlyContinue) -eq $null )
    {
        Add-PsSnapin NutanixCmdletsPSSnapin
    }

    # Просмотр списка Nutanix CMDlets


    Get-Command | Where-Object{$_.PSSnapin.Name -eq "NutanixCmdletsPSSnapin"}

    # Подключение к кластеру Nutanix


    Connect-NutanixCluster -Server $server -UserName "myuser" -Password "myuser" -AcceptInvalidSSLCerts
    # Or secure way prompting user for password
    Connect-NutanixCluster -Server $server -UserName "myuser" -Password (Read-Host "Password: ") -AcceptInvalidSSLCerts

    # Подключение к нескольким кластерам Nutanix


    # Create array of cluster to pass to function
    [array]$clusters = @(
    @("99.99.99.98","admin","blah"),
    @("99.99.99.99","admin","blah")
    )
    # NOTE: you can also do this without hardcoding passwords using the following
    [array]$clusters = @(
    @("99.99.99.98","admin",$(read-host "Please enter the prism user password:" -
    AsSecureString)),
    @("99.99.99.99","admin",$(read-host "Please enter the prism user password:" -
    AsSecureString))
    )
    # To connect interactively run the following which will connect to every cluster specified in $clusters
    $clusters | %{
    $server = $_[0]
    $user = $_[1]
    $password = $_[2]
    Connect-NutanixCluster -Server $server -UserName $user -Password $(if ($password.GetType().Name -eq "SecureString") `
    {([Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($password)))} `
    else {$password}) -AcceptInvalidSSLCerts
    }
    # You can also just set this to a function and just run the command when you want to connect
    function connNTNX {
    $clusters | %{
    $server = $_[0]
    $user = $_[1]
    $password = $_[2]
    Connect-NutanixCluster -Server $server -UserName $user -Password $(if
    ($password.GetType().Name -eq "SecureString") `
    {([Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($password)))} `
    else {$password}) -AcceptInvalidSSLCerts
    }
    }
    # When you want to connect then just run
    connNTNX

    # Получение списка виртуальных машин в соответствии со строкой поиска


    # Set to variable
    $searchString = "myVM"
    $vms = Get-NTNXVM | where {$_.vmName -match $searchString}  
    # Interactive
    Get-NTNXVM | where {$_.vmName -match "myString"}  
    # Interactive and formatted
    Get-NTNXVM | where {$_.vmName -match "myString"} | ft

    # Получение списка vDisk


    # Set to variable
    $vdisks = Get-NTNXVDisk
     
    # Interactive
    Get-NTNXVDisk
     
    # Interactive and formatted
    Get-NTNXVDisk | ft

    # Получение списка контейнеров


    # Set to variable
    $containers = Get-NTNXContainer
     
    # Interactive
    Get-NTNXContainer
     
    # Interactive and formatted
    Get-NTNXContainer | ft

    # Получение списка защищенных доменов


    # Set to variable
    $pds = Get-NTNXProtectionDomain
     
    # Interactive
    Get-NTNXProtectionDomain
     
    # Interactive and formatted
    Get-NTNXProtectionDomain | ft

    # Получение списка групп консистенции


    # Set to variable
    $cgs = Get-NTNXProtectionDomainConsistencyGroup
     
    # Interactive
    Get-NTNXProtectionDomainConsistencyGroup
     
    # Interactive and formatted
    Get-NTNXProtectionDomainConsistencyGroup | ft

    Примеры скриптов:

    ССЫЛКИ НА СКРИПТЫ

    Метрики и пороговые значения

    Ниже будут рассмотрены специфические метрики и пороговые значения бэкэнда Nutanix. Обновления в данном разделе будут опубликованы в ближайшее время.

    2009 Stargate - Обзор

    Метрика

    Пояснение

    Threshold/Target

    Start time

    Время запуска сервиса Stargate

     

    Build version

    Версия запущенного экземпляра

     

    Build last commit date

    Время последнего изменения версии

     

    Stargate handle

    Адрес обращения к Stargate

     

    iSCSI handle

    Адрес обращения к iSCSI

     

    SVM id

    ID SVM Stargate

     

    Incarnation id

     

    Highest allocated opid

     

    Highest contiguous completed opid

     

    Extent cache hits

    % запросов на чтение поступающих напрямую из extent cache в пямяти

     

    Extent cache usage

    размер extent cache в мегабайтах

     

    Content cache hits

    % запросов на чтение поступающих напрямую из content cache

     

    Content cache flash pagein pct

     

    Content cache memory usage

    Размер content cache в памяти, в МБ

     

    Content cache flash usage

    Размер content cache на SSD, в МБ

     

    QoS Queue (size/admitted)

    Размер очереди управления доступом и количество выполненных операций

     

    Oplog QoS queue (size/admitted)

    Размер очереди oplog и количество выполненных операций

     

    NFS Flush Queue (size/admitted)

     

    NFS cache usage

     

     

         

    2009 Stargate – состояние кластера

    Метрика

    Описание

    Threshold/Target

    SVM Id

    Id CVM

     

    IP:port

    IP-адрес:port обращения к Stargate

     

    Incarnation

     

    SSD-PCIe

     SSD-PCIe устройства  и их размер/загрузка

     

    SSD-SATA

    SSD-SATA устройства  и их размер/загрузка

     

    DAS-SATA

    HDD-SATA устройства  и их размер/загрузка

     

     

    Container Id

    Id контейнера

     

    Container Name

    Наименование контейнера

     

    Max capacity (GB) – Storage pool

    Максимальный объем дискового пула

     

    Max capacity (GB) – Container

    Максимальный объем контейнера(как правило совпадает с размером дискового пула)

     

    Reservation (GB) – Total across vdisks

    Всего ГБ зарезервировано для всех vDisk

     

    Reservation (GB) – Admin provisioned

     

    Container usage (GB) – Total

    Всего используется ГБ на контейнер

     

    Container usage (GB) – Reserved

    Всего зарезервировано контейнером, Гб

     

    Container usage (GB) – Garbage

     

    Unreserved available (GB) – Container

    Свободное пространство ГБ на контейнер

     

    Unreserved available (GB) – Storage pool

    Свободное пространство, ГБ для дискового пула

     

         

    2009 Stargate – NFS Slave

    Метрика

    Описание

    Threshold/Target

    Vdisk Name

    Наименование Vdisk на NDFS

     

    Unstable data – KB

     

    Unstable data – Ops/s

     

    Unstable data – KB/s

     

    Outstanding Ops – Read

    Количество ожидающих запросов на чтение в сек для vDisk

     

    Outstanding Ops – Write

    Количество ожидающих запросов на запись в сек для vDisk

     

    Ops/s – Read

    Текущее количество запросов на чтение в сек для vDisk

     

    Ops/s – Write

    Текущее количество запросов на запись в сек для vDisk

     

    Ops/s – Error

    Текущее количество ошибок в сек для vDisk

     

    KB/s – Read

    Поток запросов на чтение KB/s для Vdisk

     

    KB/s – Write

    Поток запросов на запись KB/s для Vdisk

     

    Avg latency (usec) – Read

    Средняя задержка при чтении c vDisk, мс

     

    Avg latency (usec) – Write

    Средняя задержка при записи на vDisk, мс

     

    Avg op size

    Средний размер операции в байтах

     

    Avg outstanding

    Среднее количество ожидающих операций

     

    % busy

    % занятости

     

         

    Метрика

    Описание

    Threshold/Target

    Container Name

    Наименование контейнера

     

     

     

     

    Outstanding Ops – Read

    Количество ожидающих операций чтения в сек. для контейнера

     

    Outstanding Ops – Write

    Количество ожидающих операций записи в сек. для контейнера

     

    Outstanding Ops – NS lookup

    Количество ожидающих запросов lookup  к NFS. для контейнера

     

    Outstanding Ops – NS update

    Количество ожидающих запросов update к NFS. для контейнера

     

    Ops/s – Read

    Текущее количество операций чтения в сек. для контейнера

     

    Ops/s – Write

    Текущее количество операций записи в сек. для контейнера

     

    Ops/s – NS lookup

    Текущее количество запросов lookup  к NFS. для контейнера

     

    Ops/s – NS update

    Текущее количество запросов update  к NFS. для контейнера

     

    Ops/s – Error

    Текущее количество ошибок запросов в сек для контейнера

     

    KB/s – Read

    Поток запросов на чтение KB/s для контейнера

     

    KB/s – Write

    Поток запросов на запись KB/s для контейнера

     

    Avg latency (usec) – Read

    Средняя задержка при чтении для контейнера, мс

     

    Avg latency (usec) – Write

    Средняя задержка при записи для контейнера, мс

     

    Avg latency (usec) – NS lookup

    Средняя задержка при выполнении запросов lookup к NFS для контейнера, мс

     

    Avg latency (usec) – NS update

    Средняя задержка при выполнении запросов update к NFS для контейнера, мс

     

    Avg op size

    Средний размер операции в байтах

     

    Avg outstanding

    Среднее количество ожидающих операций

     

    % busy

    % занятости

     

    2009 Stargate – Hosted vDisk

    Метрика

    Описание

    Threshold/Target

    Vdisk Id

    ID Vdisk на NDFS

     

    Vdisk Name

    Наименование Vdisk

     

    Usage (GB)

    Используемая емкость, Гб

     

    Dedup (GB)

     

    Oplog – KB

    Размер OpLog для vDisk

     

    Oplog – Fragments

    Количество фрагментов Oplog для Vdisk

     

    Oplog – Ops/s

    Количество текущих операций в сек для Vdisk

     

    Oplog – KB/s

    Поток в KB/s для Vdisk

     

    Outstanding Ops – Read

    Количество ожидающих операций чтения в сек. для Vdisk

     

    Outstanding Ops – Write

    Количество ожидающих операций записи в сек. для Vdisk

     

    Outstanding Ops – Estore

    Количество ожидающих операций в extent store в сек. для Vdisk

     

    Ops/s – Read

    Текущее количество операций чтения в сек. для Vdisk

     

    Ops/s – Write

    Текущее количество операций записи в сек. для Vdisk

     

    Ops/s – Error

    Текущее количество ошибок запросов в сек для Vdisk

     

    Ops/s – Random

     

    KB/s – Read

    Поток запросов на чтение KB/s для Vdisk

     

    KB/s – Write

    Поток запросов на запись KB/s для Vdisk

     

    Avg latency (usec)

    Средняя задержка для Vdisk, мс

     

    Avg op size

    Средний размер операции чтения/записи для Vdisk

     

    Avg qlen

    Средний размер очереди для Vdisk

     

    % busy

     

     

         

    2009 Stargate – Extent Store

    Метрика

    Описание

    Threshold/Target

    Disk Id

    ID физического устройства (диска)

     

    Mount point

    Точка монтирования физического устройства (диска)

     

    Outstanding Ops – QoS Queue

    Количество операций в секунду (primary/secondary) для устройства (диска)

     

    Outstanding Ops – Read

    Количество ожидающих операций чтения в сек. для устройства

     

    Outstanding Ops – Write

    Количество ожидающих операций записи в сек. для устройства

     

    Outstanding Ops – Replicate

     

    Outstanding Ops – Read Replica

     

    Ops/s – Read

    Текущее количество операций чтения в сек. для устройства

     

    Ops/s – Write

    Текущее количество операций записи в сек. для устройства

     

    Ops/s – Error

    Текущее количество ошибок запросов в сек для устройства

     

    Ops/s – Random

     

    KB/s – Read

    Поток запросов на чтение KB/s для устройства

     

    KB/s – Write

    Поток запросов на запись KB/s для устройства

     

    Avg latency (usec)

    Средняя задержка для устройства, мс

     

    Avg op size

    Средний размер операции чтения/записи для устройства

     

    Avg qlen

    Средний размер очереди для устройства

     

    Avg qdelay

    Средняя задержка очереди для устройства

     

    % busy

     

    Size (GB)

     

    Total usage (GB)

    Всего используется GB для устройства

     

    Unshared usage (GB)

     

    Dedup usage (GB)

     

    Garbage (GB)

     

    Egroups

    Количество extent groups для устройства

     

    Corrupt Egroups

    Количество испорченных extent groups для устройства

     

         

    Поиск неисправностей

    # Поиск журналов ошибок в кластере ( error log )

    				


    # Description: Find ERROR logs for the cluster
     
    for i in `svmips`;do ssh $i "cat ~/data/logs/COMPONENT_NAME_or_*.ERROR";done
     
    # Example for Stargate
    for i in `svmips`;do ssh $i "cat ~/data/logs/Stargate.ERROR";done

    # Поиск журналов отказов в кластере (fatal log)


    # Description: Find FATAL logs for the cluster
    for i in `svmips`;do ssh $i "cat ~/data/logs/_COMPONENT_NAME_or_*.FATAL";done
    # Example for Stargate
    for i in `svmips`;do ssh $i "cat ~/data/logs/Stargate.FATAL";done

    Книга vSphere


    Архитектура

    Будет добавлено

    Как это работает

    Array Offloads – VAAI

    Платформа Nutanix поддерживает API  VMWare для интеграции с хранилищами данных (VAAI) которое позволяет гипервизору перенести часть задач на массив. Это позволяет добиться большей эффективности, так как гипервизор перестает быть элементом в середине цепочки между ВМ и дисковым массивом. На данный момент Nutanux поддерживает примитивы VAAI для NAS, включающие ‘full file clone’, ‘fast file clone’ и ‘reserve space’. Вот тут хорошо описаны данные примитивы http://cormachogan.com/2012/11/08/vaai-comparison-block-versus-nas/. Быстрое и полное клонирование в рамках NDFS, выполняется созданием снимка с возможностью записи (используя "re-direct on write") для каждого создаваемого клона. Каждый из данных клонов имеет свою карту блоков, так что беспокоится о глубине клонирования не стоит. Ниже рассмотрим, в каких случаях будет использоваться VAAI, а в каких нет:

    • Клонирование ВМ с созданием снимка -> VAAI не используется
    • Клонирование ВМ без создания снимка в выключенном состоянии -> VAAI используется
    • Клонирование ВМ на другое хранилище -> VAAI не используется
    • Клонирование ВМ в включенном состоянии -> VAAI не используется

    Следующие сценарии применимы к VMWare View

    • Полное клонирование (Шаблон со снимком) -> VAAI не используется
    • Полное клонирование (Шаблон без снимка) -> VAAI используется
    • Линкованный клон (VCAI) -> VAAI не используется

    Вы можете проверить состояние операций VAAI на странице ’NFS Adapter’ Activity Traces.

    CVM Autopathing

    Надежность и отказоустойчивость является ключевой, если не самой важной частью NDFS. Являясь распределённой системой, NDFS построен так, чтобы иметь возможность справится с отказом компонентов, сервисов или CVM. В этой секции я расскажу как обрабатывается "отказ" CVM. "Отказ" CVM может включать в себя ситуацию когда пользователь выключил CVM, CVM обновляется или наступает любое другое событие приведшее к недоступности CVM. NDFS имеет функцию называемую "autopathing", которая в случае недоступности локальной CVM осуществит прозрачную передачу операций ввода/вывода другой CVM в кластере. Гипервизор и CVM взаимодействуют посредством приватной сети 192.168.5.0 на выделенном vSwitch. Все операции I/O направляются на внутренний IP-адрес CVM (192.168.5.2). Внешний IP-адрес CVM используется для удаленной репликации и взаимодействия между CVM. Вот как это выглядит:

    В случае если произошел отказ локальной CVM, адрес 192.168.5.2 становится недоступным. NDFS автоматически определит эту ситуацию и перенаправит поток операций ввода/вывода на другую CVM в кластере, по сети 10GbE. Перестроение маршрутов происходит прозрачно для гипервизора и размещенных на нем ВМ. Это значит, что если CVM выключена то ВМ продолжают работать и отправлять свои запросы чтения/записи в NDFS. NDFS выполняет "самолечение", т.е. она определяет что CVM выключена и начинает попытки автоматически перезагрузить или включить данную CVM. Как только CVM становится снова доступной, весь трафик операций чтения/записи будет перенесен обратно и снова будет обслуживаться локальной CVM. Давайте посмотрим, как это происходит:

    Администрирование

    Будет добавлено

    Важные страницы

    Будет добавлено

    Команды администрирования

    # ESXi. обновление кластера


    # Description: Perform an automated upgrade of ESXi hosts using the CLI
    # Upload upgrade offline bundle to a Nutanix NFS container
    # Log in to Nutanix CVM
    # Perform upgrade
    for i in `hostips`;do echo $i ssh root@$i “esxcli software vib install -d /vmfs/volumes/Datastore_Name/Offline_bundle_name”;done
    # Example
    for i in `hostips`;do echo $i ssh root@$i “esxcli software vib install -d /vmfs/volumes/NTNX-upgrade/update-from-esxi5.1-5.1_update01.zip”;done

    # ESXi. Перезапуск сервисов


    # Description: Restart each ESXi hosts services in a incremental manner
    for i in `hostips`;do ssh root@$i "services.sh restart";done

    # ESXi. Статус интерфейсов 10G


    # Description: Display the ESXi host's nics which are in a 'Up' state
    for i in `hostips`;do echo $i ssh root@$i esxcfg-nics -l | grep Up;done

    # ESXi. Статус активных интерфейсов


    # Description: Display the ESXi host's 10GbE nics and status
    for i in `hostips`;do echo $i ssh root@$i esxcfg-nics -l | grep ixgbe;done

    # ESXi. Просмотр таблицы маршрутов


    # Description: Display the ESXi host's active, standby and unused adapters
    for i in `hostips`;do echo $i   ssh root@$i "esxcli network vswitch standard policy failover get --vswitch-name vSwitch0";done

    # ESXi . Проверка статуса VAAI для хранилища


    # Description: Display the ESXi host's routing tables
    for i in `hostips`;do ssh root@$i 'esxcfg-route -l';done

    # ESXi. Включение поддержки CommunitySupported VIB


    # Description: Check whether or not VAAI is enabled/supported for a datastore
    vmkfstools -Ph /vmfs/volumes/Datastore_Name

    # ESXi. Установка VIB


    # Description: Set the vib acceptance level to CommunitySupported allowing for 3rd party vibs to be installed
    esxcli software acceptance set --level CommunitySupported

    # ESXi. Проверка емкости ramdisk


    # Description: Check free space of ESXi ramdisk
    for i in `hostips`;do echo $i; ssh root@$i 'vdf -h';done

    # ESXi. Очистка логов pynfs


    # Description: Clears the pynfs logs on each ESXi host
    for i in `hostips`;do echo $i; ssh root@$i '> /pynfs/pynfs.log';done

    Метрики и пороговые значения

    Будет добавлено

    Поиск неисправностей

    Будет добавлено

    Книга Hyper-V


    Архитектура

    Будет добавлено

    Как это работает

    Array Offloads – ODX

    Платформа Nutanix поддерживает функцию Microsoft Offloaded Data Transfers (ODX) для интеграции с хранилищами данных, которая позволяет гипервизору перенести часть задач на массив. Это позволяет долбиться большей эффективности, так как гипервизор перестает быть между ВМ и системой хранения данных. В настоящий момент Nutanix поддерживает ODX примитивы для SMB включая "full copy" и операции "zeroing".  В отличие от VAAI, который может выполнять операции клонирования используя снимки для записи, примитивы ODX не имеют схожих функций для выполнения "full copy". Учитывая эту особенность, стоит полагаться на встроенную в NDFS возможность создания клонов используя вызовы nCLI, REST, or Powershell CMDlets. На данный момент это используется для следующих операций:

    • Копирование или клонирование ВМ на NDFS через SMB
    • Копирование файла на общем ресурсе SMB
    • Разворачивание шаблона через библиотеку SCVMM (общий ресурс NDFS SMB). Внимание: общий ресурс должен быть добавлен в кластер SCVMM с использованием коротких имен (НЕ FQDN). Проще всего добавить имена в файл hosts (например 10.10.10.10     nutanix-130).

    ODX НЕ используется для следующих операций:

    • Клонирование ВМ через SCVMM
    • Развертывание шаблона через библиотеку SCVMM (НЕ-NDFS SMB)
    • развертывание клона XenDesktop

    Вы можете проверить состояние операции ODX используя страницу ‘NFS Adapter’ Activity Traces (да, я говорю NFS, даже если это выполняется через SMB). Активность операций будет показана через ‘NfsSlaveVaaiCopyDataOp‘ при копировании диска, и ‘NfsSlaveVaaiWriteZerosOp‘ при выполнении операции "zeroing".

    Администрирование

    Будет добавлено

    Важные страницы

    Будет добавлено

    Команды администрирования

    # Выполнение команды на удаленном узле


    # Description: Execute a powershell on one or many remote hosts
    $targetServers = "Host1","Host2","Etc"
    Invoke-Command -ComputerName  $targetServers {
             _COMMAND_or_SCRIPT_BLOCK_
    }

    # Проверка доступности VMQ Offloads


    # Description: Display the available number of VMQ offloads for a particular host
    gwmi –Namespace “root\virtualization\v2” –Class Msvm_VirtualEthernetSwitch | select elementname, MaxVMQOffloads

    # Отключение VMQ для ВМ по маске


    # Description: Disable VMQ for specific VMs
    $vmPrefix = "myVMs"
    Get-VM | Where {$_.Name -match $vmPrefix} | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight 0

    # Включение VMQ для ВМ по маске


    # Description: Enable VMQ for specific VMs
    $vmPrefix = "myVMs"
    Get-VM | Where {$_.Name -match $vmPrefix} | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight 1

    # Включение ВМ по маске


    # Description: Power-On VMs matchin a certain prefix
    $vmPrefix = "myVMs"
    Get-VM | Where {$_.Name -match $vmPrefix -and $_.StatusString -eq "Stopped"} | Start-VM

    # Выключение ВМ по маске


    # Description: Shutdown VMs matchin a certain prefix
    $vmPrefix = "myVMs"
    Get-VM | Where {$_.Name -match $vmPrefix -and $_.StatusString -eq "Running"}} | Shutdown-VM -RunAsynchronously

    # Остановка ВМ по маске


    # Description: Stop VMs matchin a certain prefix
    $vmPrefix = "myVMs"
    Get-VM | Where {$_.Name -match $vmPrefix} | Stop-VM

    # Получение настроек  RSS хоста Hyper - V


    # Description: Get Hyper-V host RSS (recieve side scaling) settings
    Get-NetAdapterRss

    # Проверка соединения между Winsh and WinRM


    # Description: Check Winsh and WinRM connectivity / status by performing a sample query which should return the computer system object not an error
    for i in `svmips`; do echo $i; ssh $i 'source /etc/profile > /dev/null 2>&1; winsh "get-wmiobject win32_computersystem"'; done

    Метрики и пороговые значения

    Будет добавлено

    Поиск неисправностей

    Будет добавлено