Архив рубрики: обзоры

Обзоры продуктов

Конфигурация «1-Node» Nutanix

Как вы уже наверное слышали, у Nutanix появляется особый класс систем, которые я в целом затрудняюсь называть «кластер». Это однонодовые системы, которые, подобно тому, что вы уже, возможно, видели в Community Edition, могут работать как «кластер, состоящий из одной ноды». Раньше мы такое позволяли использовать в качестве Backup Target, а вот теперь, хорошо подумав, разрешили использовать и для запуска VM. Но подумали мы и правда тщательно, и вот ниже я перечислю все моменты, о которых вам будет нужно знать, прежде чем вы будете интересоваться предметно таким «сверхдешевым» Nutanix.

Пункт номер ноль. Это НЕ SMB решение. Это решение для рынка так называемого ROBO (Remote Office/Branch Office). Поэтому минимальная закупка таких 1-Node Nutanix — 10 штук.
То есть если у вас структура компании с множеством (десятком и более) небольших удаленных филиалов, и вы выбрали Nutanix в качестве решения для основной инфраструктуры, и при этом вам нужно оснастить Nutanix-ами филиалы и удаленные офисы, на которых практически нет вычислительной задачи, а данные для защиты все равно реплицируются на «большой» Nutanix в головной компании, то вот тогда это то, что вам нужно. В филиалы тогда идут недорогие однонодовые Nutanix, управляемые из Prism Central головного офиса. И в целом вы решаете задачу защиты данных через их репликацию в центральную систему, минимальная локальная защита у вас будет (об этом ниже). При этом типовая задача у вас для такого офиса — держать «AD, DHCP, DNS, Firewall, VPN до «головы», пять VDI операционистов, почту и файлопомойку» — то с этим вот сюда. Получается такой «филиальный допофис-ин-э-бокс», заливаемый за 30 минут и готовый к использованию «просто включи в сеть».

1. Пока мы подготовили две специальные модели для этого направления, это NX-1175S-G5 (1N1U) и NX-1155-G5 (1N2U). Обратите внимание, 1175S означает single socket, 1 pCPU. Модель 1155 уже была доступна, это 1-Node Backup Target, теперь на ней разрешено запускать Guest VMs.

Конфигурация NX-1175S-G5:
CPU: 1x 2620v4 (8-core) or 1x 2650v4 (12-core)
Memory: 64G or 96G or 128G or 256G
Hybrid:
SSD: 2x 480G or 2x 960G or 2x 1.9TB
HDD: 2x 2TB or 2x 4TB or 2x 6TB
All-Flash:
SSD: 4x 480G or 4x 960G or 4x 1.9TB
Network: 2x1GbE LOM (built-in) + Add-on NIC (Optional) : 2x1GbE or 2x10GbE (SFP+ or Base-T)
Power Supply: 1 (only!)

Сетевая конфигурация, доступная для NX-1155-G5:
4x1GbE, Add-on NIC (Optional): Dual-Port 10 GbE SFP+, Dual-Port 10 GbE BASE-T, or Quad-Port 10 GbE SFP+

2. «Расширение кластера» для 1-Node нет и не планируется. То есть, купить и установить 1-Node, потом докупить еще две и расширить на них, сделав «полный» кластер нельзя.
Однако можно собрать «большой» Nutanix Cluster из трех и более NX-1175S, но только НЕ расширением 1-Node, а переинсталляцией, с нуля. Дальше такой 1375S можно скейлить обычным для Nutanix способом, это будет обычный трех- и более нодовый кластер Nutanix из 1U Single CPU нод 1175S.

3. CVM на такой системе занимает 6 vCPU и 20GB RAM

4. Так как наша архитектура подразумевает репликацию блоков, то даже на 1-Node она будет, просто две копии блока будут храниться локально. Это не защитит от отказа контроллера или ноды целиком, но отказ одного HDD это может помочь пережить без потери данных. Отказоустойчивость предполагается решать репликацией на main cluster и локальными бэкапами, например с помощью Comtrade HYCU на сторонний NAS.
Так что репликация RF=2 будет, и usable space все равно будет ~50% от raw физических дисков.

5. Нет: дедупликации, ABS и AFS, Erasure Coding, Capacity Analysis на Prism Central.

6. Async DR (репликация на Nutanix в другом DC) — минимальный цикл 6 часов (RPO). Metro Availability конечно же нет тоже.

7. Отказ ноды — ожидаемо offline всего на ней содержащегося.

8. Отказ SSD (одного из двух) — переход хранилища в read only.

9. Гипервизоры: для 1175S — AHV и ESXi, для 1155 — только AHV. Hyper-V нет ни для одной модели.

10. Минимальная версия AOS — 5.5

Чуть позже, как только они будут объявлены, я расскажу и про вариант перечисленного, который будет носить название «2-Node».

Переход на Nutanix для компании — реальный кейс

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

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

Nutanix Xtract for VMs: как мигрировать сотни VM из VMware vSphere в AHV и не сойти с ума

Постоянно задают нам пользователи вопрос: «Как мигрировать V2V, например, с vSphere на AHV?» Ладно, если это десяток VM, можно перекорячиться руками. А если их сотни? А если нужна сложная схема взаимосвязанных операций при этом? В общем, руками — не вариант.
И вот теперь у нас появился наш собственный, отличный инструмент для переноса VM из vSphere в AHV — Nutanix Xtract for VMs. Он входит в группу инструментов Xtract, там уже есть, например, инструмент для переноса баз данных, может быть как-нибудь напишу и про него. А пока, про то, как мигрировать VM из vSphere в AHV.
Начнем с того, что Xtract for VMs это виртуальная машина, разворачиваемая на платформе Nutanix AHV. Скачать подготовленную VM в формате QCOW2 можно с нашего портала http://portal.nutanix.com, а затем развернуть ее на имеющемся у вас кластере AHV. Образ имеет размер около гигабайта, так что развертывание занимает немного времени. Можно это сделать вручную, залив скачанный образ в AHV Image Service, и затем создав из него VM. Можно также сделать более автоматизированно, с помощью Xtract CLI. Рекомендуем попробовать именно автоматизированный вариант.

Кроме процедуры развертывания, утилита Xtract CLI может быть использована для некоторых других полезных операций, но все необходимое для миграции можно сделать из графического интерфейса, написанного на HTML 5. Так что после развертывания вы скорее всего будете управлять работой Xtract с помощью этого интерфейса в браузере, введя в него IP-адрес VM с установленным в нем Xtract for VMs. 
После логона в Xtract, вам потребуется добавить исходную и целевую систему для миграции. Исходная система под VMware vSphere подключается указанием адреса ее vCenter и соответствующих логинов-паролей. Система под AHV, аналогично, требует указания на адрес кластера AHV или адрес Prism Central.

После заведения системы-источника и системы, на которую будет произведена миграция, можно создать план миграции. С помощью него мы установим, какие именно VM будут мигрировать из vSphere. На примере ниже мы выбрали группу VM, обеспечивающих работу некоего сервиса, это две VM с фронтендом, сервер приложения и сервер базы данных. Перенесем всю эту группу из vSphere в AHV.

Перед началом миграции выполняются проверки, что на целевой системе есть достаточно ресурсов (например, памяти , дискового пространства и vCPU) для размещения переносимых в заданном плане виртуальных машин. Xtract группирует пригодные и непригодные для миграции машины, и снабжает их комментариями, позволяющими разобраться почему, например, данная VM не может быть перенесена. Это может быть, например, необходимость установки в VM средств Vmware Tools, или несоответствие версии virtual hardware, либо еще какие-то проблемы. Со стороны OS VM, все OS, поддерживаемые в AHV, также поддерживаются и в Xtract for VMs. Полный список всех поддерживаемых OS можно найти на портале.
Xtract использует возможности VMware vStorage API for Data Protection (VADP) для управления процесса репликации данных, поэтому на стороне VM или хоста ESXi нам не нужно устанавливать никаких агентов. Опционально можно разрешить Xtract подключаться в VM для установки в нее драйверов (VirtIO), обеспечивающих работу VM OS в среде AHV, однако это можно сделать и заранее вручную. Если вы хотете сделать это как часть процесса миграции, укажите соответствующие логины и пароли для мигрируемых VM, для всех вместе или для каждой индивидуально. Также настраивается и маппирование сети между ресурсами исходной и целевой сетей. Наконец, вы можете создать расписание миграции, запланировав ее на определенное время.

После настройки всего перечисленного выше, можно начинать миграцию. Как упоминалось выше, мы используем механизмы VADP для переноса содержимого виртуальных дисков VM на кластер AHV. Система создает снэпшот ESXi для каждой VM, а затем перенесет его в заданный контейнер AHV. Запущенную миграцию конечно же можно, при необходимости, поставить на паузу или прервать в любой момент. 

Файлы виртуальных дисков мигрируемых VM запоминаются во временной директории, и поддерживаются актуальными даже в случае изменения исходных данных, с помощью механизма change block tracking (CBT) API и дополнительных снэпшотов.
Когда наступает пора провести cutover, и закончить процесс миграции, Xtract выключает исходные машины, выполняя для них power-off, и отключает их виртуальные NIC. Инкрементально накопившиеся данные синхронизируются с перенесенными на AHV данными VM. Когда данные полностью реплицированы, файлы vmdk конвертируются силами AHV image service в нативный формат RAW, используемый в AHV. Конверсия происходит быстро, так как vmdk и RAW, по сути, идентичные форматы, так что обычно это занимает секунды. Xtract также указывает оценочное время выполнения, так что легко можно определить необходимые на операцию затраты времени и период даунтайма.

Виртуальные машины, согласно вашему плану миграции, могут делать cutover все вместе или индивидуально. Для такой группы связанных VM как на нашем примере, cutover можно начать с базы данных, затем провести его для сервера приложений, а затем для фронтэнда. После завершения миграции, VM включаются и все временные vmdk и конвертированные образы в AHV image service удаляются. Исходные VM остаются в состоянии выключенных, и сохраняются неизменными, на случай, если они вам понадобятся. К каждой мигрированной VM добавляется комментарий, где указывается, что данная VM является мигрированной, указывается дата и время миграции и версия Xtract, которая эту операцию проводила.

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

Вот и все. Процесс миграции с vSphere на AHV еще никогда не был для пользователя настолько простым.

Comtrade HYCU v1.5

Я уже упоминал в блоге о новом продукте для бэкапа Nutanix, сделанного небольшой (на самом деле не такой уж «небольшой», около 1000 инженеров в компании, и около 200 — на направлении бэкапа) восточноевропейской компаней Comtrade — HYCU, а вот уже подоспело обновление до версии 1.5. Те, кто ни за что не поставят первую версию продукта (где-то вы даже правы, обычно), можете начинать смотреть.

К преимуществам HYCU следует отнести не только изначальную заточенность на Nutanix, но и сравнительно невысокую цену лицензии на решение, например, ниже чем у Veeam B&R.

Вот список новинок из Release Notes:

  • Появилось возможность в явном виде задать «окно бэкапа», в которое должны будут уложиться все backup jobs системы.
  • Можно задать число параллельно выполняемых backup jobs для данного таргета.
  • При создании бэкапа VM можно сохранять сделанные в ней снэпшоты, чтобы иметь возможность быстрого восстановления состояния VM
  • Появилась возможность использовать для бэкапа iSCSI Target. В первой версии можно было бэкапиться только на NAS или в «облако» (AWS S3, Azure).
  • Теперь можно использовать iSCSI Target на какой-то внешней блочной СХД с iSCSI, например.
  • Улучшены механизмы резервного копирования и восстановления, за счет использования некоторых возможностей Nutanix, которые не использовались ранее. Это позволило поднять производительность как резервного копирования, так и восстановления.
  • Файлы из бэкапа могут быть восстановлены на shared location, с совместным доступом к location с нескольких клиентов.
  • Постепенно расширяются возможности app-specific backup. К бэкапу SQL Server добавились методы резервного копирования Active Directory в контроллере AD в VM. Список поддерживаемых приложений и методов бэкапов для них будет, конечно, расширяться.
  • Можно вручную задавать для какого-то бэкапа состояние expired, тогда этот бэкап будет удален с таргета и занимаемое им место высвобождается.
  • Появились более гибкие email notifications на разные события.

Поддерживается версия Nutanix OS от 5.1 и новее.
Поддерживаются Windows OS 7, 8, 10, Server 2008R2, 2012, 2016.
Для app-specific и file level restore поддерживаются файловые системы внутри VM: FAT, FAT32, NTFS.
Поддерживаются версии MS SQL Server: 2008R2, 2012, 2014, 2016.
Поддерживаемые версии AD: 2008R2, 2012, 2016
В качестве backup target может использоваться: SMB (1.0, 2.0, 3.0), NFS (3.0, 4.0), AWS S3 (и совместимые), MS Azure, iSCSI Target.

Как и ранее, триал можно взять на сайте Comtrade, причем для развертывания на CE можно попросить бесплатную лицензию.

Что нас ждет до конца этого года? Технические новинки.

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

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

* Near-Sync Replication. Довольно долго у нас был не всех устраивающий лимит на цикл асинхронной репликации данных между кластерами Nutanix в один час. Это было связано с тем, что механизм снэпшотов, используемый у нас, накладывал слишком большие накладные расходы на слишком частые «снимки», используемые в механизме репликации. В ближайшем релизе мы представляем долгожданные lightweight snapshots, механизм, дополняющий наш обычный механизм снэпшотов, с помощью которых мы можем делать 15-минутный цикл репликации, а, в отдельных случаях и для отдельных приложений, и вплоть до 1 минуты RPO.

* Поддерживается Hyper-V 2016. Что тут еще добавить. Начиная со следующего релиза не только полностью поддерживается Windows Server 2016 в гостевой VM, но и Hyper-V 2016 в качестве хостовой виртуализации.

* Появится поддержка vGPU и vNUMA. Сейчас у нас пока в AHV поддерживается только физический проброс GPU, полноценный vGPU в самом ближайшем будущем, как и vNUMA.

* Turbo Mode о котором я уже писал чуть раньше, выходит в релиз. Это механизм, упрощающий и распараллеливающий путь данных от VM к физическим дискам, что насущно важно для быстрых «твердотельных» дисков, в частности, для NVMe.

* Шифрование данных на дисках появится не только в форме поддержки SED — Self-encrypted Disks, но и чисто программным образом, на обычных дисках. Можно будет создавать зашифрованные контейнеры, для тех данных, которые в этом нуждаются. Для России это будет, вероятно, также недоступно по причине действующего законодательства, как и в случае SED.

* Наконец-то доползла до релиза долгожданная наша микросегментация сети! Ее первый выход в свет в форме, как у нас принято, Technical Preview, будет в ближашем релизе. Я уже немного упоминал про то, что это, но чуть более развернуто: это «наш ответ NSX», скажем так. Возможность создавать в виртуальной среде специальные сегменты-зоны сетевой доступности, и назначать их политиками на определенные VM. Это будет гораздо проще и легче, чем сегментирование с помощью, например VLAN.
Для VM, которые могут мигрировать не только между хостами кластера, но и между кластерами, в том числе, в будущем, между локальным и удаленным облаком, критически важно сохранять структуру сетевой подсистемы и носить ее «с собой», а, при необходимости, быстро ее реконфигурировать, без необходимости делать это через, допустим, перепрограммирование VLAN-ов на внешних коммутаторах. С помощью нашей Microsegmentation вы сможете создавать сетевые сегменты внутри виртуальной среды, ограничивать области «видимости» для групп VM, назначать в них нужные вам VM с помощью политик, причем эта сегментация через политики будет следовать за VM в том числе в случае ее миграции по хостам. Сейчас такое обычно требует чего-то вроде VMware NSX, дорогого и, часто, избыточного. Microsegmentation тоже будет небесплатным, но включенным в AHV, как, например, мы сделали с AFS (Ultimate и standalone-лицензия для более низких уровней лицензий). В любом случае, уже понятно, это будет существенно дешевле NSX. Так что если вы использовали NSX на vSphere только ради сегментации виртуальной сетевой инфраструктуры — это еще один повод посмотреть AHV.
Tech Preview — в ближайшем релизе. Production Release — как обычно, в следующем за ним.

* Ну и много всякой мелочи, о которой «через запятую». Продолжаем улучшать ИИ в Prism Central, появится диагностика аномального поведения VM и хостов и анализ его причин, аналитика предсказательного сервиса в Prism Central будет учитывать поведение VM в их исторической перспективе. Self-service будет работать в том числе и на многокластерной конфигурации.

Затем, мы ожидаем в декабре-январе (в зависимости от того, как лягут звезды) следующий релиз, и в нем:

* Как я уже писал выше — в следующем за techpreview релизе приходит production release для microsegmentation и security groups.

* Step 2 выкатки функциональности для CALM. Новые возможности CALM будут выходить постепенно, в несколько ступеней. Первые две — в этом году.

* Prism Central будет уметь Scale-out. Сейчас это одна VM, что непорядок. Сам Prism-то у нас полноценный Scale-out на скейлаут инфраструктуре. Вот теперь и до Prism Central дело дошло, он тоже будет масштабируемый, что насущно важно для по-настоящему больших распределенных инфраструктур.

* В AFS, нашем scaled-out файловом сервисе, появится NFSv4. Отметьте, что пока не v3 и не SMB3, все это в ближайшем будущем, по-порядку.

* Появится вариант, разрабатывавшийся в течение этого года, и предназначенный для ROBO-сегмента — 2-node cluster. Технические детали по нему — в свое время.

* Появится поддержка для узлов высокой емкости, вплоть до 80TB raw на ноду.

Ну а дальше — год 2018. На него у нас есть свои большие планы, о чем — в свое время.

Почему вам не нужно ставить в компании OpenStack: практический опыт

У меня тут есть, судя по логам, суперпопулярная статья со ссылкой на пост на Хабре: История двухлетнего опыта использования ceph в веб-хостере и полученный опыт.
Продолжим же инициативу, раз она пользуется успехом у моих читателей.
Пару дней назад там же на Хабре была опубликована статья под заголовком:
Итак, вы решили развернуть OpenStack.
В ней автор рассказывает о собственных злоключениях в течение двух лет, в попытке заставить стабильно работать кластер OpenStack.

Немного цитат:
«В общем, в 2012-м мы развернули OpenStack, на тот момент это был Essex, запустили проект, прожили с такой облачной инфраструктурой до 2014-го года, кажется до релиза Grizzly включительно. Сил и желания поддерживать его дальше не было, и OpenStack был с позором выпилен.

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

Так часто у меня спрашивают про OpenStack, что, как мне кажется, тема требует своего освещения. Как вы, возможно, знаете, уже примерно год у нас есть инструмент, позволяющий встроить и использовать Nutanix как компонент типа hypervisor в среду OpenStack. Но это интересно только пользователям, у которых уже есть развернутся работающая инфраструктура OpenStack, например они уже инвестировали в это продукт, и они не хотят немедленно отказаться от него, но им нравится Nutanix. Для этого варианта мы сделали специальную VM интеграции, которая транслирует вызовы API OpenStack, в наш RESTful API Nutanix. Но, соглашусь с автором, наиболее разумным будет отказ от OpenStack, в стратегической перспективе, а использование нашего интерфейса интеграции может помочь провести переход наиболее безболезненно.

Основные недостатки, по мнению автора: сложность и тяжеловесность.

Когда-то давно, когда мы ставили Essex, там было все относительно просто и понятно. Keystone (служба авторизации), Glance (служба хранилища образов) и Nova (служба управления гипервизорами). Кроме того там еще был Horizon (дашборд) и куча мелких и не очень зависимостей. Каждый узел системы обрастает чуть ли не десятками вспомогательных демонов. На controller node через некоторое время становится страшно смотреть.

Архитектура OpenStack достаточно сильно фрагментирована. Есть очень большое количество «движущихся частей», взаимосвязь который между собой не всегда абсолютно ясна. У вас что-то сломалось? Окей, попробуй понять где это что-то сломалось и почему. OpenStack Foundation похоже гордится, что в OpenStack более 20 миллионов строк кода, даже на главную своего сайта вынесли. Так вот, ЭТО НИФИГА НЕ ДОСТОИНСТВО.
Код в большинстве своем написан на Python. Спасибо, OpenStack, благодаря тебе я возненавидел Python и все что с ним связано.

Дело в том, что являясь OSS, OpenStack пытается быть kind of unix-way. Т.е. под капотом все эти монструозные службы на самом деле дергают десятки и сотни unix-утилит по собственной логике, которую вам придется изучить и возможно даже дебажить.

Нестабильность:

ну вот вы наконец-то запилили инфраструктуру своей мечты, все худо-бедно работает как рассчитывали, но не хватает одной мааааленькой детали. А в новом релизе она есть. Ну по крайней мере по Release Notes.
Окей гугл, давай обновим наш OpenStack. И тут выясняется, что функционал, который вы с радостью использовали — выпилили. Ну потому что. Ну некрасивый он был и вообще, мы лучше сделаем, честно-честно. В следующем релизе. Может быть. А пока вот вам попроще, но ведь работает же! Ну и плевать что не в вашем случае, но работает!

И вообще сырость, в лучших традициях OSS:

А еще очень дивное чувство испытываешь, когда тебе нужен функционал, ну, скажем, деление на зоны. Ну вот есть у тебя машины с большими винтами, есть с SSD, есть с видюхами, хочу разбить кластер на зоны, чтобы виртуалка падала на ту машину, у которой необходимый ресурс есть. Ну ок, читаем доку, вроде бы availability zones подходит. Настраиваем, включаем. И ничего. В доке написано что все должно, а на практике ничего. Лезем в код, а там.
Будет реализовано. В следующем релизе. Может быть. Ну ты понял. Смотри предыдущий пункт.

Автор там, правда, делает вывод в конце:

В общем после полутора лет борьбы с OpenStack мы от него отказались и перешли на другое облако. Управление инфраструктурой стало простым и приятным, а обновлять версий также просто как apt dist-upgrade.
Что это за облако и почему оно удобнее OpenStack я постараюсь рассказать в следующей статье. (Спойлер: это OpenNebula).

Но мы то с вами, посетителями этого блога, знаем еще более правильный вариант. ;)

Nutanix для 1-Tier и Business Critical — опыт компании ЦФТ

Недавно мы завершили испытания системы Nutanix в компании ЦФТ — Центр Финансовых Технологий. Под таким незамысловатым названием скрывается компания-разработчик банковских информационных систем, работающая не только в России, но и за рубежом, с численностью более 2000 человек. ЦФТ входит в TOP-5 крупнейших разработчиков ПО, действующих на российском рынке.
Свыше 500 банков РФ и СНГ используют программные продукты и сервисы ЦФТ: Сберегательный банк РФ, Газпромбанк, «Возрождение», банк «РОССИЯ», «Банк Санкт-Петербург», «Еврофинанс Моснарбанк», «Росгосстрах Банк», Банк «УралСиб», банк «Петрокоммерц», Национальный банк «ТРАСТ», «МДМ Банк», Банк «Финансовая Корпорация Открытие», «Связной Банк», «Восточный Экспресс Банк», «Национальный резервный банк», Банк «Финансово-промышленный капитал», «БКС Банк», Банк «РЕСО Кредит», «Нордеа Банк» и многие другие в странах СНГ.

Сотрудники этой компании несколько месяцев назад тщательно и придирчиво тестировали Nutanix под самую Critical Tier-1 нагрузку разрабатываемых ими программных банковских систем. По результатам тестирования был выпущен отчет, который я и предлагаю ниже вашему вниманию: (PDF)

Nutanix for Critical Tier-1 workload - CFT report

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

Кстати, для внимательных: кто найдет что-то необычное и интересное в тестируемой конфигурации? Там есть кое-что о чем мы публично еще не рассказывали, но вот-вот объявим. :)

Опубликованы результаты Q3FY2017

Опубликованы результаты Nutanix для Q3FY2017, то есть третьего квартала финансового года 2017 (у нас, как это принято в Америке, финансовый год начинается в сентябре).

Скучные подробности про GAAP ищите на соответствующих сайтах, а пока — традиционная уже картинка:

Сколько в мире сегодня «гиперконвергентных решений»?

Наш коллега в своем блоге делает подсчеты и собирает индекс «гиперконвергентных решений», существующих на сегодня. У него получилось 34 (Тридцать Четыре!) продукта, без учета выбывших и «слившихся» с другими.
Конечно, добрая половина там — компании «ниже горизонта», не уверен даже что у них вообще есть хоть какие-то продажи, но сам факт!
В этом списке огромный диапазон компаний, от HP и EMC, до, например, QNAP и Promise. Поистине, сегодня гиперконвергенция — самая горячая тема в IT.

http://bythebell.com/2016/01/hyperconverged-players-index.html

Как настроить и использовать Nutanix SSP

Если вы хотите разобраться как настроить, использовать, и что вообще такое SSP — Nutanix Self-service Portal, то рекомендую вам просмотреть серию из шести статей, написанных в блоге нашего инженера, Магнуса Андерссона: http://vcdx56.com/category/ssp/.
Очень подробно, пошагово, с массой скриншотов рассмотрено как настраивать и использовать SSP. Все настолько детально и подробно, что не требует даже перевода.
SSP — это наш встроенный в Acropolis продукт, позволяющий построить портал самообслуживания для «частного облака» компании на базе AHV и Nutanix. Вы можете создавать лимиты на ресурсы для групп пользователей (которые интегрируются с корпоративным AD/LDAP), создавать заранее подготовленные для развертывания пользователями образы VM, делегировать управление, в общем все то, для чего ранее вам нужно было переходить на VMware и ее vCloud Director, теперь вы это сможете сделать в рамках Acropolis Hypervisor на Nutanix.