Решение номер 1 - StarWind iSCSI SAN - для создания отказоустойчивых хранищ под виртуальные машины серверов VMware ESXi и Microsoft Hyper-V снова в продаже со скидками, которые уменьшаются каждый день. Торопитесь!
Календарь скидок в процентах при заказе в первых двух неделях марта:
Как вы знаете, в VMware vSphere 5 есть возможность динамической миграции хранилищ виртуальных машин - Storage vMotion. Эта возможность позволяет не только без простоя перенести виртуальные машины между хранилищами и их LUN, но и изменять формат результирующего виртуального диска (thin или thick).
В этой заметке мы рассмотрим один из интересных аспектов миграции Storage vMotion - перенесение томов RDM (Raw Device Mapping) виртуальных машин, работающих в режиме виртуальной и физической совместимости (physical and virtual RDMs).
Также перенос хранилища виртуальной машины мы можем сделать не только в "горячем" режиме, но и в "холодном" с помощью функции Cold Migration (для выключенной ВМ). В этом случае мы также можем выбрать формат виртуального диска результирующей ВМ. Давайте посмотрим как эти условия влияют на перенос RDM томов во всех случаях.
Перенос включенных ВМ с физическим RDM (pRDM) средствами Storage vMotion:
Если вы пытаетесь изменить формат результирующего диска - Storage vMotion будет сделать нельзя.
Если вы не пытаетесь изменить формат - будет перемещен маппинг-файл pRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос включенных ВМ с виртуальным RDM (vRDM) средствами Storage vMotion:
Если вы изменяете формат результирующего диска (в advanced view) - том vRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл vRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос выключенных ВМ с физическим RDM (pRDM) средствами Cold Migration:
Если вы изменяете формат результирующего диска (в advanced view) - том pRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл pRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос выключенных ВМ с виртуальным RDM (vRDM) средствами Cold Migration:
Если вы изменяете формат результирующего диска (в advanced view) - том vRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл vRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Таким образом, у нас получается 3 ситуации, когда исходный RDM-том конвертируется в VMDK-диск на целевом томе, при этом в мастере миграции вас никто об этом не предупреждает.
Также есть еще один аспект при миграции таких томов. Если исходный RDM-том находился в режиме Independent Persistent (а pRDM обязательно в этом режиме находится), то, как следует из свойств этого диска, он не участвует в создании снапшотов ВМ.
После миграции, если он будет сконвертирован в vmdk-файл, то он также останется в этом режиме:
А это значит софт для резервного копирования виртуальных машин не будет бэкапить такой диск, поскольку он не участвует в создании снапшота. Учитывайте этот момент.
Продолжаем втягивать вас в процесс ознакомления с решением номер 1 StarWind Enterprise iSCSI для создания отказоустойчивых хранилищ виртуальных машин Microsoft Hyper-V и VMware vSphere. На этот раз несколько новостей о продукте StarWind Native SAN for Hyper-V (с резервным копированием StarWind Hyper-V backup Plug-in), который позволяет используя всего 2 сервера, сделать кластер из серверов Hyper-V и сделать хранилища прямо на этих серверах, которые продолжат непрерывно работать в случае отказа любого из них.
Во-первых, приходите сегодня на вебинар Толи Вильчинского, который быстро и четко говорит по-английски, но (наверняка) сможет ответить на ваши вопросы по-русски:
Компания StarWind, выпускающая продукт номер 1 StarWind iSCSI Target для создания отказоустойчивой инфраструктуры хранилищ для виртуальных машин vSphere и Hyper-V, продолжает информировать вас о своем новом продукте для резервного копирования виртуальных машин StarWind Hyper-V backup Plug-in, который поставляется как плагин к основному решению.
Напоминаю, что StarWind Hyper-V backup Plug-in это:
Безагентная Архитектура
Резервные копии, сохраняемые в «родном» для Hyper-V VHD-формате
Глобальная Дедупликация
Операция резервного копирования в один клик
Обращаю также внимание, что мероприятие пройдет 9 февраля в 17-00 по москве, то есть послезавтра - поэтому не задерживайтесь и приходите вовремя. Подробнее о плагине StarWind Hyper-V backup Plug-in для резервного копирования виртуальных машин Hyper-V и ESX/ESXi можно почитать в нашей заметке.
Как раз в тему - у StarWind до 15 февраля есть возможность приобрести плагин для резервного копирования ВМ Hyper-V на 15% дешевле от будущей цены. Покупайте сейчас, чтобы через 2 недели не платить больше.
Плагин Hyper-V Backup Plug-in включает в себя:
Безагентную архитектуру
Дедупликацию хранимых резервных копий
Хранение бэкапов в формате VHD
Резервное копирование в один клик
Тестирование резервных копий на целостность
Подробнее о продукте Hyper-V Backup Plug-in можно узнать тут и тут, а оформить заявку можно на сайте StarWind по этой ссылке.
Мы уже писали о том, что в новом продукте StarWind Native SAN for Hyper-V для создания отказоустойчивых хранилищ Hyper-V с использованием всего 2-х серверов присутствует возможность резервного копирования виртуальных машин под названием VM Backup. Давайте заглянем немного в процесс резервного копирования StarWind Native SAN. В плане работы с плагином VM Backup сначала появляются следующие задачи:
Более-менее стали оформляться подробности о новой файловой системе ReFS (Resilient File System), которую компания Microsoft планируют ввести в новых версиях Windows 8 (серверной и клиентской). Первоначально ReFS будет включена в состав серверной версии нового семейства ОС, а только затем в десктопную версию и далее появится возможность использования ее для загрузочных разделов (цикл внедрения аналогичен NTFS, который применялся в свое время).
Основная идея ReFS - дополнительные функции отказоустойчивости, которые будут обеспечиваться средствами "эластичной" обработки программных и аппаратных ошибок.
Что касается изменений ReFS по отношению к максимумам NTFS - их почти нет (за исключением удвоения максимального количества файлов в каталоге и увеличения размера тома):
Самый потенциально неприятный момент - в ReFS нельзя будет конвертировать существующие тома NTFS, поэтому данные придется переносить простым копированием.
Кроме того, в Windows 8 Server система ReFS в перспективе будет обеспечивать функции виртуализации хранилищ (пространства хранения - storage spaces).
Первоначально планируется, что Storage Spaces будут работать для томов NTFS, позволяя гибко агрегировать физические дисковые носители в пулы ("пространства"), которые организованы с помощью техник зеркалирования и контроля четности (mirror - частое обновление, например, документы и parity - частое чтение, редкое обновление, например, фотки и видео). При этом утверждают, что это не обычные RAID-тома (но диски в пространствах по отдельности читаться не будут). Пространства будут также поддерживать технику Thin provisioning, которая позволит создавать их размером, например, в 10 ТБ, при этом "под ними" может быть гораздо меньше сырой емкости:
То есть, при нехватке физического пространства будет выдаваться предупреждение о том, что необходимо добавить еще сырой емкости в пул.
В целом и ReFS, и пространства хранения - какие-то не очень нужные, как кажется, вещи. Пространства хранения выглядят просто как приучение пользователя к созданию избыточных хранилищ данных. Больше деталей обещают к концу февраля, поскольку на это время намечен выход бета-версии клиентской Windows 8. Окончательный же выход новой платформы ожидается к концу года (серверной и клиентской).
Многие из вас уже читали о новой версии StarWind Enterprise 5.8 для организации отказоустойчивых ISCSI-хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V. Одна из интересных фич новой версии - возможность резервного копирования хранилищ виртуальных машин, идущая как плагин к продукту (VM Backup). Бэкап работает как для vSphere, так и для Hyper-V (с поддержкой дедупликации).
В связи в этим обновилось сравнение изданий продукта для платформ VMware и Microsoft.
Издания StarWind iSCSI SAN (для серверов ESX / ESXi):
Возможности
StarWind
Enterprise CDP Edition
StarWind iSCSI SAN
1TB
2TB
4TB
8TB
16TB
Unlimited
Support
1 year
1 year
1 year
1 year
1 year
1 year
1 year
# of Servers per license
1
2
2
2
2
4
(2 HA sets)
4
(2 HA sets)
Maximum Capacity
Unlimited
1TB
2TB
4TB
8TB
16TB
Unlimited
# of Concurrent iSCSI Connections
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Ethernet ports
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Served Disk Drives
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Synchronous Mirroring (Active-Active High Availability)
Remote Replication (Active-Passive)
Automatic Failover
Failback with Fast Synchronization
Disk Bridge
SPTI
Image File
IPSec, CHAP, ACL, iSNS
CDP / Snapshots
Thin Provisioning
High Speed Caching
Event Log
Event notifications
Deduplication
*VM Backup Option
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
Издания StarWind Native SAN for Hyper-V:
Возможности
StarWind Native SAN for Hyper-V
1TB
2TB
4TB
8TB
16TB
Unlimited
Support
1 year
1 year
1 year
1 year
1 year
1 year
# of Servers per license
2
2
2
2
2
2
Maximum Capacity
1TB
2TB
4TB
8TB
16TB
Unlimited
# of Concurrent iSCSI Connections
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Ethernet ports
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Served Disk Drives
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Synchronous Mirroring (Active-Active High Availability)
Remote Replication (Active-Passive)
Automatic Failover
Failback with Fast Synchronization
Disk Bridge
SPTI
Image File
IPSec, CHAP, ACL, iSNS
CDP / Snapshots
Thin Provisioning
High Speed Caching
Event Log
Event notifications
Deduplication
*VM Backup Option
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
Стоимость VM Backup Option указана за физический сервер ESX или Hyper-V, виртуальные машины которого вы планируете бэкапить. При этом неважно количество процессоров и ВМ на данном сервере.
Как мы недавно писали, новая версия продукта номер 1 для создания iSCSI-хранилищ виртуальных машин vSphere и Hyper-V - StarWind Enterprise 5.8 уже доступна для загрузки. Одна из самых полезных новых возможностей версии StarWind 5.8 для Hyper-V - это функция VM Backup, предназначенная для резервного копирования виртуальных машин.
На сайте steelbytes.com недавно обновилась бесплатная утилита HD_Speed, которая позволит вам протестировать производительность дисков в виртуальных машинах VMware vSphere или на других платформах.
Утилита выводит статистику скорости обмена в реальном времени не только для виртуальных дисков, но и любых других устройств - hard disks, cd/dvd-roms, flash cards/sticks, floppys и т.д. Поддерживаемые режимы - чтение, запись, чтение-запись, чтение-запись-проверка (можно задавать размер блока). С режимом записи осторожнее - можно уничтожить данные на диске. Также возможно тестирование пиковой пропускной способности устройства.
Результаты можно писать в лог-файл. Что приятно - присутствует интерфейс на русском языке.
* Внимание! Цены указаны по курсу доллара ЦБ РФ на 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 можно почитать тут и тут, соответственно. О том, для чего нужен продукт - читайте здесь.
Таги: StarWind, Enterprise, VMC, HA, Storage, iSCSI
Помните, мы писали, что снапшоты виртуальных машин в VMware vSphere - это плохо? Но иногда без них не обойтись - например, системы резервного копирования (например, Veeam Backup and Replication) вынуждены делать снапшоты, чтобы не прерывать работу виртуальной машины во время бэкапа.
Цель этой заметки - показать, что в VMware vSphere при работе со снапшотами все сделали несколько лучше, чем в предыдущей версии. Во-первых, смотрим это видео:
Мысль видео такова: если у вас некорректно завершилась операция по консолидации снапшотов, то в VMware vSphere 5 вам предлагается опция по консолидации, доступная из контекстного меню виртуальной машины:
То есть, теперь не надо терзать командную строку в случае появления проблем со снапшотами виртуальных машин.
Во-вторых, появилась опция по поиску виртуальных машин, нуждающихся в консолидации снапшотов, доступная из vSphere Client. Чтобы найти такие машины, нужно выбрать хост или кластер, перейти на вкладку "Virtual Machines" и по правой кнопке выбрать пункт "Needs Consolidation":
Ну и, в-третьих, в vSphere 5 полностью поддерживается "горячее" перемещение виртуальных машин между хранилищами средствами Storage vMotion, а также, само собой, между хостами средствами обычного vMotion.
На сайте проекта VMware Labs, где в последнее время часто появляются полезные утилиты от сотрудников VMware, опубликована новая штучка - VMware I/O Analyzer, виртуальный модуль (Virtual Appliance) для анализа статистики по вводу-выводу.
Данное ПО включает в себя стандартные средства для измерения производительности систем хранения VMware vSphere, которые позволят выявить проблемы и узкие места в инфраструктуре хранилищ.
Ключевые возможности VMware I/O Analyzer:
Интегрированный фрейворк для тестирования хранилищ
Готовый к развертыванию виртуальный модуль
Прост в настройке и возможность исполнения тестов на нескольких хостах ESX/ESXi
Возможность просмотра результатов производительности как на уровне хоста, так и на уровне гостевой ОС
Возможность экспорта данных для последующего анализа
Скачать VMware I/O Analyzer можно по этой ссылке. Инструкция по развертыванию доступна тут.
Как вы знаете, в 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, но это уже другая история.
Возвращаемся к проблеме тонких (thin) дисков VMware ESXi и уменьшения их размера после того, как они разрослись. Суть проблемы: когда вы используете тонкие диски для виртуальных машин - они постоянно растут, даже если вы удаляете в гостевой ОС. Это происходит потому, что ОС Windows (да и Linux) при удалении файлов не заполняет их блоки нулями, а просто помечает их удаленными в метаданных тома.
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 можно по этой ссылке (без регистрации).
Таги: StarWind, Enterprise, Update, HA, Storage, iSCSI, VMware, Microsoft
Многие из вас знают продукт номер 1 для резервного копирования виртуальных машин VMware vSphere - Veeam Backup and Replication. Мы уже много писали как о функциональности Veeam Backup and Replication 5, так и о новых возможностях, которые появляются в Veeam Backup and Replication 6. В среду, 30 ноября, должен состояться релиз новой версии продукта, поэтому постараемся в этой статье собрать все новые функции, улучшения и нововведения Veeam Backup and Replication 6 (обратите также внимание на повышение цен на продукт с 1 декабря).
Приведенная ниже информация основана на документе "Veeam Backup & Replication. What's new in v6", который вы можете почитать в оригинале для понимания всех аспектов новых возможностей этого средства для резервного копирования виртуальных машин.
Новые ключевые возможности и улучшения Veeam Backup and Replication 6:
Enterprise scalability: улучшенная архитектура продукта позволяет производить развертывание в удаленных офисах и филиалах, а также для больших инсталляций. Теперь появилось несколько backup proxy серверов для крупных окружений (data movers), которые могут распределять между собой нагрузку в процессе резервного копирования, а управляет процессом сервер Veeam Enterprise Manager. Виртуальные машины динамически назначаются proxy-серверам с учетом алгоритма балансировки нагрузки, что снижает затраты на администрирование инфраструктуры РК. Также увеличена производительность для резервного копирования, репликации и восстановления по WAN-каналам.
Advanced replication: в некоторых случаях скорость репликации выросла до 10 раз, а также появится Failback (обратное восстановление виртуальной машины после возобновления работы отказавшего хоста с ВМ) с возможностью синхронизации дельты (различия данных с момента отказа основной машины на основном сервере и хранилище - Failover). Кроме того, поддерживается репликация в thin provisined-диски на целевой сервер. Это сильная заявка на победу над VMware SRM 5 (в издании Standard) для небольших компаний, где серверов не много и нужно укладываться в небольшие бюджеты. Появилась также возможность создания реплик базового образа для окружений VMware View.
Multi-hypervisor support: полная поддержка Windows Server с ролью Hyper-V и Microsoft Hyper-V Server, а также возможность управления резервным копированием для гипервизоров разных производителей из одной консоли. Одна и та же инсталляция Veeam Backup позволит делать резервные копии и с VMware vSphere, и с Microsoft Hyper-V. При этом лицензирование также единое - один пул лицензий Veeam вы можете распределить между лицензиями на процессоры для хостов ESXi и Hyper-V. Кроме того, появилась поддержка методики Changed Block Tracking для Hyper-V для ускорения процесса инкрементального резервного копирования (отслеживание изменившихся блоков с момента последнего бэкапа).
1-Click File Restore - с помощью 1-Click File Restore можно зайти в Enterprise Manager, выбрать нужный файл и восстановить туда, откуда он был удален (это можно сделать также из результатов поиска файла по резервным копиям). При этом есть разделение ролей - есть тот, кто может файл восстановить (helpdesk), а есть тот, кто открыть. Данная возможность доступна только в Enterprise Edition.
Полный список новых возможностей:
Архитектура Veeam Backup and Replication 6
ESXi-centric processing engine - теперь архитектура продукта полностью опирается на архитектуру ESXi, но в поддержка гипервизора ESX остается в полной мере.
Backup proxy servers - один сервер Veeam Backup может контролировать несколько прокси-серверов, обеспечивающих передачу данных на целевые хранилища. Прокси-серверы не нуждаются в Microsoft SQL
Server и содержат минимальный набор компонентов.
Backup repositories - новая концепция репозиториев резервного копирования (в традиционном РК известная как медиа-серверы), которые хранят настройки задач резервного копирования и параметры целевых хранилищ. Задачи по РК виртуальных машин с помощью медиа-серверов динамически назначаются proxy-серверам с учетом алогоритма балансировки нагрузки.
Windows smart target - в дополнение к Linux target agent, который помогает при резервном копировании в удаленные хранилища, появился также агент для Windows. Этот агент на целевой машине позволяет производить эффективную компрессию и обновлять синтетические резервные копии.
Enhanced vPower scalability - теперь можно использовать несколько серверов vPower NFS. Теперь можно запускать еще больше ВМ напрямую из резервных копий (например, если у вас много ВМ с большими дисками это очень может помочь). Любой сервер РК Veeam или Windows backup repository может быть таким сервером.
Ядро продукта Veeam Backup and Replication 6
Optimization of source data retrieval - теперь учитываются параметры дисковых хранилищ при обращении к виртуальным машинам. Это позволяет до 4-х раз увеличить производительность для одной операции, в зависимости от настроек дискового массива.
Reduced CPU usage - теперь в два раза меньше нагрузка задач на процессор, что позволяет запустить больше задач РК или репликации на одном сервере Veeam Backup или прокси-сервере.
Traffic throttling - теперь доступны опции по регулированию полосы пропускания, которые производятся на базе пары source/target IP. Эти правила могут быть основаны на времени операций - время дня или день недели.
Multiple TCP/IP connections per job - теперь агенты Data Movers могут инициировать соединение по нескольким IP-адресам, что существенно увеличивает скорость резервного копирования. Особенно это эффективно для репликации по WAN-каналам.
WAN optimizations - протокол передачи данных Veeam Backup был существенно доработан в плане производительности для передачи данных по соединениям с большими задержками в канале.
Exclusion of swap files - блоки, относящиеся к файлам подкачки, теперь исключаются из передачи в резервную копию, что существенно увеличивает производительность.
Enforceable processing window - теперь для каждой задачи можно задавать окно РК или репликации (все задачи, не попадающие в это окно завершаются). Также вне рамок окна не разрешается применение снэпшотов, что не позволяет оказывать влияние на производительность ВМ в рабочие часы.
Parallel backup and replication - теперь задачи, относящиеся к одной и той же ВМ, могут быть выполнены параллельно. Например, вы можете запускать ежедневную задачу Full Backup параллельно с работающей задачей репликации.
Улучшения резервного копирования в Veeam Backup and Replication 6
Backup mapping - при создании новой задачи резервного копирования ВМ, ее можно присоединить к уже имеющейся задаче (например, в ней есть уже файлы этой ВМ). В этом случае Full Backup этой ВМ может не потребоваться.
Enhanced backup file format - новый формат метаданных позволяет осуществлять быстрый импорт резервных копий, а также закладывает основу для поддержки новой функциональности в следующих релизах продукта.
Backup file data alignment - данные ВМ, сохраненные в бэкап-файле, могут быть размещены в пределах блоков по 4 КБ. Это увеличивает производительность дедупликации как самого Veeam Backup, так и сторонних технологий дедупликации (например, средствами дискового массива).
Improved compatibility with deduplicating storage - теперь механизм РК оказывает меньшее влияние на предыдущие файлы резервной копии, что улучшает производительность массивов, которые осуществляют пост-процессинг хранимых данных.
Репликация Veeam Backup and Replication 6
New replication architecture - теперь репликация использует двухагентную архитектуру, которая позволяет собирать данные хранилищ ВМ на исходном DR-сайте одним прокси-сервером РК и посылать их напрямую к прокси-серверу резервной площадки (и наоборот), минуя главный сервер Veeam Backup. Поэтому теперь не разницы, где размещать последний.
Replica state protection - теперь инкрементальные задачи репликации больше не обновляют последнюю точку восстановления ВМ. Это позволяет при прерывании задачи не перестраивать последнюю точку восстановления до того, как следующая задача откатит ее к последнему согласованному состоянию, как в прошлых версиях. В версии 6 последняя точка восстановления всегда согласована и ВМ может быть запущена в любой момент.
Traffic compression - за счет новой архитектуры репликации теперь не важно где находится основной сервер РК Veeam, а трафик сжимается намного более эффективно. Кроме того, появились настройки уровня компрессии для передаваемого трафика, что позволяет уменьшить требования к полосе пропускания до 5 раз.
Hot Add replication - теперь прокси-сервер на целевой площадке представляет диски реплики, используя технологию Hot Add. Это уменьшает поток трафика до 4 раз.
1-click automated failback - позволяет произвести обратное восстановление (Failback) виртуальной машины после возобновления работы отказавшего хоста с ВМ с возможностью синхронизации только дельты с момента последнего отказа (Failover), т.е. различия данных с момента отказа основной машины на основном сервере и хранилище) . Перед завершением этого процесса можно проверить ВМ на работоспособность на основной площадке.
1-click permanent failover - возможность в один клик провести все необходимые процедуры по завершению процесса превращения резервной машины в основную, когда в случае отказа основной ВМ она переместилась на резервный сайт.
Active rollbacks - репликация теперь хранит точки восстановления как обычные снапшоты ВМ. Это позволяет откатиться в любую точку на резервной площадке, даже без участия Veeam Backup.
Improved replica seeding - улучшения механизма организации репликации. Теперь репликация использует обычные бэкап-файлы, это позволяет уменьшить размер передаваемых данных, поддерживаются ВМ с тонкими (thin) дисками и многое другое.
Replica mapping - теперь реплицируемую виртуальную машину можно привязать к уже существующей ВМ на резервной площадке (например, ранее для нее использовалась репликация или на резервную площадку ее восстановили из резервной копии). Это позволяет не передавать весь объем данных для создания реплицируемой пары.
Re-IP - теперь можно задать правила автоматического назначения IP-адреса для восстанавливаемой ВМ. Это очень полезно, когда требуется восстановить ВМ на резервную площадку, где действует другая схема IP-адресации, в случае сбоя основной.
Cluster target - задачи репликации теперь поддерживают указание определенного хоста или кластера как целевого для репликации. Это позволяет убедиться в том, что при восстановлении ВМ она окажется доступной (например, на резервной площадке).
Full support for DVS - полная поддержка распределенных коммутаторов VMware Distributed Virtual Switches технологией репликации, что позволяет передавать состояние реплики без дополнительных ручных операций (например, в окружениях с VMware vCloud Director).
Automatic job update - операции failover и failback автоматически обновляют задачу репликации путем исключения из нее ВМ и повторного добавления.
Multi-select operations - в консоли теперь можно выбрать несколько ВМ для операций с репликацией. Например, при массовом выходе из строя хостов можно провести операции failover сразу с несколькими ВМ (аналогично и для failback).
Enhanced job configuration - теперь мастер создания реплицируемой пары поддерживает возможность настройки репликации на уровне vmdk-дисков, а также предоставляет возможность настроить целевые объекты: resource pool, VM folder и virtual network, где будет размещаться реплика и восстанавливаться ВМ.
Миграция виртуальных машин в Veeam Backup and Replication 6
Quick Migration - эта технология позволяет организовать миграцию виртуальной машины между хостами и/или хранилищами путем передачи данных ВМ в фоновом режиме (пока она запущена) и потом на время простоя (переключения) передается только дельта файлов vmdk. Переключение осуществляется с помощью технологии SmartSwitch или просто повторной загрузкой ВМ. По сути, эта функция - аналог vMotion и Storage vMotion, но с небольшим простоем ВМ.
SmartSwitch - эта технология позволяет передать текущее состояние ВМ от исходного хоста и хранилища к источнику на время переключения виртуальной машины между ними (с простоем). При этом процессоры исходного и целевого хостов должны быть совместимы по инструкциями.
Migration jobs - новый тип задач "миграция ВМ". С учетом имеющейся у вас лицензии на VMware vSphere, мастер миграции выполняет одну из следующих задач: VMware vMotion, VMware Storage vMotion, Veeam Quick Migration
with SmartSwitch или Veeam Quick Migration with cold switch. Это позволяет быстро перевести ВМ с хостов, для которых требуется срочное обслуживание или останов (например, электричество выключили, а они на UPS'ах) или перенести ВМ в другой датацентр с минимальным влиянием на доступность сервисов в ВМ.
Instant VM Recovery integration - задачи миграции ВМ теперь оптимизированы для работы с функцией Instant VM Recovery. Если задача миграции обнаруживает, что ВМ переносится из состояния, когда она была мгновенно восстановлена (т.е. дельта размещается на vPower NFS datastore), то постоянная составляющая этой ВМ берется из бэкап-файла, а различия уже с NFS-хранилища для ускорения процесса миграции и оптимизации производительности.
Копирование файлов в Veeam Backup and Replication 6
Support for copying individual file - поддержка копирования отдельных файлов. Задача по копированию файлов теперь поддерживается так же, как и для каталогов.
Восстановление виртуальных машин в Veeam Backup and Replication 6
1-click VM restore - при восстановлении ВМ в исходное размещение (самый частый случай), это может быть сделано в один клик.
Virtual Disk Restore wizard - новый режим восстановления позволяет восстановить отдельные vmdk-диски в их исходное размещение или присоединить к другой или новой ВМ. При этом мастер Virtual Disk Restore может восстанавливать диски как "thin" (т.е. растущими по мере наполнения данными), а также делает все необходимые настройки в заголовочном vmdk-файле.
Hot Add restores - Veeam Backup первым стал поддерживать технологию Hot Add не только для РК, но и для восстановления vmdk-дисков, что позволяет избежать проблем производительности.
Multi-VM restore - возможность восстановления сразу многих ВМ из графического интерфейса, что очень удобно для случаев массовых отказов хранилищ или хост-серверов.
Full support for DVS - полная поддержка распределенных коммутаторов VMware Distributed Virtual Switches и улучшения в интерфейсе по интеграции с ним (что удобно, например, при использовании совместно с vCloud Director).
Network mapping - при восстановлении виртуальных машин на сервер или площадку с другой конфигурацией виртуальных сетей, можно указать новые параметры сетевого взаимодействия.
moRef preservation - при восстановлении ВМ с заменой существующей копии, ее идентификатор сохраняется, что позволяет не перенастраивать задачи Veeam, а также стороннее ПО, работающее с виртуальными машинами по их идентификатору (почти все так и работают).
Восстановление на уровне файлов в Veeam Backup and Replication 6
Support for GPT and simple dynamic disks - теперь восстановление на уровне файлов поддерживает тома GPT и simple dynamic disks.
Preservation of NTFS permissions - опционально при восстановлении файлов Windows можно сохранить владельца и права на них в NTFS.
Индексирование и поиск файлов в резервных копиях Veeam Backup and Replication 6
Optional Search Server - теперь поиск по файлам гостевой ОС работает без Microsoft Search Server. Однако он рекомендуется для больших окружений с сотнями ВМ для лучшей производительности.
Reduced catalog size - размер каталога файловой системы гостевых ОС существенно уменьшился, что позволяет экономить место на сервере Veeam Backup.
User profile indexing - появилась поддержка индексации профиля пользователя в гостевой ОС.
Статистика и отчетность в Veeam Backup and Replication 6
Enhanced real-time statistics - теперь статистика в реальном времени по задачам РК улучшена в плане дизайна, чаще обновляется и более информативна для пользователя.
Improved job reports - отчеты о задачах РК лучше выглядят, имеют дополнительную информацию, включая количество изменившихся данных, уровень компрессии и коэффициент дедупликации.
Bottleneck monitor - в ответ на наиболее частые вопросы о низкой производительности в различных окружениях, Veeam сделала новый компонент, который позволяет выявить узкие места на различных стадиях РК и репликации. Все это отображается в статистике реального времени.
VM loss warning - история задач РК теперь оповещает пользователя о виртуальных машинах, которые раньше бэкапились, а потом задачи РК перестали существовать (например, случайно или намеренно удалили).
Интерфейс пользователя консоли Veeam Backup and Replication 6
Wizard improvements - все мастера были обновлены для возможности быстрой навигации при создании задач РК. Некоторые мастера стали динамическими - т.е. сфокусированными только на той задаче, которую вы хотите выполнить.
VM ordering - мастера резервного копирования и репликации теперь позволяют задать порядок, в котором ВМ должны обрабатываться.
Multi-user access - доступ нескольких пользователей к консоли теперь включен по умолчанию, позволяя нескольким пользователям получить доступ к консоли по RDP на одном сервере.
Веб-интерфейс Enterprise Manager в Veeam Backup and Replication 6
Job editing - в дополнение к управлению задачами, Enterprise Manager позволяет теперь менять их настройки для защищаемых ВМ, бэкап-репозитории, учетную запись гостевой ОС - все прямо из веб-интерфейса.
Job cloning - существующие задачи теперь могут быть клонированы прямо из веб-интерфейса с сохранением всех настроек.
Helpdesk FLR - появилась новая роль "File Restore Operator" в Enterprise Manager, которой делегированы полномочия по восстановлению отдельных файлов. Ее можно назначить персоналу службы help desk. При этом файлы восстанавливаются в их исходное размещение, а персоналу hepl desk можно ограничить возможности их скачивания, и, соответственно, доступа к ним (есть настройки касательно типов файлов и прочее).
FIPS compliance - веб-интерфейс теперь полностью совмести с стандартом FISP.
Design improvements - веб-интерфейс имеет множество улучшений в плане юзабилити и дизайна.
Улучшения технологии SureBackup в Veeam Backup and Replication 6
Improved DC handling - теперь улучшена работа с контроллерами домена в ситуациях, когда он оказывается изолированным в окружениях с несколькими DC.
Support for unmanaged VMware Tools - задачи SureBackup теперь поддерживают виртуальные машины с пакетами VMware Tools, которые установлены вручную.
Остальные улучшения Veeam Backup and Replication 6
Enhanced PowerShell support - расширены возможности PowerShell API, что позволяет управлять всеми настройками Veeam Backup. Все командлеты PowerShell были упрощены в плане синтаксиса (старый синтаксис также поддерживается). Появились маски в именах объектов, поиск объектов - все аналогично возможностям в консоли.
Log collection wizard - новый мастер, который собирает лог-файлы с защищенных хостов и подготавливает пакет, необходимый при обращении в техподдержку Veeam.
1-click automated upgrade - все компоненты продукта, включая те, что установлены на удаленной площадке (backup
proxy servers и backup repositories), могут быть просто обновлены с использованием мастера Upgrade wizard. При открытии консоли, Veeam Backup & Replication автоматически определяет компоненты решения, которые следует обновить.
Продукт Veeam Backup and Replication 6 должен быть доступен для скачивания с сайта Veeam ориентировочно в среду на странице загрузки продукта.
Несколько скриншотов. Восстановление файла резервной копии из результатов поиска в Enterprise Manager:
Настройки Traffic Throttling:
Мастер восстановления виртуальной машины Microsoftc Hyper-V:
Настройка бэкап-репозиториев:
Настройки Re-IP при восстановлении на резервной площадке:
Часто бывает, что от хоста ESX/ESXi нужно отвязать Datastore и LUN, на котором это виртуальное хранилище находится. При этом важно избежать ситуации All Paths Down (APD) - когда на хосте все еще остались пути к устройству, а самого устройства ему больше не презентовано. В этом случае хост ESX/ESXi будет периодически пытаться обратиться к устройству (команды чтения параметров диска) через демон hostd и восстановить пути.
В этом случае из-за APD хоста начнут возникать задержки других задач (поскольку таймауты большие), что может привести к различным негативным эффектам вплоть до отключения хоста от vCenter.
ESX/ESXi 4.1
В версии ESX/ESXi 4.1 демон hostd проверяет том VMFS на доступность прежде чем слать туда команды ввода-вывода (I/Os) Но это не помогает для тех I/O, которые находятся в процессе в то время, когда случилась ситуация APD.
Как описано в KB 1015084, правильно отвязывать LUN с хоста ESX/ESXi 4.1 так (все делается на каждом из хостов):
Разрегистрировать все объекты с этого Datastore (если они там есть), включая шаблоны - правой кнопкой по объекту, Remove from Inventory.
Убедиться, что этот datastore не используют сторонние программы.
Убедиться, что никакие из фичей vSphere для хранилищ (например, Storage I/O Control) больше не используются для этого устройства.
Замаскировать LUN на хосте ESX/ESXi, следуя инструкциям KB 1009449 через модуль PSA (Pluggable Storage Architecture).
Со стороны дискового массива распрезентовать LUN от хоста.
Сделать "Rescan for Datastores" на хосте ESX/ESXi.
Удалить правила маскирования LUN, которые вы сделали на шаге 4 по инструкции в KB1015084.
Убедиться, что не осталось путей к устройству, после того, как вы проделали все эти операции.
Для ESX/ESXi 4.1 процесс достаточно сложный, теперь давайте посмотрим, как это выглядит в ESXi 5.
ESXi 5.0
В ESXi 5.0 появился новый статус Permanent Device Loss (PDL), то есть когда хост считает, что дисковое устройство уже никогда не будет снова подключено, а ситуация APD рассматривается как временный сбой, после которого хост снова увидит пути и устройство.
Чтобы избавиться от сложной процедуры отключения LUN от хостов ESXi, VMware сделала операции detach и unmount в интерфейсе vSphere Client и в командном интерфейсе CLI.
Вот тут можно найти unmount Datastore (но устройство продолжит быть доступным):
А вот тут находится detach для самого устройства:
Как описано в KB 2004605, чтобы у вас не возникло ситуации APD, нужно всего-лишь сделать detach устройства от хоста. Это размонтирует VMFS-том (если там есть какие-нибудь объекты - vSphere Client вам сообщит об этом).
Таким образом правильная последовательность отключения LUN в ESXi 5.0 теперь такова:
Разрегистрировать все объекты с этого Datastore (если они там есть), включая шаблоны - правой кнопкой по объекту, Remove from Inventory.
Убедиться, что этот datastore не используют сторонние программы.
Убедиться, что никакие из фичей vSphere для хранилищ (например, Storage I/O Control или Storage DRS) больше не используются для этого устройства.
Сделать detach устройства на хосте ESXi, что также автоматически повлечет за собой операцию unmount.
Со стороны дискового массива распрезентовать LUN от хоста.
Сделать "Rescan for Datastores" на хосте ESXi.
Ну и в качестве дополнительного материала можно почитать вот эти статьи:
Как вы знаете есть самое лучшее средство для создания отказоустойчивых хранилищ iSCSI - StarWind Enterprise HA. С его помощью можно, используя всего 2 физических сервера, создать недорогое хранилище для виртуальных машин (в том числе на базе локальных дисков серверов) с поддержкой возможностей HA/vMotion/SVMotion и т.п., которое переживет отказ одного из узлов без простоя виртуальных машин. Кроме того, есть отдельная версия продукта для создания отказоустойчивого хранилища и кластера ВМ на базе всего двух серверов - StarWind Native SAN for Hyper-V.
Пользователи StarWind часто спрашивают, а как можно создать резервную копию конфигурации самого сервера StarWind? Ведь если у вас много хранилищ (например, вы их цепляете с дискового массива), то в случае переустановки Windows или сбоя сервера их восстановление может занять значительное время.
Выход прост и элегантен - нужно просто бэкапить/восстанавливать файл starwind.cfg и убедиться в том, что буквы дисков (где лежат ima-файлы хранилищ) остались теми самыми, что и раньше, после переустановки или восстановления ОС. Все это применимо и к StarWind Enterprise HA для обоих узлов HA. Таким же образом можно организовать и переезд одного из узлов StarWind на другой сервер.
Несмотря на то, что в VMware vSphere Client диски виртуальных машин создаются уже выровненными относительно блоков системы хранения данных, многих пользователей платформы беспокоит, не выглядит ли их дисковая подсистема для ВМ таким образом:
Специально для таких пользователей, на сайте nickapedia.com появилась бесплатная утилита UBERAlign, которая позволяет найти виртуальные диски машин с невыровненными блоками и выровнять их по любому смещению.
Но самое интересное, что утилита UBERAlign работает еще и как средство, позволяющее уменьшать размер виртуальных дисков ВМ с "тонкими" дисками (thin provisioning), возвращая дисковое пространство за счет удаленных, но не вычищенных блоков.
Скачать UBERAlign можно по этой ссылке (а вот тут в формате виртуального модуля OVA), полный список возможностей утилиты можно найти тут (там еще несколько видеодемонстраций).
Как мы уже писали, недавно компания StarWind выпустила решение StarWind Native SAN for Hyper-V (возможности см. тут), которое позволяет построить кластер отказоустойчивости серверов и хранилищ для виртуальных машин Hyper-V, используя всего лишь 2 физических сервера, что вдвое сокращает затраты на внедрение решения и его обслуживание.
10 ноября компания StarWind проводит вебинар по продукту Native SAN for Hyper-V, ведет его Анатолий Вильчинский, который, как не трудно догадаться, говорит по-русски, поэтому вы сможете задать все интересующие вас вопросы по решению для вашей виртуальной инфраструктуры Hyper-V.
Дана и время вебинара: 10 ноября в 19-00 по московскому времени.
Интересный момент обнаружился на блогах компании VMware. Оказывается, если вы используете в кластере VMware HA разные версии платформы VMware ESXi (например, 4.1 и 5.0), то при включенной технологии Storage DRS (выравнивание нагрузки на хранилища), вы можете повредить виртуальный диск вашей ВМ, что приведет к его полной утере.
In clusters where Storage vMotion is used extensively or where Storage DRS is enabled, VMware recommends that you do not deploy vSphere HA. vSphere HA might respond to a host failure by restarting a virtual machine on a host with an ESXi version different from the one on which the virtual machine was running before the failure. A problem can occur if, at the time of failure, the virtual machine was involved in a Storage vMotion action on an ESXi 5.0 host, and vSphere HA restarts the virtual machine on a host with a version prior to ESXi 5.0. While the virtual machine might power on, any subsequent attempts at snapshot operations could corrupt the vdisk state and leave the virtual machine unusable.
По русски это выглядит так:
Если вы широко используете Storage vMotion или у вас включен Storage DRS, то лучше не использовать кластер VMware HA. Так как при падении хост-сервера ESXi, HA может перезапустить его виртуальные машины на хостах ESXi с другой версией (а точнее, с версией ниже 5.0, например, 4.1). А в это время хост ESXi 5.0 начнет Storage vMotion, соответственно, во время накатывания последовательности различий vmdk (см. как работает Storage vMotion) машина возьмет и запустится - и это приведет к порче диска vmdk.
Надо отметить, что такая ситуация, когда у вас в кластере используется только ESXi 5.0 и выше - произойти не может. Для таких ситуаций HA и Storage vMotion полностью совместимы.
Компания StarWind, выпускающая продукт номер 1 для создания отказоустойчивых iSCSI-хранилищ для виртуализации StarWind Enterprise HA, на прошлой неделе выпустила новый продукт для создания кластера хранилищ виртуальных машин StarWind Native SAN for Microsoft Hyper-V (подробнее тут и тут). Отличительной особенностью продукта является то, что он позволяет орагнизовать отказоустойчивую конфигурацию серверов и хранилищ на базе всего лишь 2-х серверов Hyper-V, что в 2 раза сокращает затраты на оборудование (серверы, коммутаторы) и обслуживание решения.
Таги: StarWind, SAN, Hyper-V, iSCSI, Storage, HA, TCO, VMachines
Скоро нам придется участвовать в интереснейшем проекте - построение "растянутого" кластера VMware vSphere 5 на базе технологии и оборудования EMC VPLEX Metro с поддержкой возможностей VMware HA и vMotion для отказоустойчивости и распределения нагрузки между географически распределенными ЦОД.
Вообще говоря, решение EMC VPLEX весьма новое и анонсировано было только в прошлом году, но сейчас для нашего заказчика уже едут модули VPLEX Metro и мы будем строить active-active конфигурацию ЦОД (расстояние небольшое - где-то 3-5 км) для виртуальных машин.
Для начала EMC VPLEX - это решение для виртуализации сети хранения данных SAN, которое позволяет объединить ресурсы различных дисковых массивов различных производителей в единый логический пул на уровне датацентра. Это позволяет гибко подходить к распределению дискового пространства и осуществлять централизованный мониторинг и контроль дисковых ресурсов. Эта технология называется EMC VPLEX Local:
С физической точки зрения EMC VPLEX Local представляет собой набор VPLEX-директоров (кластер), работающих в режиме отказоустойчивости и балансировки нагрузки, которые представляют собой промежуточный слой между SAN предприятия и дисковыми массивами в рамках одного ЦОД:
В этом подходе есть очень много преимуществ (например, mirroring томов двух массивов на случай отказа одного из них), но мы на них останавливаться не будем, поскольку нам гораздо более интересна технология EMC VPLEX Metro, которая позволяет объединить дисковые ресурсы двух географически разделенных площадок в единый пул хранения (обоим площадкам виден один логический том), который обладает свойством катастрофоустойчивости (и внутри него на уровне HA - отказоустойчивости), поскольку данные физически хранятся и синхронизируются на обоих площадках. В плане VMware vSphere это выглядит так:
То есть для хост-серверов VMware ESXi, расположенных на двух площадках есть одно виртуальное хранилище (Datastore), т.е. тот самый Virtualized LUN, на котором они видят виртуальные машины, исполняющиеся на разных площадках (т.е. режим active-active - разные сервисы на разных площадках но на одном хранилище). Хосты ESXi видят VPLEX-директоры как таргеты, а сами VPLEX-директоры являются инициаторами по отношению к дисковым массивам.
Все это обеспечивается технологией EMC AccessAnywhere, которая позволяет работать хостам в режиме read/write на массивы обоих узлов, тома которых входят в общий пул виртуальных LUN.
Надо сказать, что технология EMC VPLEX Metro поддерживается на расстояниях между ЦОД в диапазоне до 100-150 км (и несколько более), где возникают задержки (latency) до 5 мс (это связано с тем, что RTT-время пакета в канале нужно умножить на два для FC-кадра, именно два пакета необходимо, чтобы донести операцию записи). Но и 150 км - это вовсе немало.
До появления VMware vSphere 5 существовали некоторые варианты конфигураций для инфраструктуры виртуализации с использованием общих томов обоих площадок (с поддержкой vMotion), но растянутые HA-кластеры не поддерживались.
С выходом vSphere 5 появилась технология vSphere Metro Storage Cluster (vMSC), поддерживаемая на сегодняшний день только для решения EMC VPLEX, но поддерживаемая полностью согласно HCL в плане технологий HA и vMotion:
Обратите внимание на компонент посередине - это виртуальная машина VPLEX Witness, которая представляет собой "свидетеля", наблюдающего за обоими площадками (сам он расположен на третьей площадке - то есть ни на одном из двух ЦОД, чтобы его не затронула авария ни на одном из ЦОД), который может отличить падения линка по сети SAN и LAN между ЦОД (экскаватор разрезал провода) от падения одного из ЦОД (например, попадание ракеты) за счет мониторинга площадок по IP-соединению. В зависимости от этих обстоятельств персонал организации может предпринять те или иные действия, либо они могут быть выполнены автоматически по определенным правилам.
Теперь если у нас выходит из строя основной сайт A, то механизм VMware HA перезагружает его ВМ на сайте B, обслуживая их ввод-вывод уже с этой площадки, где находится выжившая копия виртуального хранилища. То же самое у нас происходит и при массовом отказе хост-серверов ESXi на основной площадке (например, дематериализация блейд-корзины) - виртуальные машины перезапускаются на хостах растянутого кластера сайта B.
Абсолютно аналогична и ситуация с отказами на стороне сайта B, где тоже есть активные нагрузки - его машины передут на сайт A. Когда сайт восстановится (в обоих случаях с отказом и для A, и для B) - виртуальный том будет синхронизирован на обоих площадках (т.е. Failback полностью поддерживается). Все остальные возможные ситуации отказов рассмотрены тут.
Если откажет только сеть управления для хостов ESXi на одной площадке - то умный VMware HA оставит её виртуальные машины запущенными, поскольку есть механизм для обмена хартбитами через Datastore (см. тут).
Что касается VMware vMotion, DRS и Storage vMotion - они также поддерживаются при использовании решения EMC VPLEX Metro. Это позволяет переносить нагрузки виртуальных машин (как вычислительную, так и хранилище - vmdk-диски) между ЦОД без простоя сервисов. Это открывает возможности не только для катастрофоустойчивости, но и для таких стратегий, как follow the sun и follow the moon (но 100 км для них мало, специально для них сделана технология EMC VPLEX Geo - там уже 2000 км и 50 мс latency).
Самое интересное, что скоро приедет этот самый VPLEX на обе площадки (где уже есть DWDM-канал и единый SAN) - поэтому мы все будем реально настраивать, что, безусловно, круто. Так что ждите чего-нибудь про это дело интересного.
Таги: VMware, HA, Metro, EMC, Storage, vMotion, DRS, VPLEX
Мы уже много писали о новом продукте StarWind Native SAN for Hyper-V, который позволит создать кластер отказоустойчивости серверов и хранилищ для виртуальных машин Hyper-V, используя всего 2 хост-сервера (это намного дешевле традиционных решений).
Напоминаем, что продукт выходит завтра, 18 октября.
Вебинар: "StarWind Native SAN for Hyper-V: конвергенция гипервизора и СХД"
18 октября, вторник
StarWind Native SAN for Hyper-V работает на локальном Hyper-V сервере и обеспечивает высокую доступность СХД при минимальных затратах и простоте развёртывания. Продукт идеально подходит для представителей малого и среднего бизнеса, которые не могут позволить себе аппаратные СХД, но хотят использовать следующие преимущества Hyper-V кластера:
Высокая доступность
Защита от сбоя жесткого диска
Защита от единой точки отказа. Безшовная интеграция с Hyper-V
Одно из существенных изменений, Datastore Heartbeating - механизм, позволяющий мастер-серверу определять состояния хост-серверов VMware ESXi, изолированных от сети, но продолжающих работу с хранилищами. Напомним, что в качестве heartbeat-хранилищ выбираются два, и они могут быть определены пользователем. Выбираются они так: во-первых, они должны быть на разных массивах, а, во-вторых, они должны быть подключены ко всем хостам.
Если у вас доступно общее хранилище только одно, вы получите такое предупреждение в vSphere Client:
Теперь еще один момент, на который хочется обратить внимание. Помните, что в настройках VMware HA есть варианты выбора действия для хост-сервера по отношении к своим виртуальным машинам в том случае, когда он обнаруживает, что изолирован от сети (параметр Isolation Responce):
Напомним, что Isolation Responce может принимать следующие значения:
Leave powered on (по умолчанию в vSphere 5 - оптимально для большинства сценариев)
Power off
Shutdown
Выбирать правильную настройку нужно следующим образом:
Если наиболее вероятно что хост ESXi отвалится от общей сети, но сохранит коммуникацию с системой хранения, то лучше выставить Power off или Shutdown, чтобы он мог погасить виртуальную машину, а остальные хосты перезапустили бы его машину с общего хранилища после очистки локов на томе VMFS или NFS (вот кстати, что происходит при отваливании хранища).
Если вы думаете, что наиболее вероятно, что выйдет из строя сеть сигналов доступности (например, в ней нет избыточности), а сеть виртуальных машин будет функционировать правильно (там несколько адаптеров) - ставьте Leave powered on.
Разницу между Power off и Shutdown многие из вас знают - во втором случае машина выключается средствами гостевой системы, а в первом случае - это жесткое выключение средствами хост-сервера. Казалось бы, лучше всего ставить второй вариант (Shutdown). Но это не всегда так. Дело в том, что при действии shutdown у гостевой ОС может не получиться погасить систему (например, вылетит exception или еще что). В этом случае хост ESXi будет пытаться сделать shutdown в течение 5 минут до того, как он уже сделает действие power off.
Это приведет к тому, что время восстановления работоспособности сервиса вполне может увеличиться на 5 минут, что может быть критично для некоторых задач (с высокими требованиями к RTO). Зато в случае shutdown у вас произойдет корректное завершение работы сервера, а при power off могут не сохраниться данные, нарушиться консистентность и т.п. Выбирайте.
Мы уже рассматривали новые возможности платформы VMware vSphere 5, в состав которой входит продукт для резервного копирования виртуальных машин VMware Data Recovery 2.0 (vDR).
Остановимся на них несколько подробнее. Что появилось нового в vDR 2.0:
Виртуальный модуль Data Recovery использует 64-битную ОС CentOS 5.5, что улучшает масштабирование и надежность.
Swap-файлы (внутри гостевой ОС Windows и Linux) больше не включаются в резервные копии, что ускоряет процесс резервного копирования.
Операции Integrity check (проверка консистентности) и reclaim (высвобождение места) теперь можно запускать по расписанию (кроме того, работают быстрее). Кроме того, если процесс проверки будет приостановлен (например, вылезет за пределы окна обслуживания), то его можно продолжить с того же места, не запуская с начала. Кроме того, процесс может выполняться одновременно с другими задачами.
Улучшена устойчивость к нестабильности сетевого соединения.
Можно приостановить виртуальный модуль, чтобы новые задачи бэкапа не запускались.
Доступны оповещения администраторов по email об успешном и неудачном завершении задач.
Улучшенная производительность дедупликации.
Как мы видим, улучшения достаточно небольшие, поэтому vDR до продукта Veeam Backup and Replication еще далеко, шестая версия которого выйдет уже совсем скоро.
В первой части статьи мы уже рассматривали наиболее оптимальную конфигурацию средства VMware vSphere Storage Appliance для создания отказоустойчивого кластера хранилищ из трех хостов и описали, что происходит с хранилищами при отказе сети синхронизации (Back-End Network). Во второй части статьи мы расскажем о том, как конфигурация VSA отрабатывает отказ сети управления и экспорта NFS-хранилищ (Front-End).
RSS
