Ни для кого не секрет, что следующий год для технологий виртуализации станет годом облачной инфраструктуры. Многие вендоры, сервис-провайдеры и интеграторы обещают пользователям "золотые горы", предлагая облачные услуги различного характера (SaaS, PaaS и IaaS), построенные на базе самых разных архитектур.
VMware в этом плане также старается не отставать, предлагая свои фреймворки, описывающие архитектуру частных и публичных облаков, построенных на продуктах VMware vSphere, vCloud Director, Request Manager и прочих. Одним из таких фреймворков является vCat - vCloud Architecture ToolKit.
В рамках документов, предлагаемых в составе vCat, вы найдете не только детальное описание архитектуры облачной среды, построенной на базе ПО VMware, но и конкретные примеры развертывания частного или публичного облака. Вот, собственно, сами документы:
Document Map – Document descriptions, function, and table of contents.
vCAT Introduction – Considerations when first developing your Cloud strategy.
Мы уже не раз писали о продукте номер 1 для создания отказоустойчивых хранилищ iSCSI для виртуальных машин - StarWind Native SAN for Hyper-V (см. тут и тут). Напомним, что он позволяет, используя всего 2 сервера с установленной ролью Hyper-V сделать отказоустойчивый кластер как хранилищ, так и серверов, сэкономив 50% бюджета.
Сегодня хотим обратить ваше внимание на несколько документов по продукту StarWind Native SAN for Hyper-V, которые помогут детальнее ознакомиться с данным решением:
This white paper describes in details the benefits of the recently released StarWind revolutionary product called StarWind Native SAN for Hyper-V. The document highlights the might of server virtualization consolidated with the shared storage.
This white paper outlines advantages of server virtualization and gives detailed description of features and benefits provided by the shared storage. The document describes how to build a cost-effective, reliable and powerful storage infrastructure using the StarWind iSCSI SAN solution and lists the hardware prerequisites. The white paper also gives the step-by-step instruction of how to connect vSphere to ISCSI SAN.
This white paper mentions the advantages of virtualization and gives a short description of the components that help your system avoid downtime and stay 100% up and running. The document provides practical recommendations of how to build the replicated environment in order to ensure 100% uptime of your storage infrastructure.
This white paper provides an overview of how a SAN can help overcome limited IT budgets, being effective and inexpensive solution for educational institutions.
Скачав эту утилиту совершенно бесплатно, вы узнаете, насколько ваша виртуальная инфраструктура соответствует следующим общепринятым нормам обеспечения безопасности виртуальной среды:
vGate Compliance Checker for VMware vSphere 5 и VMware vSphere 4.1 New!
PCI DSS 2.0
VMware Security Hardening Best Practices 4.1
CIS VMware ESX Server Benchmarks 4
vGate Compliance Checker for VMware Infrastructure и VMware vSphere 4
PCI DSS 1.2
VMware Security Hardening Best Practices 4
CIS VMware ESX Server Benchmarks 3.5
Отчет будет выглядеть примерно так:
То есть для каждого несоответствия нормам безопасности вам не только расскажут о самом факте, но и дадут ссылку на соответствующий пункт регламентирующего документа. Для многих компаний это будет весьма полезно - узнать, сколько у них потенциальных проблемных мест в сфере ИБ для инфраструктуры виртуализации.
Интересное (но неофициальное) исследование на тему миграции на новую версию платформы VMware vSphere 5 опубликовано на блоге virtualgeek. Было опрошено 1935 респондентов. Напомним, что VMware vSphere 5 вышла в августе этого года.
Самый занимательный график - это ответы на вопрос "Какую версию VMware vSphere вы сейчас используете?" (допускалось более одного варианта ответа):
59,2% для vSphere 5 - это очень и очень большой показатель, учитывая выход продукта 4 месяца назад.
Полезен также график ответов на вопрос "Используете ли вы другие технологии виртуализации":
Ну Hyper-V понятно, но, фигасе, XenServer жжет. Неожиданно.
Далее вопрос о проценте виртуализованных серверов (но надо учитывать специфику исследования - отвечали люди, которые крутятся в сфере виртуализации). График в лучших традициях Чурова, но автор говорит, что результат где-то 86%.
Далее - тоже интереснейшая тема. Системы хранения каких вендоров используют под виртуализацию:
EMC на высоте - молодцы. Но, по-моему, автор из EMC, поэтому тоже надо на это делать скидку.
Ну и теперь - ответьте на вопросы для нашего небольшого исследования:
Для пользователей решения по виртуализации настольных ПК предприятия VMware View появилась красивая бесплатная утилита PCoIP Log Viewer 2.0 для визуализации статистики, собираемой через WMI для PCoIP-сессий в виртуальных ПК.
Возможности PCoIP Log Viewer 2.0:
Парсинг и графическое отображение метрик производительности PCoIP из лог-файлов (для View 4.x, 5.0)
Отображение в реальном времени счетчиков WMI для PCoIP (View 5.0)
Возможность сохранять сессии WMI для дальнейшего просмотра и анализа
Возможность WMI-Rewind для перемещения во временном интервале для статистики сессии
Вкладки для различных сессий WMI и лог-файлов
Возможность Drag-and-Drop лог-файлов в окно просмотрщика
Экспорт сохраненных WMI-сессий в формат XLSX для дальнейшего анализа и возможности построения своих графиков
Классная штука. Скачать PCoIP Log Viewer 2.0 можно по этой ссылке.
Вот тут те же IDC пишут, что к Virtualization 3.0 развитый мир придет не раньше 2013 года, а главными ее признаками будут полностью виртуализованный ЦОД, объединяющий сервисы собственного внутреннего облака и внешних облаков сервис-провайдеров, адаптивная инфраструктура (если проще - то самооптимизирующаяся) и сервисно-ориентированная бизнес-модель.
Вообще, это интересная штука - классификация зрелости виртуализации по верисям - Virtualization 1.0, 2.0 и 3.0. Если кратко, то эти этапы, с точки зрения признаков, преимуществ и используемых технологий, на примере VMware я бы охарактеризовал так:
Virtualization 1.0 - консолидация
Аудит собственной инфраструктуры физических серверов
Выбор платформы - базовая консолидация серверов (низкая и средняя критичность)
Экономия капитальных и операционных затрат (серверы, электричество), но больший фокус на капитальных
Быстрый экспансивный рост виртуальной инфраструктуры (зачастую, бесконтрольный)
Применение разнородных скриптов и стороннего ПО для решения специфических задач
Virtualization 2.0 - управление
Унификация развертывания новых серверов в виртуальных машинах (то есть, запрос на создание сервера формируется в виде вычислительных ресурсов и хранилища - без привязки к оборудованию). Автоматизация процессов выделения ВМ пользователям
Фокус на операционных затратах (сокращение издержек на управление, обслуживание, мониторинг, резервное копирование и т.п.) и отдаче от возможностей ПО виртуализации (интенсификация, увеличение коэффициента консолидации)
Внедрение новых средств управления виртуальной средой (мониторинг, отчетность, интеграция с существующим ПО для управления датацентром)
Унификация процедур управления: обновлений, настройки конфигурации хостов и ВМ, шаблоны рабочих процессов (например, VMware Orchestrator, Host Profiles, запланированные задачи и т.п.)
Управляемое планирование мощностей виртуальной среды (Capacity Planning)
Построение модели TCO/ROI дл виртуальной инфраструктуры (сколько обходится ее содержание и как окупаются инвестиции)
Внедрение специализированных средств обеспечения безопасности
Первые производственные внедрения VDI-инфраструктуры (для наименее критичных пользователей)
Расширенные сервисы по отказо- и катастрофоустойчивости инфраструктуры (например, VM Monitoring и VMware SRM + план восстановления после сбоев, репликация ВМ)
Расширенные сервисы управления ресурсами (например, VMware Net I/O Control, Storage I/O Control, DPM и т.п.)
Расширенные сервисы мобильности (Storage vMotion+vMotion между ЦОД, распространение виртуализованных приложений в виде пакетов, Offline Desktops для VDI)
Расширенные сервсиы хранилищ (VMware Storage DRS, профили хранилищ, ярусное хранение данных серверов и виртуальных ПК, VAAI)
Унификация средств решения рутинных задач (например, VMware PowerShell/PowerCLI, Orchestrator)
Первые опыты по формализации внутреннего облака (постоянный учет затрат, соглашения SLA внутри компании, выдача ресурсов по требованию, обслуживание жизненного цикла ВМ)
Первые опыты по использованию сервисов публичных облаков
Virtualization 3.0 - самооптимизация и услуги для бизнеса
Виртуализация Tier 1 систем (самая высокая критичность)
Полная автоматизация операций по управлению виртуальной средой, внедрение средств самооптимизации вычислительных ресурсов, сетей и хранилищ
Унификация использования адаптивных сервисов (например, Storage DRS, SIOC и т.п.)
План для всех видов отказов и простоев в виртуальной инфраструктуре - оформление SLA для пользователей (доступность, производительность и т.п.)
Делегирование части полномочий "повзрослевшим" пользователям (выдача ресурсов по требованию самому себе, порталы самообслуживание, средства управления и контроля)
Непрерывный учет затрат (например, VMware Chargeback), четкое представление о том, сколько стоит 1 МБ и 1 ГГц для соответствующего SLA или Tier, т.е. любая создаваемая ВМ.
Интеграция и федерация (сведение в одну точку управления) средств управления и мониторинга физической и виртуальной среды (от уровня приложений до уровня ЦОД)
Гетерогенные среды виртуализации (например, где-то Hyper-V будет использовать выгоднее, чем VMware с точки зрения TCO) + единые средства управления такими средами
Виртуализация хранилищ SAN (например, EMC VPLEX + интеграция с виртуальной средой)
VDI как стандарт настольных ПК в организации (доставка ПК, клиентский гипервизор + доставка в них виртуализованных приложений) - этот момент, кстати, спорный, т.к. может быть заменен альтернативной облачной концепцией
Оформление внутреннего облака предприятия (учет мощностей и денег, SLA, ITaaS, уровни доступности, классы обслуживания и т.п.) + возможности предоставления услуг внешним организациям, а также аффилированным или дочерним компаниям (зависит от специфики организации)
Расширение использования внешних облаков (SaaS+PaaS+IaaS), механизмы использования ресурсов внешнего облака по требованию
* Внимание! Цены указаны по курсу доллара ЦБ РФ на 29.11.2011. При покупке уточняйте стоимость у менеджера Softline.
Все системы хранения NetApp обеспечиваются трехлетней гарантией. Гарантия включает в себя сервис по замене вышедших из строя частей с доставкой по месту установки системы хранения на следующей рабочий день.
Надо сказать, что NetApp делает крутяцкие массивы, которые хорошо интегрированы с технологиями виртуализации VMware (см. тут, тут и тут). Кроме того, массивы NetApp обеспечивают поддержку технологии VAAI, которая во многих случаях в разы увеличивает производительность хранилищ виртуальных машин.
Получить консультацию и приобрести дисковые массивы NetApp вам поможет Роман Карнаухов (e-mail: netapp@softline.ru, тел. +7 (495) 232-0023, доб. 0959).
Наконец-то хоть кто-то сделал (или я только узнал) человеческую утилиту для добавления custom-драйверов в дистрибутив (ISO) сервера VMware ESXi 5. На сайте v-front обнаружилось средство ESXi-Customizer:
Утилита ESXi Customizer полностью бесплатна и имеет GUI под Windows, однако, отметим, что такой способ вставки драйверов в дистрибутив ESXi не поддерживается со стороны VMware. Во время получения финального ISO-образа ESXi вы можете прервать процесс и поменять различные параметры целевого образа (в текстовом фале):
Скачать утилиту ESXi-Customizer можно по этой ссылке. Также по теме будет интересна вот эта статья.
Да-да, это не опечатка - 20% и менее. Компания StarWind Software, поставщик продукта номер 1 - StarWind Enterprise - для создания отказоустойчивых хранилищ iSCSI виртуальных машин VMware vSphere и Microsoft Hyper-V, объявила о начале рождественской распродажи лицензий на ПО:
Смотрите, штука такая - 16 декабря назначается скидка на покупку ПО StarWind Enterprise в 20%. Далее каждый день она уменьшается на 1% и 26 декабря заканчивается на отметке в 10%:
Правда сильная маркетинговая штука? Акция действует и для России (инфа 100%). Поэтому, если вы планировали купить StarWind Enterprise в редакциях HA или CDP - бегите быстрее к вашему поставщику и хватайте скидки (можете обратиться, например, к нам).
О новых возможностях StarWind Enterprise 5.7 и 5.8 можно почитать тут и тут, соответственно. О том, для чего нужен продукт - читайте здесь.
Обновилась знаменитая шпаргалка по VMware vSphere от Forbes Guthrie - vSphere 5 vReference card (см тут). Теперь в нее добавлен раздел по установке серверов VMware ESXi 5:
Хорошая новость от Veeam - теперь любой VCP, MVP, VCI, vExpert и просто участник какого-нибудь захолустного VMware User Group может получить бесплатную лицензию на Veeam Backup and Replication 6 на 2 процессора для тестирования дома и на работе. Однако помните, что выданные NFR-лицензии нельзя использовать в производственной среде (а можно только для тестирования и обучения).
Но 2 сокета - это как-то мало. Поставьте к этой статье NN лайков, и, возможно, Veeam увеличит количество выдаваемых сокетов (мы пообщаемся на эту тему, если вас будет много).
Вторая интересная новость: вышел отчет "Virtualization Data Protection 2011" от Veeam. Отчет представляет собой исследование 500 крупных компаний на предмет того, как они защищают данные в виртуальных средах.
Там есть интересная инфографика, как, например, стоимость часа простоя критической системы в разных странах (че-то вообще дофига):
Мы уже писали о том, что не так давно компания Citrix выпустила обновленную версию ПО для виртуализации и доставки приложений Citrix XenApp 6.5. Одна из интересных функций продукта - Citrix Instant App Access, реализующая мгновенный доступ к приложению за счет создания фоновой ICA-сессии сразу после входа пользователя через Citrix Receiver, что заметно сокращает время доступа к приложению.
Хотелось бы раскрыть несколько деталей о ее работе. Во-первых, в рамках фермы приложений XenApp после логина пользователя в Citrix Receiver, сессия ICA-создается только для одного из серверов, в качестве которого выбирается самый менее загруженный. Во-вторых, эту функцию можно настроить таким образом, что после логина пользователя в Receiver сессия создаваться не будет, но после закрытия недавно открытого приложения она будет оставаться в фоне (в течении настраиваемого времени), что позволит потом открыть это приложение без создания новой сессии.
Ну и, в-третьих, надо помнить, что Citrix Instant App Access, будучи включенной, потребляет клиентскую лицензию (то есть фоновые сессии тоже считаются за обычные), поэтому надо подумать о том, как настроить ее для различных типов пользователей.
Ну и последнее - это возможность Fast Reconnect, которая при неожиданном отключении пользователя и его повторном подключении находит его сессию в списке и привязывает его к данной сессии (то есть при логине в таких условиях время соединения уменьшается с 6-и секунд где-то до 3-х).
Интересная штука обнаружилась в настройках мониторинга VMware vSphere. Оказывается в vSphere Client можно вывести информацию о том, сколько электроэнергии потребляет отдельно взятая виртуальная машина на хост-сервере ESXi.
Для этого необходимо выставить экспериментальную настройку Power.ChargeVMs в Advanced Options (которая по-умолчанию установлена в 0) в значение 1 на каждом из хостов ESXi:
После этого мы получим вот такой график в vSphere Client, отражающий потребление виртуальной машиной электричества (видимо, высчитывается из актуальных значений загрузки хоста по памяти и процессору). Кликабельно:
Для чего это нужно? Очевидно, что для таких продуктов, как VMware vCenter Chargeback, который высчитывает, во сколько обходится содержание различных объектов виртуальной инфраструктуры VMware vSphere. Кстати, недавно вышло обновление - VMware vCenter Chargeback 2.0.
Еще очень давно компания VMware выпустила продукт VMware vCenter Orchestrator, который является платформой для автоматизации задач администраторов VMware vSphere. Этот продукт позволяет создать определенный рабочий процесс (Workflow), который представляет собой совокупность взаимосвязанных действий, которые, составив однажды, можно исполнять впоследствии, что очень помогает при типовых операцях в виртуальной инфраструктуре (например, миграция большого количества систем, создание пула ресурсов с тестовыми виртуальными машинами и т.п.). Эти рабочие процессы может выполнять уже не администратор, а, например, оператор, наделенный соответствующими полномочиями.
По-сути VMware vCenter Orchestrator - это фреймворк со своим GUI, который, кстати говоря, раньше использовался различными продуктами компании VMware (например, VMware Lifecycle Manager, на смену которому пришел VMware vCloud Director в части Request Manager). При этом функциональность Orachestrator может быть расширена за счет различных плагинов, которые предоставляют возможности интеграции как с объектами виртуальной инфраструктуры (например, развернуть новый хост ESXi за счет AutoDeploy), так и со сторонними приложениями (например, внести изменения в Active Directory). Вообще говоря, VMware vCenter Orchestrator - очень классная и мощная вещь, которая, зачастую, игнорируется администраторами vSphere (особенно продукт актуален для крупных развертываний).
На днях VMware объявила о выпуске сразу 4-х новых плагинов к VMware vCenter Orchestrator:
1. VMware vCenter Orchestrator SQL Plug-In. Этот плагин позволяет автоматизировать операции с базой данных (например, перевод ее в соответствующий режим или вставка записей). Теперь это может пригодиться при миграции баз данных или других операциях, требующих выполнения SQL-запросов перед операциями в виртуальной среде.
2. VMware vCenter Orchestrator Plug-In for vSphere Auto Deploy. Плагин позволяет ввести в строй новый сервер ESXi и выполнить далее, например, операции по развертыванию на нем парка ВМ.
3. vCenter Orchestrator Multi-Node Plug-In. Плагин для управления несколькими экземплярами VMware vCenter Orchestrator.
4. vCenter Orchestrator Plug-In for Microsoft Windows PowerShell. Самый долгожданный плагин, позволяющий добавить в рабочий процесс сценарии PowerCLI, которых на сегодняшний день написано огромное множество.
Выглядят плагины так (смотрите, сколько там еще всего интересного):
Мы уже писали о том, что недавно вышла бета-версия StarWind 5.8 - продукта номер 1 для создания отказоустойчивых хранилищ iSCSI под виртуальные машины Hyper-V и VMware vSphere (загрузить бету можно по этой ссылке).
Как многие знают, продукт поставляется в двух версиях: собственно StarWind Enterprise HA 5.8 для виртуальных машин на серверах ESX / ESXi, а также решение StarWind Native SAN for Hyper-V, которое является уникальным в своем роде: с помощью него мождо сделать кластер отказоустойчивости как для серверов, так и для хранилищ (см. тут).
Для версии продукта под Hyper-V появилось интересное нововведение - возможность резервного копирования виртуальных машин Hyper-V:
ArCycle Backup for Hyper-V - это плагин к StarWind Native SAN 5.8, который позволяет копировать виртуальные машины с нескольких серверов Hyper-V и сохранять резервные копии на пуле серверов хранилищ. Его основные возможности:
Простая установка
Высокая скорость резервного копирования и восстановления
Единая центральная консоль как для организаци хранилищ, так и управления резервным копированием
Работает без агентов в виртуальных машинах
Без простоя виртуальных машин
Поддержка дедуплкации целевых хранилищ резервных копий
Реализовано в виде сервиса VSS
Режим "sandbox"
Попробуйте - особенно для виртуальных машин Hyper-V должно работать хорошо. Пробную версию продукта StarWind Enterprise 5.8 Beta можно скачать по этой ссылке. Бесплатная версия продукта доступна тут.
Помните, мы писали, что снапшоты виртуальных машин в VMware vSphere - это плохо? Но иногда без них не обойтись - например, системы резервного копирования (например, Veeam Backup and Replication) вынуждены делать снапшоты, чтобы не прерывать работу виртуальной машины во время бэкапа.
Цель этой заметки - показать, что в VMware vSphere при работе со снапшотами все сделали несколько лучше, чем в предыдущей версии. Во-первых, смотрим это видео:
Мысль видео такова: если у вас некорректно завершилась операция по консолидации снапшотов, то в VMware vSphere 5 вам предлагается опция по консолидации, доступная из контекстного меню виртуальной машины:
То есть, теперь не надо терзать командную строку в случае появления проблем со снапшотами виртуальных машин.
Во-вторых, появилась опция по поиску виртуальных машин, нуждающихся в консолидации снапшотов, доступная из vSphere Client. Чтобы найти такие машины, нужно выбрать хост или кластер, перейти на вкладку "Virtual Machines" и по правой кнопке выбрать пункт "Needs Consolidation":
Ну и, в-третьих, в vSphere 5 полностью поддерживается "горячее" перемещение виртуальных машин между хранилищами средствами Storage vMotion, а также, само собой, между хостами средствами обычного vMotion.
Часто пользователи виртуальной инфраструктуры VMware vSphere задают вопрос: а зачем нам нужны дополнительные средства обеспечения безопасности, такие как vGate R2, если у VMware vSphere и так есть сертификат ФСТЭК?
Ответы на этот вопрос с точки зрения необходимых средств защиты мы уже давали тут, тут и тут. Кто-то еще спрашивает: а зачем нам vGate R2, если есть такая штука как VMware vShield? И на этот вопрос мы уже отвечали вот здесь.
А вот как обстоят дела с точки зрения соответствия законодательству? Можно просто взглянуть вот на эту таблицу:
VMware vSphere 4
vGate R2
vGate-S R
Защита персональных данных
К1
Нет (1)
Да
Да
К2
Да
Да
Да
K3
Да
Да
Да
Применение в информационных системах государственного сектора
1Г
Нет (2)
Да
Да
1В
Нет
Нет
Да
1Б
Нет
Нет
Да
Используемые платформы
Только vSphere 4.0 Update 1 (3)
Virtual Infrastructure 3.5 \ vSphere 4
Virtual Infrastructure 3.5 \ vSphere 4
Комментарии к таблице
Таким образом, компаниям надо внимательно отнестись к уровню сертификации vSphere и учитывать, что:
У vSphere нет сертификата по НДВ. Согласно п.2.12 Приказа ФСТЭК России от 5.02.2010 N 58 зарегистрирован в Минюсте России 19.02.2010 № 16456 требуется наличие сертификата НДВ 4 в K1, а так же по решению оператора - в K2 и K3.
У vSphere нет сертификата по НДВ. Согласно п.1.5 РД "Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей" для применения в этих сетях дополнительно требуется наличие сертификата НДВ4.
Обновления общесистемного программного обеспечения тоже должны быть сертифицированы. Использование дополнительных СЗИ позволяет устанавливать все обновления, не заботясь об этом. Любое программное обеспечение имеет ошибки, которые нужно периодически исправлять. Любое программное обеспечение постоянно совершенствуется с целью улучшения его потребительских свойств. В результате исправлений исходного кода периодически выходят пакеты обновлений. Обновления общесистемного программного обеспечения должны быть сертифицированы. Если изменения незначительны, можно провести сертификацию только изменений по упрощенной процедуре – процедуре инспекционного контроля. Если изменения исходного кода превышают 10% всего кода, то необходимо проводить полную пересертификацию продукта. Сертификация операционной системы либо аналогичного по размеру исходного кода, общесистемного программного обеспечения занимает от полугода. Инспекционный контроль может быть проведен за пару месяцев. Использование дополнительных СЗИ позволяет устанавливать все обновления на общесистемное программное обеспечение без риска потери аттестации и задержек на сертификацию обновлений общесистемного программного обеспечения.
Таким образом, если в вашей организации серьезные требования к обеспечению информационной безопасности - то без vGate R2 вам просто не обойтись. Сейчас это единственный продукт на рынке, выполняющий все требования законодательства (о защите персональных данных в среде VMware vSphere с помощью vGate вы можете прочитать тут).
Пробную версию vGate R2 можно запросить по этой ссылке.
На сайте проекта VMware Labs, где в последнее время часто появляются полезные утилиты от сотрудников VMware, опубликована новая штучка - VMware I/O Analyzer, виртуальный модуль (Virtual Appliance) для анализа статистики по вводу-выводу.
Данное ПО включает в себя стандартные средства для измерения производительности систем хранения VMware vSphere, которые позволят выявить проблемы и узкие места в инфраструктуре хранилищ.
Ключевые возможности VMware I/O Analyzer:
Интегрированный фрейворк для тестирования хранилищ
Готовый к развертыванию виртуальный модуль
Прост в настройке и возможность исполнения тестов на нескольких хостах ESX/ESXi
Возможность просмотра результатов производительности как на уровне хоста, так и на уровне гостевой ОС
Возможность экспорта данных для последующего анализа
Скачать VMware I/O Analyzer можно по этой ссылке. Инструкция по развертыванию доступна тут.
Михаил Козлов, бывший директор VMware Россия, прислал интересную презентацию "Как заработать в облаке? FAQ для реселлеров и интеграторов", объясняющую суть бизнеса в сфере облачных инфраструктур, которую я рад представить вашему вниманию:
Очень хороший бизнес-обзор и весьма наглядные примеры.
Как вы знаете, в VMware vSphere 5 версия файловой системы VMFS была продвинута до 5. Это дает множество преимуществ по сравнению с VMFS 3, в частности, возможность создания хранилищ виртуальных машин (Datastore) размером до 64 ТБ без необходимости создания экстентов.
Это стало возможным благодаря использованию GPT-разделов (GUID Partition Table) вместо MBR-разделов (Master Boot Record). При этом, существует ошибочное мнение, что для томов VMFS 3, обновляемых на VMFS 5, ограничения старой версии в 2 ТБ на файловую систему Datastore остаются. Это не так - VMFS 5.0 при обновлении на нее с третьей версии действительно сохраняет формат MBR, однако после расширения тома более 2 ТБ происходит автоматическая конвертация MBR в GPT-диск.
То есть, происходит это так. У нас есть том VMFS 3, мы нажимаем ссылку "Upgrade to VMFS 5":
После прохождения мастера обновления, видим что тип тома - VMFS 5:
Однако здесь также видно, что том VMFS (теперь уже 5-й версии) остался размеров в 2 ТБ, несмотря на то, что LUN может быть более 2 ТБ. Кроме того, том остался MBR-форматированным, а размеры блоков VMFS 3 для него остались неизменными (см. KB 1003565). Надо отметить, что вновь создаваемые тома VMFS 5 всегда создаются с унифицированным размером блока - 1 МБ.
Чтобы расширить том VMFS, вызываем мастер "Increase Datastore Capacity":
Расширяем том, например до 3 ТБ:
Обратите внимание, что VMFS 5 не дает нам увеличения размера файла (vmdk) по сравнению с предыдущей версией - максимум по прежнему 2 ТБ, просто теперь том может быть размером до 64 ТБ без экстентов.
Запустим fdisk, посмотрим свойства расширенного тома и увидим, что он теперь GPT-том:
Далее операции с таким диском производятся с помощью утилиты partedUtil, но это уже другая история.
Многие пользователи VMware vSphere не пользуются средством автоматизированного обновления хост-серверов VMware Update Manager по тем или иным причинам. Кроме того, пользователи бесплатного VMware ESXi 5 хотели бы обновлять свои хост-серверы, потому как даже эта бесплатная платформа используется в компаниях в производственной среде. Если раньше можно было обновлять хосты ESX/ESXi 4 прямо из vCLI (vihostupdate), то теперь патч нужно загрузить на хранилище (Datastore).
Ниже представлен способ обновления VMware ESXi 5 без VMware Update Manager:
1. Загрузите нужный патч для VMware ESXi 5 с VMware Patch Portal в формате zip-файла.
2. Убедитесь, что на хосте включен доступ по SSH, а также на нем нет запущенных виртуальных машин (или переведите его в Maintenance Mode).
3. Скопируйте патч ESXi 5 в один из Datastore'ов (общий или локальный) с помощью бесплатной утилиты FastSCP. Лучше использовать общее хранилище, чтобы с одного файла патча обновлять несколько хостов.
5. После этого начнется обновления хост-сервера VMware ESXi 5, по окончании которого его нужно будет перезагрузить.
Патч для ESXi можно накатить и через PowerCLI (но загрузить патч на Datastore все равно придется). Для этого можно использовать скрипт от Justin Guidroz.
Как вы знаете, с появлением VMware vSphere 5 появилось несколько новых возможностей платформы виртуализации и новых компонентов решения. Однако мы хотим сосредоточиться на том, какие компоненты больше не являются частью VMware vSphere 5.
Итак чего больше нет в vSphere 5:
Гипервизора ESX. Остался только ESXi. Все дальнейшие версии vSphere будут только на платформе ESXi.
Продукта VMware Converter Enterprise, поставлявшегося в виде плагина к vCenter. Читаем в Release Notes:
"VMware vSphere 4.1 and its subsequent update and patch releases are the last releases for the VMware vCenter Converter plug-in for vSphere Client. VMware will continue to update and support the free Converter Standalone product, which enables conversions from sources such as physical machines, VMware and Microsoft virtual machine formats, and certain third-party disk image formats."
То есть больше нет вот этого пункта меню в vSphere Client:
Обновления гостевых ОС через VMware Update Manager. Ранее гостевые ОС можно было обновлять средствами VUM через репозитории Shavlik, компании, которая не так давно была куплена компанией VMware. Теперь возможность обновления гостевых ОС есть в двух продуктах: VMware vCenter Protect Essentials и VMware vCenter Configuration Manager, приобретаемых отдельно от vSphere 5.
Компонента Guided Consolidation, позволявшего провести базовое исследование по миграции физических серверов в виртуальную среду VMware vSphere. Теперь вы можете использовать только VMware Capacity Planner, доступный со стороны партнеров VMware.
VMware Consolidated Backup теперь полностью исключен из списка поддерживаемых продуктов (для четвертой версии vSphere поддержка еще существовала). Вместо него используется vStorage API for Data Protection, используемый, например, в Veeam Backup and Replication 6.
Также нужно отметить, что несмотря на то, что VMware ESXi и VMware vCenter - полностью 64-битные продукты, некоторые компоненты, а именно: VMware Update Manager 5.0, View Composer (из поставки VIew), vSphere Client - по-прежнему 32-битные приложения.
С приходом виртуализации в компании сервис-провайдеров повысился спрос на услуги аренды виртуальных машин (см. нашу статью о программе VMware VSPP). При этом в такой модели предоставления услуг, для пользователей очень важна защита арендуемых виртуальных сервисов и своих данных. Если подумать, то главной угрозой тут являются вовсе не внешние угрозы, поскольку ЦОДы сервис-провайдеров обычно хорошо защищены от них, а угрозы внутренние - ведь администратор VMware vSphere имеет доступ к виртуальным машинам различных организаций, а значит и ко всем файлам пользователей, в которых могут содержаться конфиденциальные данные (можно просто примонтировать vmdk-диск и скопировать их).
Вот тут и нужно обратить внимание на средство номер 1 для защиты виртуальных инфраструктур VMware vSphere - продукт vGate R2, который специализируется не только на задачах защиты от несанкционированного доступа и автоматической настройки среды в соответствии с требованиями законодательства, но и на разделении прав доступа самих администраторов (в данном случае - облачных).
Используя vGate R2, можно настроить инфраструктуру vSphere так, чтобы действия администраторов надежно протоколировались, а сами администраторы имели четкий набор привилегий и возможных действий, контролируемых и утверждаемых со стороны службы ИБ. Так что, если вы подумываете о том, не начать ли сдавать в аренду виртуальные машины, самое время прочитать про защиту облачных сред в документе "Обеспечение информационной безопасности
данных клиентов с помощью решения vGate при
предоставлении услуг облачных ЦОДов" от компании Код Безопасности:
Мы уже писали об утилите Login Virtual Session Indexer, которая позволяет измерять производительность виртуальных ПК (или терминальных сессий) в окружениях VDI. На днях вышла новая версия Login Virtual Session Indexer 3.5. Версия продукта Express Edition - бесплатна.
Новые возможности Login Virtual Session Indexer 3.5
Zero Footprint Launcher - теперь агентов можно запускать с любой файловой шары, без инсталляции
Pre/Post actions - действия до тестирования и после
Интерфейс Command Line для полной автоматизации тестирования
Возможность прерывания теста
Автоматический перезапуск зависших тестов
Шифрование логов
Улучшения в механизме генерации нагрузки
Поддержка счетчиков RemoteFX Host Performance (GPU, ошибки протокола и производительность ВМ и гипервизора)
Улучшения анализатора в плане интерфейса
Скачать Login Virtual Session Indexer 3.5 можно по этой ссылке (требуется регистрация).
На сайте проекта VMware Labs, где публикуются результаты внутренних разработок VMware (т.е. утилиты, которые факультативно разрабатываются сотрудниками компании) появилась новая утилита ESX System Analyzer.
ESX System Analyzer - это утилита, поставляемая в виде готового виртуального модуля (Virtual Appliance), которая позволяет пользователям спланировать миграцию хост-серверов ESX на платформу ESXi. Она анализирует серверы ESX в виртуальной инфраструктуре и собирает для каждого хоста информацию, которую необходимо учитывать в процессе миграции:
Аппаратную совместимость серверов с ESXi
Виртуальные машины, зарегистрированные на хосте ESX, а также ВМ, которые находятся на локальных дисках
Отличия настроек компонента Service Console от стандартных:
RPM-пакеты, которые были добавлены или удалены
Файлы в сервисной консоли, которые добавляли пользователи
Добавленные пользователи и задачи cron
Утилита ESX System Analyzer также собирает информацию о виртуальном окружении:
Версии VMware Tools и Virtual Hardware для всех виртуальных машин
Версии файловых систем для томов VMFS
На базе этой информации администраторы могут определить задачи, которые следует выполнить перед миграцией. Например:
Переместить ВМ с локальных дисков на общие хранилища
Понять, как можно заменить агентов в сервисной консоли на их безагентные альтернативы или CIM-агенты
Заменить задачи cron удаленными скриптами PowerCLI или vCLI
Системные требования к ВМ, содержащей ESX System Analyzer (работа с утилитой производится через веб-интерфейс):
20GB virtual disk
512MB virtual memory
1 vCPU
vCenter Server 2.5, 4.0, 4.1, 5.0
ESX Hosts 3.5, 4.0, 4.1
Административный доступ к vCenter Server
Root password для анализируемых ESX
Включенный доступ Root по SSH на всех хостах
Скачать ESX System Analyzer можно по этой ссылке. Инструкция по работе с продуктом - тут.
Мы уже писали о решении EMC VPLEX, которое позволяет организовать катастрофоустойчивую архитектуру хранилищ для виртуальных машин за счет организации синхронного распределенного виртуального тома (Disrtibuted Virtual Volume).
Семейство продуктов EMC VPLEX с операционной системой EMC GeoSynchrony является решением по объединению на основе сети SAN. Технология EMC VPLEX Metro позволяет объединить дисковые ресурсы массивов, находящихся на двух географически разделенных площадках в единый пул хранения. Со стороны серверов ESX / ESXi на обеих площадках доступен один виртуальный логический том, который обладает свойством катастрофоустойчивости, поскольку данные физически хранятся и синхронизируются на обеих площадках.
Данная технология интегрирована с технологией отказоустойчивости VMware HA за счет поддержки структуры vSphere Metro Storage Cluster, что позволяет использовать их совместно для обработки различных вариантов сбоев в виртуальной инфраструктуре. К тому же, EMC VPLEX - это единственное сертифицированное VMware решение для организации географически "растянутых" кластеров VMware HA.
В географически разнесенных ЦОД, хранилища которых синхронизированы с помощью VPLEX, есть важная проблема – является ли нарушение связи между узлами кластеров VPLEX следствием сбоя сети или сбоя на площадке. Она затрагивает и кластеры VPLEX, которые находятся в различных географических точках. Система EMC VPLEX обрабатывает сбой сети путем автоматического прекращения всех операций ввода-вывода в устройстве («отключение») на одной из двух площадок в зависимости от набора преопределенных правил. Операции ввода-вывода в то же устройство на другой площадке продолжают выполняться в обычном режиме. Поскольку правила применяются к каждому устройству в отдельности, в случае разделения сети активные устройства могут присутствовать на обеих площадках. Для предотвращения этого используется Cluster Witness - компонент на сторонней площадке, отвечающий за мониторинг доступности основной и резервной площадки.
При отказе различных компонентов ИТ-инфраструктуры и каналов связи могут возникнуть различные ситуации как для кластера VPLEX, так и для кластера VMware HA, которые успешно обрабатываются и теоретически весьма мало ситуаций, которые могут привести к потере данных. Однако есть ситуации (и они всегда будут в распределенных ЦОД - именно потому RTO=0 это Objective, а не Requirement), когда нельзя автоматизировать операции по восстановлению и требуется вмешательство администратора, который выполнит наиболее правильное действие.
Вот как VPLEX совместно с HA обрабатывают различные варианты сбоев:
Сценарий
Поведение VPLEX
Влияние на кластер VMware HA
Отказ одного из путей порта
VPLEX back-end
(BE) к дисковому массиву.
VPLEX прозрачно переключится на альтернативный путь, без влияния на работу распределенных виртуальных томов (Distributed Virtual Volumes).
Отсутствует.
Отказ одного из путей к порту VPLEX front-end
(FE) от хост-сервера.
Сервер ESXi за счет встроенного механизма работы по нескольким путям переключится на резервный путь к распределенным виртуальным томам.
Отсутствует.
Выход из строя массива
на основной площадке.
VPLEX продолжит обслуживать виртуальные тома, используя дисковый массив резервной площадки. Когда основной дисковый массив восстановится после сбоя, тома основного дискового массива будут автоматически синхронизированы с резервного.
Отсутствует.
Выход из строя массива на резервной площадке.
VPLEX продолжит обслуживать виртуальные тома, используя дисковый массив основной площадки. Когда резервный дисковый массив восстановится после сбоя, тома резервного дискового массива будут автоматически синхронизированы с основного.
Отсутствует.
Выход из строя одного из устройств VPLEX Director.
VPLEX продолжит обслуживать виртуальные тома, перенаправив запросы на другие директоры кластера VPLEX.
Отсутствует.
Полная потеря основной площадки (катастрофа), включая все хосты ESXi и компоненты кластера VPLEX (обнаруживается с помощью Cluster Witness).
VPLEX продолжит обслуживать запросы ввода-вывода на дисковом массиве резервной площадки. Когда основная площадка восстановится, виртуальные тома будут синхронизированы с резервной площадки.
Виртуальные машины основной площадки будут перезапущены на хостах резервной площадки.
Полная потеря резервной площадки (катастрофа), включая все хосты ESXi и компоненты кластера VPLEX (обнаруживается с помощью Cluster Witness).
VPLEX продолжит обслуживать запросы ввода-вывода на дисковом массиве основной площадки. Когда резервная площадка восстановится, виртуальные тома будут синхронизированы с основной площадки.
Виртуальные машины резервной площадки будут перезапущены на хостах основной площадки.
Множественный выход из строя хост-серверов в рамках одной из площадок.
Отсутствует
Механизм VMware HA перезапустит виртуальные машины на оставшихся хостах кластера HA.
Выход из строя сети сигналов доступности в рамках одной из площадок.
Отсутствует.
HA продолжит обмен сигналами доступности через общие хранилища (см. тут), что не повлечет за собой аварийного восстановления.
Все пути к хосту ESXi находятся в состоянии APD (All Paths down) – т.е. временно отсутствует доступ к хранилищам (виртуальным томам).
Отсутствует.
В этом случае необходимо перезапустить сервер ESXi, что приведет к перезапуску виртуальных машин в кластере HA на других хост-серверах кластера HA.
Разрыв канала репликации между устройствами VPLEX при сохранении сети управления.
На резервной площадке VPLEX переводит виртуальные тома в режим I/O Failure (что запрещает работу с ними). На основной площадке виртуальные тома продолжают оставаться доступными виртуальным машинам.
На основной площадке виртуальные машины продолжают функционировать. На резервной площадке виртуальные машины получают ошибку ввода-вывода и выключаются. Механизм VMware HA (VM Monitoring) восстанавливает их на резервной площадке.
Сбой кластера VPLEX (компоненты кластера на обеих площадках недоступны, но хосты ESXi не испытывают проблем работы по SAN и СПД).
Запросы ввода-вывода для всех виртуальных томов продолжат обслуживаться на основной площадке.
Хосты ESXi на резервной площадке перейдут в состояние APD. Это потребует их перезагрузки для восстановления виртуальных машин.
Одновременный полный выход из строя обеих площадок.
После восстановления площадок VPLEX продолжит обслуживать запросы ввода-вывода (в первую очередь следует запустить дисковые массивы на обеих площадках).
Хосты ESXi должны быть включены только после того, как компоненты VPLEX будут восстановлены, а виртуальные тома синхронизированы. При включении хостов ESXi виртуальные машины будут восстановлены механизмом VMware HA.
Выход из строя одного из директоров VPLEX на одной из площадок, а также выход дискового массива на противоположной площадке (резервная площадка для виртуального тома).
Оставшиеся директоры кластера VPLEX продолжат обслуживать доступ к виртуальным томам, используя дисковый массив, являющийся для них основным.
Отсутствует
Разрыв сети сигналов доступности (heartbeat) на одной из площадок и разрыв коммуникаций VPLEX между площадками (отличие от выхода из строя площадки понимает Cluster Witness).
VPLEX прекращает обслуживать запросы ввода-вывода для виртуальных томов, у которых дисковые массивы помечены как резервные. Обмен продолжится только с дисковыми массивами, являющимися основными для виртуальных томов.
На основной площадке виртуальные машины продолжат исполняться. Для VMware HA – это ситуация «split-brain» (хосты резервной площадки считают себя оставшимися работоспособными в кластере и пытаются включить виртуальные машины). При включении ВМ на хостах резервной площадки будет получена ошибка ввода-вывода. В этой ситуации необходимо вручную перерегистрировать виртуальные машины резервной площадки на основной.
Том VPLEX оказывается недоступен (например, случайно удален из консоли управления).
VPLEX продолжит обслуживать запросы ввода-вывода с резервной площадки, где том доступен.
Все хосты ESXi работающие с томом VPLEX получают ошибку ввода-вывода и переходят в состояние PDL (Permanent Device Loss). В результате компонент VM Monitoring останавливает виртуальные машины, после чего они запускаются на хостах другой площадки.
Разрыв соединения между компонентами VPLEX на обеих площадках и одновременных выход из строя соединения VPLEX Cluster Witness к основной площадке.
VPLEX прекращает обслуживать запросы ввода-вывода к виртуальным томам на резервной площадке и продолжает работу с томами основной площадки.
Виртуальные машины на резервной площадке завершат работу по ошибке ввода-вывода, они могут быть вручную зарегистрированы и запущены на резервной площадке.
Разрыв соединения между компонентами VPLEX на обеих площадках и одновременных выход из строя соединения VPLEX Cluster Witness к основной площадке.
VPLEX прекращает обслуживать запросы ввода-вывода к виртуальным томам на основной площадке и продолжает работу с томами резервной площадки.
Виртуальные машины на основной площадке завершат работу по ошибке ввода-вывода, они могут быть вручную зарегистрированы и запущены на резервной площадке.
Сбой компонента VPLEX Cluster Witness.
VPLEX продолжает обслуживать запросы ввода-вывода на обеих площадках.
Отсутствует.
Сбой компонента VPLEX Management Server на одной из площадок.
Отсутствует.
Отсутствует.
Отказ сервера управления виртуальной инфраструктурой VMware vCenter
Отсутствует.
На механизм VMware HA и восстановления виртуальных машин это не повлияет. Однако правила размещения и балансировки виртуальных машин по хост-серверам прекратят работать.
Как видите, все ситуации обрабатываются разумно и корректно. Тут обязательным должно быть наличие VPLEX Cluster Witness, который отличит выход из строя линков между ЦОД от выхода из строя одного из ЦОД, о чем он скажет им обоим.
Также надо отметить, что полной автоматизации восстановления тут нельзя добиться, как говорится, "by design".
Deduplication - плагин для дедупликации хранилищ был переработан и теперь поддерживает журналирование данных. Также добавлена поддержка снапшотов для механизма дедупликации.
Новая версия плагина, обеспечивающего высокую доступность хранилищ (см. ниже).
В качестве отказоустойчивых хранилищ могут быть использованы файлы типа raw image.
iSCSI-трафик, идущий по каналу синхронизации между узлами StarWind HA теперь передается более быстро и надежно за счет замены транспорта MS iSCSI на собственный от StarWind (разработчики утверждают, что в MS iSCSI много багов, которые остались еще с 2006 года, что влияет на надежность решения).
Канал сигналов доступности (Heartbeat channel) теперь является обязательной конфигурацией для решения (во избежания несогласованности данных). Можно использовать для него публичную сеть - по нему не проходит много трафика.
Возможность "Switch partner" - для существующего узла StarWind HA может быть переназначен новый узел (помните, что требуется обновить пути доступа к хранилищам в ESX и Hyper-V).
Автоматическая синхронизация узлов после одновременного выключения двух узлов (например, отключение электричества). Если одно из дисковых устройств имеет более актуальные данные, то они будут автоматически синхронизированы на другой узел. Если вы используете методику кэширования write-back и хотя бы один из узлов был выключен некорректно (hard power off, например) - то автоматической синхронизации не произойдет, и будут ожидаться действия пользователя.
RAM disk - алгоритм генерации серийного номера был изменен для соблюдения его уникальности в пределах сети.
SPTI - параметр выравнивания буфера используется при проверки свойств устройства во время инициализации сервиса.
Скачать бета-версию StarWind Enterprise HA 5.8 можно по этой ссылке (без регистрации).