Архив автора: romx

Являются ли снэпшоты бэкапами?

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

С тех пор прошло много времени, Димитрис перешел из NetApp в Nimble, а теперь с ним, кажется, и в HPE, и, как и я, подзабросил блог. Но всякий раз, когда у него в нем появляются посты, они интересные и заставляют задуматься.

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

July 24, 2018 by Dimitris

Снэпшоты — это бэкапы? И что вам нужно предпринять для защиты ваших данных?

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

Итак, моя позиция: Неважно, как фича называется — вы можете, используя ее, восстановить ваши данные? И, если ответ «да», то как быстро и по какому сценарию? И какие возможные минусы решения?

Начните с составления списка возможных ситуаций!

Перед тем, как засесть за разработку вашего решения для бэкапа/DR/BR, начните с того, что обдумайте ВСЕ от чего вы хотите предусмотреть защиту ваших данных. Например вот две очевидных ситуации:

      • Случайное удаление данных
      • Потеря сайта целиком

Но подумайте также и о ситуациях не совсем обычных, но которые тоже приведут к потерям данных.

      • Акт корпоративного саботажа, или злонамеренный админ, который удаляет ВСЕ ваши данные на сторадже, и ВСЕ ваши бэкапы, на ВСЕХ сайтах (это займет время, но это потенциально возможно, поэтому может случиться).
      • Хакер завладевает админской учеткой и удаляет ВСЕ ваше облако, когда вы только закончили миграцию в облако. (Такое уже тоже было).
      • Вирус-шифровальщик закончил шифрование всех ваших данных, и теперь просит денег.

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

Почему «стратегия 3-2-1» — недостаточна.

Главное правило, которое рекомендуют при разработке стратегии бэкапа принято называть «стратегией», или «правилом 3-2-1». Это означает:

      • 3 полных копии данных
      • На 2 разных носителях
      • И одна из этих копий — на удаленном сайте

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

Снэпшоты — это бэкапы. Но просто этот вариант не покрывает ВСЕ возможные случаи защиты данных.

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

Например, довольно просто сделать систему, соответствующую «правилу 3-2-1» просто с помощью снэпшотов:

      • Множественные (виртуальные) копии, хранящиеся локально и удаленно, не просто «три копии»… (обычный профиль использования снэпшотов)
      • Репликация некоторых снэпшотов на другую систему (и убедитесь, что используемая вами технология создания снапшотов позволяет вам иметь полностью раздельные политики retention для источника и получателя репликации)
      • И одна из используемых систем расположена на удаленном сайте (идеально — в сотне километров от основного).

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

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

Поэтому основная тема спора состоит не в том, что «бэкапом является», а что — «нет». Основная тема обсуждения тут — кто и как контролирует процесс создания резервных копий, неважно, как именно эти копии созданы и где хранятся.

Что вы можете сделать против злонамеренного вмешательства

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

Большинство людей вообще не задумываются о данной проблеме.

Осознайте факт того, что роль backup admin — это САМАЯ опасная роль в IT!

Задумайтесь над этим фактом. ПО бэкапа, по своему определению:

      1. Управляет созданием резервных копий (включая создание снэпшотов и репликации, в некоторых решениях)
      2. Имеет агентов на хостах, которые, обычно, имеют полный неограниченный доступ ко всем пользовательским данным, включая права на перезапись всех данных. Или, как вы думаете, работает процесс восстановления?

То есть backup admin может легко сделать следующее:

      1. Удалить все снэпшоты на массиве хранения (если бэкапный софт управляет процессом создания этих снэпшотов) – даже если он не является админом хранилища!
      2. Сделать так, чтобы все ленты (если вы используете ленты) за прошедшие месяцы были отозваны из хранилища и стерты (а вы думали, что достаточно записать бэкапы на другой носитель, чтобы их обезопасить).
      3. Воспользоваться агентами бэкапа, чтобы полностью стереть все серверы.
      4. Стереть базу бэкап-сервера и все копии данных.
      5. [Бонус] Сделать копию данных для себя, чтобы оставить возможность шантажа – вы же не забыли, эта роль имеет доступ ко ВСЕМ серверам. Ему не нужны пароли глобального админа (доменные админы, вы правда считаете, что права вашей учетки абсолютно необходимы для запуска агента резервного копирования?)

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

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

Определенные ключевые сотрудники должны проходить особую углубленную проверку

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

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

Мы живем во времена программ-вымогателей, а то и еще чего похуже. Обдумайте некоторые из перечисленных идей:

      • Если вы используете ленты для оффсайт-хранения, используйте ДВЕ разных компании, предоставляющие вам услуги хранения лент, причем админы должны иметь доступ к хранилищу только ОДНОЙ. Только глава компании (например CEO, или исполнительный директор), должен иметь права доступа к хранилищу другой.
      • Используйте 3 локации хранения, а не обычных 2. Одна из трех должна располагаться очень далеко от других, идеально — другой континент (а в будущем может быть и геостационарная орбита?).
      • Если вы не используете ленты, у вас должна быть одна полностью независимая команда админов, отвечающая за третью копию ваших данных в отдельном датацентре. Массив хрнения в этом датацентре должен быть полностью недоступен для любого из админов остальных двух сайтов хранения. Сама копия должна создаваться полностью иным методом, то есть НЕ вашим обычным бэкапным софтом, ни штатным механизмом репликации дискового массива. Обычные админы НЕ должны иметь доступа к этому дополнительному механизму репликации и создания резервной копии, идеально — он должен быть от них полностью скрыт. Кстати, это не так просто сделать.
      • Подумайте о использовании лент как дополнение к всем прочим вариантам хранения, если вы их еще не используете. Да, все сегодня ненавидят ленты, но в данном случае это как раз задача для них.
      • Подумайте о возможности использовать настоящее WORM решение (такое, запись на которое никак нельзя изменить).

Я могу продолжать, но в целом вы уже поняли ход рассуждения.

Может быть пришла пора нового стандарта, «правила 4-3-3-3-1»?

      • 4 копии данных
      • В 3 локациях
      • Управляемых 3 разными системами создания копий
      • Администрируемых 3 разными командами, без пересечений в правах между ними.
      • И 1 копия, остающаяся полностью недоступной для почти любого в компании.

 

А для фанатов «облаков», это означает использование AWS, Azure и Google cloud вместе, одновременно (вот вам, например, ваши необходимые «три локации»).

И в заключение: остерегайтесь стать «слишком параноиком»

Чтобы уберечься от этого, задайте себе несколько вопросов:

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

Источник <http://recoverymonkey.org/2018/07/24/are-snapshots-backups-and-what-do-you-need-to-protect-against/>

Nutanix Acropolis OS — 5.9

Как вы помните, по новой модели time-based releases, мы выпускаем short-time support releases каждый квартал. В этом квартале вышел релиз 5.9

Сегодня релиз выложен для скачивания, и вот что в нем нового:

• Улучшена работа NearSync DR, это наша асинхронная репликация с циклом 1 минута, я писал о ней ранее в блоге.
Теперь в одном Protection Domain (PD) можно иметь и NearSync, и обычный Async. В PD с NearSync можно делать App-consistent Snapshots, а также one-time snapshots, выполняемые вручную, например для фиксации состояния VM перед изменениями в ней. Так как NearSync использует спциальные, Lightweight Snapshots, отличающиеся от обычных Snapshots, было ограничение на использование последних в PD с Nearsync. Теперь можно. Это, кстати, также означает, что backup решения которые используют наш механизм timestream snapshots, будут работать и на томах, реплицируемых NearSync.

• С этого релиза поддерживается ESXi 6.7

• Rack Fault Tolerance — это расширенный block awareness. Последний, если помните, возможнось раскладывать избыточные блоки не просто на разные ноды, но на ноды в разных блоках. С RFT это будет делаться еще и между рэками, если, например, кластер состоит из более чем одного рэка блоков. Это позволяет, потенциально, повысить отказоустойчивость, если авария затронет целиком рэк нодов.

• Metro Availability Support for Hyper-V 2016. Наконец-то к vSphere добавился Hyper-V. По-прежнему ждем Metro Availability для AHV

• Karbon (бывший Acropolis Container Services 2.0) выходит в статусе Tech Preview, в следующем релизе, 5.10 уже будет prodiuction ready. Karbon — это система, позволяющая развертывать кластер Kubernetes, со своей web-консолью, и Kibana для логгинга и мониторинга.

• Поддерживается NVIDIA Tesla V100 16 GB GPU в AHV

• Поддерживается RDMA для двух NIC на платформах G6: NX-3060-G6, NX-3155G-G6, NX-3170-G6, NX-8035-G6, NX-8155-G6 (не поддерживается на NX-1065-G6).

• Реорганизовано меню Settings в Web Console Prism (то, что раньше открывалось по щелчку по шестеренке справа). Так как настроек становится все больше, стало необходимым его переделать радикально.

В новый год — с новыми именами продуктов Nutanix!

Популярное развлечение маркетингового отдела, взять и попереименовывать все продукты компании (а порой и не один раз), докатилось и до Nutanix.
Нет, я не хочу сказать, что имеющиеся названия продуктов были идеальными. Как раз скорее всего и обычно — нет.
Но вот теперь эпидемия переименований докатилась и до нас. В новый финансовый год (FY2019) — с новыми названиями.

  • Acropolis File Services (AFS) теперь будет Nutanix Files
  • Acropolis Block Services (ABS) теперь будет Nutanix Volumes
  • Object Storage Services теперь будет Nutanix Buckets
  • Xi Cloud DR services, не успев появиться и получить имя, теперь будет Leap
  • Netsil (это недавно купленная компания со своим продуктом, который мы будем предлагать как SaaS service) теперь будет Epoch

Отчасти, конечно, причины переименований понятны. Nutanix все больше занимается и все больше уходит в софтовую сторону, в Enterprise Cloud. Для нас HCI сегодня, пусть все еще самый большой и важный, но уже даже не самый главный продукт. Поэтому когда HCI и Acropolis, как ядро нашего HCI, был во главе угла всей продуктовой линейки, привязывать и называть от него продукт было разумно. Сегодня, когда, например AFS является все чаще для наших клиентов уже самостоятельным и отдельным продуктом, часто продающимся и самим по себе, было бы разумно представить и называть его, в свою очередь, как самостоятельный продукт, а не, допустим, как какую-то «фичу» нашей HCI-платформы.

Позже будут объявлены новые имена для:

  • Acropolis Container Services (ACS)
  • семейства продуктов Xtract
  • Project Sherlock

SAP HANA — официально работает на Nutanix AHV!

Это произошло даже быстрее, чем я ожидал. Еще 15 июня я опубликовал заметку, о том, что мы в Nutanix поддерживаем SAP HANA на AHV, и ждем теперь официального SAP note, и вот он вышел еще до конца лета: SAP note 2686722 – SAP HANA virtualized on Nutanix Acropolis Hypervisor.
Теперь это официально в том числе и со стороны SAP — HANA работает и поддерживается на Nutanix HCI под AHV, причем, отметьте, пока только под AHV. И не просто работает, а поддерживается в Production! Это первый гипервизор, поддерживающий HANA в Production environment (не Test/Dev, такое было). [поправка: не первый, 2393917 — SAP HANA on VMware vSphere 6.5 in production]

Nutanix и SAP технологические партнеры много лет, и пару лет назад мы уже объявляли о поддержке SAP Netweaver, то есть classic решения, а вот теперь пришел черед и для HANA.
Несмотря на то, что в данный момент в нашей собственной линейке платформ нет более чем двухпроцессорных систем с объемом памяти более 1.5TB, они есть у наших OEM-партнеров DellEMC и Lenovo, там есть 4-процессорные системы с 3TB RAM, идеальные для крупных SAP HANA серверов.
В настоящий момент поддерживаются процессоры семейства Skylake, HANA VM может занимать до 2.3 TB RAM и использовать до 168 virtual CPU, пользовательские приложения на HCI могут использовать vCPU не занятые использованием production HANA базами.

Официальная страница по решениям для SAP на сайте Nutanix: https://www.nutanix.com/sap

Beware: outdated!

Когда я смотрел статистику посещений блогов, я обратил внимание, что в блог довольно много пользователей приходят на ОЧЕНЬ старые посты, чуть ли не 2014-2015 годов.
Проблема тут в том, что продукт компании Nutanix довольно быстро развивается, и, часто, информация в даже годичной давности постах не имеет больше актуальности.
Поэтому люди, которые ходят, например, в посты трехлетней давности «как перенести VM из VMware в AHV» и читающие там длинную инструкцию как это нужно было делать в 2015 году, и так далее, «ищут проблем». Это давно уже на актуальных системах делается не так, проще и совсем другими средствами. Но я не могу пройти по нескольким сотням написанных за почти пять лет в этом блоге постов, и поправить все, что когда-то там писалось. Не хочу я и удалять старые посты, по разным причинам. Исправлять же все, что было написано за несколько лет ни рук ни времени у меня нет. Просто помните, что уже очень многое, что старше года-двух, в этом блоге уже будет outdated.

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

В остальном же — всегда обращайте внимание на дату поста.

Veeam Availability for Nutanix AHV

Ну, улита ехала, наконец доехала. :)

Наши коллеги из Veeam наконец выкладывают в public свой продукт Veeam Availability с поддержкой Nutanix AHV.

veeam site screenshot for nutanix ahv

https://www.veeam.com/availability-nutanix-ahv.html

Есть триал на 30 дней без ограничений.

NearSync replication — ограничения

В версии 5.5 у нас, в дополнение к нашей обычной асинхронной реликации с минимальным циклом «раз в час», добавилась еще и новая, которую мы назвали NearSync. Ее минимальный цикл — раз в минуту, и это может быть хорошим вариантом для тех, кому раз в час — редко, а синхронная репликация или не подходит, или слишком тормозит (например из-за расстояний между датацентрами).
Однако, как у любых фич, у NearSync есть ряд ограничений, которые хорошо знать, прежде чем вы начнете ей заниматься, планировать использование и использовать в работе.
Вот какие действующие ограничения есть в последней, на момент написания этого текста, версии AOS 5.8:

  • Поддерживается только репликация один-к-одному. С асинхронной можно разные конфигурации, например один-ко-многим.

  • Минимальное число нодов в кластере — 3, как для источника, так и для получателя. Соответственно, не работает на single-node и dual-node ROBO clusters.

  • В расписании для NearSync возможно указать только диапазон от 1 до 15 минут. Нельзя указать интервал от 16 до 59 минут. Начиная с 60 минут будет использоваться обычная Async.

  • Каждый SSD в кластере, участвующем в репликации, должен быть размером не менее 1.2TB. Оптимальный размер SSD для hybrid system — 2 x 1.9TB, для AllFlash ограничений нет. Не рекомендуется добавлять SSD размером меньше 1.2TB в кластер, который использует NearSync при его расширении.

  • Убедитесь, что в каждом Protection Domain, участвующем в NearSync репликации не более 10 объектов (VM или Volume Groups).

  • Система-получатель репликации должна иметь перед включением репликации свободного места столько же, сколько занимает защищаемый workset на системе-источнике.

  • Не включайте NearSync Replication в кластере, где есть узлы с более чем 40TB емкости хранения (SSD+HDD).

  • Поддерживаются гипервизоры ESXi и AHV на x86, не поддерживается AHV на IBM Power.

  • Поддерживается только гомогенный кластер. Не поддерживаются кластеры с разными гипервизорами (пример: ESXi и AHV на capacity nodes).

  • Linked Clones для VM, участвующих в NearSync replication не поддерживаются.

  • Не поддерживается CBT (Change Block Tracking), его пока нет в Lightweight Snapshots, используемых в NearSync.

  • Контейнеры, участвующие в Metro-репликации и в SRM — не поддерживаются.

  • Self-service Restore для реплицируемых с NearSync виртуальных машин не поддерживается (он есть только для full, а не для LWS снэпшотов). По той же причине не поддерживается интеграция для данных защищаемых NearSync VMs с Commvault, HYCU, Rubrick. Им всем нужны full snapshots, а не LWS.

  • Также для NearSync-protected VMs не поддерживаются AppConsistent Snapshots, они также используют full snapshots, а не LWS.

  • Не поддерживается NearSync репликация для AFS (Acropolis File Services).

  • Не поддерживается кросс-гипервизорная репликация.

Так что, как видите, NearSync подойдет не всем, и не является чем-то, заменяющим обычный Async, «тока быстрее». Для задач, которые требуют минимального RPO/RTO, например какая-то ответственная база данных, или аналогичная система, которой в самом деле надо иметь цикл репликации раз в минуту/в пять минут это должно неплохо подойти и ограничения легко обходятся. Для остального — по прежнем лучше использовать обычный Async.

Nutanix AOS 5.8 — новый релиз

Вообще, прошедшая неделя была богата анонсами (к сожалению, из-за рабочей занятости пишу о них спустя почти неделю).
Главная новость, конечно, это выход очередного нашего релиза, носящего номер 5.8.
Как я уже писал, мы в Nutanix перешли на новую модель выпуска релизов, становящуюся все более массовой, так называемые Time-based releases, при которых очередной софтверный релиз выпускается не когда будут закончены все запланированные в него новинки, а когда наступает календарный срок, как в Ubuntu, или как в нынешнем Windows 10.
Поэтому у нас раз в год будет выходить LTS, Long-time supported release, в котором будут все отработанные фичи, и который будет рекомендоваться для компаний, которым нужен stable продукт, подерживающийся максимально долго. Сейчас это версия 5.5. И потом будут три релиза, которые собирают в себе все самое новое, что мы выпустили за год, наш nightly build, для тех, кто хочет «все самое новое» и «передний край» разработки. Это не значит, что STS releases будут менее надежны или полны багов, совсем нет. Но если у вас нет необходимости в постоянных обновлениях, или есть строгие требования по сертифицированности ваших решений (требующих стабильной версии платформы) — выбирайте LTS, она будет поддерживаться максимально долго.
AOS — Acropolis OS, это, напомню, содержимое нашей CVM, Controller VM. Ключевая подсистема решения, то, где собственно и живет Nutanix как таковой. Виртуальная машина, в которой внутри, на базе CentOS Linux 7.x, работаю наши сервисы, обеспечивающие все, что делает Nutanix.

Итак, в версии AOS 5.8:

1. Добавляется GPG подпись для tarball, которые мы используем при обновлении системы. Если раньше для контроля целостности получаемого tar.gz использовался обычный MD5 hash, то теперь, дополнительно, скачиваемое обновление будет снабжаться GPG signature, чтобы быть уверенным, что никакой злонамеренный man-in-the-middle не подменил код, и не внедряет в кластер, под видом обновления, что-то постороннее.

2. В Prism Central, наш расширенный (и бесплатный, кстати) интерфейс управления добавляется механизм SAML аутентификаци, позволяющий использовать такие средства Single Sign-On аутентификации пользователя и Identity Provider, как, например, OKTA

3. SMB Sharing mode checks. Было несколько кейсов у пользователей Hyper-V, когда отдаваемый по SMB контейнер, бывал неправильно обрабатываем, и разные хосты одновреименно вносили в него изменения, что привлодило к его повреждениям. Теперь перед открытием доступа к контейнеру будет дополнительно проводиться проверка режима работы с ним. Эта модификация касается немногих пользователей, испльзующих Nutanix с MS Hyper-V.

4. Мы придумали, как будем лицензировать CALM. CALM — это наш встроенный оркестратор приложений в облаке, частном, на Nutanix, публичном, например AWS или GCP, и, наконец, гибридном, на котором часть приложений размещены на локальном «облаке» на платформе Nutanix, а часть ресурсов арендуется у публичного «облака». CALM встроен в Prism Central, и мы пидумали, как его лицензировать для пользователя. Сразу — хорошая новость, есть Free Tier, на 25 VM, то есть для задач на менее 25 VM вы можете пользоваться им бесплатно. Это немного, сразу скажу, но если вы выросли из 25 VM, значит ваша задача уже серьезная. Тут уже можно и деньги поискать.
Схема будет такая: первые 25 разворачиваемых VM — бесплатные всегда, и покупать на них лицензию CALM не надо. Считаются только активные, concurrent VM. Например, если вы запустили X машин, а потом пяь штук погасили и удалили, то 5 лицензий у вас освободилось, и может быть использованы на 5 других VM. VM считаются по их IP + VM ID, то есть просто выключить недостаточно.
Или еще пример. Пользователь развернул через CALM пять сервисов, по 2 VM каждая. Суммарное число лицензий — 10 (per VM). Потом он остановил и удалил два сервиса (то есть четыре VM). Значит, у него высвободилось на системе 4 лицензии, которые будут назначены следующим сервисам.
Лицензии будут продаваться паками по 25 штук (то есть на 25 VM). Первые 25 — бесплатны, дальше по количеству разворачиваемых VM в сервисах.
Что будет пр превышении — та же схема, что и с нашими обычными лицензиями, будет неблокирующий алерт и баннер в интерфейсе. Это сверхлиберальная политика в отношении лицензирования, и мы рассчитываем, что вы не будете злоупотреблять этим.

5. Фича, которой, напоминаю, нет в российских сборках Nutanix по причине непроходимой для нас процедуры ограничения импорта криптографии. Но так как меня читают не только в России, я пишу о ней все равно. Начиная с версии 5.5 в декабре у нас появилась возможность, кроме использования SED, Self-encrypted disks, использовать software-based encryption данных, записываемых на диски. На современных процессорах с hardware-assisted AES-NI это работает быстро и не создает заметных проблем с производитиельностью. Но если до версии 5.8 для хранения ключей шифрования были нужны внешние, сторонние KMS, Key Management Services, то теперь он у нас появился встроенный.
Само шифрование — AES-256, шифруются все кладущиеся на диски данные, не используются SED, то есть на обычных дисках обычных систем. Не зависит от типа гипервизора, то есть работает уровнем ниже и на любом из поддерживаемых гипервизоров. Идет сертификация FIPS 140-2 Level 1. SED сертифицированы на FIPS 140-2 Level 2. SED и software-based encryption можно использовать вместе, на одной системе, получая двухслойное шифрование (при этом, например, уровень SED будет незвависим от уровня контейнеров, лежащих на нем, и владелец ключа от контейнера А не будет возможности доступа ни к содержимому контейнера B, зашифрованному другим ключом, ни к уровню самих дисков, шифрующихся SED, и это можно использовать для формы multi-tenancy.
External KMS — это Gemalto SafeNet, Vormetric, IBM SKLM, Winmagic, Fornetix. Теперь к ним добавился наш собственный Native KMS, встроенный в Nutanix. Требуется минимум 3 ноды (он распределенный). Будучи включенным один раз, шифрование на кластере уже нельзя выключить без полного уничтожения и пересборки кластера.
Лицензия на Data-at-rest Encryption включена в Ultimate, а для прочих уровней есть Standalone license (но только для G6, Skylake CPU), и ее можно добавить, например, в Pro.

Насчет «недоступна в России» — да, для России собирается отдельная версия, с физически выпиленной фичей, к сожалению, у нас нет достаточно ресурсов и денег, чтобы пройти необходимые для импорта криптографии бюрократические препоны, мы не Cisco.
Предназначена эта фича, прежде всего, не для того, о чем вы сразу подумали, потому что тем, о ком вы сразу подумали, нет проблем изъять всю инфраструктуру, вместе с KMS. Обычно это нужно корпорациям, у которых предусмотрены мозговыносящие процедуры по списанию вышедших из строя или списываемых по старости носителей, хранящих корпоративную информацию. В случае применения шифрования у вас есть гарантия, что пока не взломан (в принципе, как алгоритм) AES-256, ваш данные с этих дисков считать в прочитываемом виде невозможно, и их можно просто выкидывать на помойку, вместо, например, физического уничтожения в шреддере для HDD (есть такие, слабонервным не смотреть).

6. Мы постепенно переводим на multiqueue всю внутреннюю кухню (не нужно думать, что для этого достаточно просто собрать бинарники с включенным ключом компиляции, там много внутренних сложных зависимостей в оригинальном коде Linux KVM). В 5.5 мы добавили AHV Turbo, это многопоточность и multiqueue для канала доступа к дискам, и тогда это дало на быстрых дисках, таких как NVMe и AllFlash почти двукратный прирост по производительности на мелких блоках, за счет распараллеливания ввода-вывода на множество доступных ядер, вместо стандартного — на одном CPU core. Появление у нас новых карт 25G и 40G Ethernet сделало необходимым то же самое проделать и с ними, так что теперь у нас есть две очереди, на два разных CPU core, вместо одной до сих пор. Преимущества от NIC multiqueue увидят главным образом владельцы систем с NVMe, RDMA и большим числом SSD (4+) в AllFlash.

7. Теперь включение Erasure Coding (EC-X) не ломает Block Awareness. Последнее — это поведение системы, когда у вас есть значительное число блоков, то есть групп нодов, собранных в одном физическом корпусе, совместно использующих корпус, бэкплейн и пару блоков питания, то в этом случае, при включении Block Awareness, система будет раскладывать блоки данных по нодам таким образом, чтобы они не собирались вместе на одном таком block, объединяющем несколько нодов. Потенциально, например, чтобы при потере сразу пары PSU, Power supply units, вы не потеряли при этом сразу несколько блоков данных, собравшихся хоть и на разных нодах, но в составе одного block, и отключившихся разом.

8. Наконец, мы планируем ввести Capacity License, особый вид лицензирования, который поможет нам решить одну, очень огорчительную для пользователй проблему, обуславливающую такую высокую стоимость лицензии Software-only Nutanix, приобретаемую на стороннюю платформу, например на HPE ProLiant, а не, например, покупаемую в составе appliance Nutanix NX.
Дело в том, что в составе appliance, состоящего из известного нам набора ядер, дисков и SSD, мы можем определить разумную цену за software часть решения. И стоимость софта на системе с парой процессоров 2620, одним SSD на 800GB и парой дисков SATA HDD сделать, со скидкой, сравнительно невысокой, соответствующей цене железной платформы. А на платформе с топовым процессорами, с большим объемом памяти, с множеством дисков и высокой производительностью (и ценой) — и цена софта может быть выше, и в целом получится сбалансированный по цене продукт.
Но, к сожалению, у нас нет таких механизмов в случае Software-only Nutanix. Мы не знаем, на какой платформе он будет запущен, поэтому вынуждены отпускать его пользователю по дефолтно максимальной цене. Это делает, например, бессмысленным установку SW-only Nutanix на слабые платформы, дешевле будет купить NX Appliance.

И вот, глубоко подумав, мы придумали схему с так называемыми Capacity Licenses, с помощью которых можно гибко формировать цену на Nutanix Software.
И теперь можно сделать так:

И, как результат, получается гибкая цена на Nutanix, в зависимости от мощности и возможности платформы, на которой он исполняется.

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

Подобная гибкость позволяет формировать адекватную мощности платформы цену на SW-only Nutanix (а не запузыривать туда полный листпрайс без скидок, за 100% цены), и поможет продажам нашего Software-only Nutanix, то есть продажи его как софта на платформы HPE, Cisco UCS, Dell PowerEdge, а скоро и на платформы еще нескольких популярных вендоров.

X-Ray 3.0 — теперь Open Source!

Наш тестовый пакет для нагрузочного тестирования гиперконвергентных систем и анализа получившейся производительности, который мы назвали X-Ray, прошел длинный путь. Сначала он был нашим внутренним продуктом для тестирования POC (Proof-of-Concept, тестовых демосистем, которые ставятся у потенциальных клиентов, где мы практически доказываем, что мы можем решить его задачи). Начиная с версии 2.0 мы сделали его общедоступным и открытым. Xray 2.0 и новее можно свободно скачивать и модифицировать настройки его тестовых сценариев, чтобы иметь возможность подстроить их под конкретные требования клиентов. В этом блоге я впервые написал о нем вот здесь.

Но все равно, мы постоянно сталкивались с предубеждением, что, мол, раз его сделал вендор HCI-платформы, то значит он заточен на то, чтобы демонстрировать преимущества только этой платформы, и поэтому необъективен. Тем более, что основной компонент его, ядро интерпретатора сценариев, оставался закрытым.
Поэтому мы сделали следующий шаг. Начиная с вышедшей на прошлой неделе версии 3.0 мы полностью открываем код и переходим в Open Source.

Исходные коды X-Ray Curie, это основной, до сих пор бывший закрытым, компонент X-Ray, ядро, которое интерпретирует и исполняет сценарии на YAML, выложены теперь на GitLab: https://gitlab.com/nutanix/curie

Лицензией выбрана MIT License.

Документация — тут: https://nutanix.gitlab.io/curie/

X-Ray 3.0 VM images
Nutanix AHV binary: QCOW2
VMware ESXi binary: OVA

Виртуальную машину с X-Ray можно развернуть поверх любого гипервизора, например на VirtualBox, зайти на него по IP-адресу VM в веб-интерфейс, указать в качестве таргета нужную систему, и X-Ray Curie передаст на нее сформированный в сценарии тестовый workload, запустит его, а потом покажет достигнутые результаты, и сформирует отчет.

X-Ray 3.0 Release Notes

Документация в PDF

Скачивайте, тестируйте, сравнивайте.

SAP HANA на AHV теперь официально поддерживается Nutanix

На этой неделе мы объявили о важном событии по проникновению нашей HCI архитектуры в «большой» enterprise. Вот уже два года Nutanix официально поддерживаемое HCI решение для SAP Netweaver, но пока мы говорили, что HANA — «в пути». Мы предлагали использовать под HANA сторонние физические хосты, размещая всю инфраструктурную обвязку уже в среде HCI. Но вот сами серверы базы данных HANA — это пока на HCI было не готово. «Скоро», писал я в этом блоге.
И вот «скоро» настало. На этой неделе мы официально объявили о том, что SAP HANA для non-production (то есть для test/dev) официально поддерживается в Nutanix для его гипервизора AHV. Ждем апрува этого на стороне SAP, и выпуска соответствующего SAP Note, а затем двигаемся к production на HCI.