В новой книге Фрэнка на 300 страницах раскрываются следующие моменты, касающиеся производительности подсистемы хранения платформ виртуализации, построенной на базе локальных дисков хост-серверов:
Новая парадигма построения виртуального датацентра с точки зрения систем хранения
Архитектура решения FVP
Ускорение доступа к данным
Технология непрерывной доступности Fault Tolerance
Технология Flash
Техники доступа к памяти
Настройка кластера решения FVP
Сетевой дизайн инфраструктуры локальных хранилищ
Внедрение и пробная версия решения FVP
Дизайн инфраструктуры хранилищ
Несмотря на то, что книга рассматривает в качестве основного продукта решение FVP от компании PernixData, ее интересно читать и с точки зрения понимания архитектуры и производительности подобных решений.
Если вы посмотрите в документ VSAN Troubleshooting Reference Manual (кстати, очень нужный и полезный), описывающий решение проблем в отказоустойчивом кластере VMware Virtual SAN, то обнаружите там такую расширенную настройку, как VSAN.ClomMaxComponentSizeGB.
Когда кластер VSAN хранит объекты с данными виртуальных дисков машин, он разбивает их на кусочки, растущие по мере наполнения (тонкие диски) до размера, указанного в данном параметре. По умолчанию он равен 255 ГБ, и это значит, что если у вас физические диски дают полезную емкость меньше данного объема (а точнее самый маленький из дисков в группе), то при достижении тонким диском объекта предела физической емкости вы получите вот такое сообщение:
There is no more space for virtual disk XX. You might be able to continue this session by freeing disk space on the relevant volume and clicking retry.
Если, например, у вас физический диск на 200 ГБ, а параметры FTT и SW равны единице, то максимально объект виртуального диска машины вырастет до этого размера и выдаст ошибку. В этом случае имеет смысл выставить настройку VSAN.ClomMaxComponentSizeGB на уровне не более 80% емкости физического диска (то есть, в рассмотренном случае 160 ГБ). Настройку эту нужно будет применить на каждом из хостов кластера Virtual SAN.
Как это сделать (более подробно об этом - в KB 2080503):
В vSphere Web Client идем на вкладку Manage и кликаем на Settings.
Под категорией System нажимаем Advanced System Settings.
Выбираем элемент VSAN.ClomMaxComponentSizeGB и нажимаем иконку Edit.
Устанавливаем нужное значение.
Надо отметить, что изменение этой настройки работает только для кластера VSAN без развернутых на нем виртуальных машин. Если же у вас уже продакшен-инфраструктура столкнулась с такими трудностями, то вы можете воспользоваться следующими двумя способами для обхода описанной проблемы:
1. Задать Object Space Reservation в политике хранения (VM Storage Policy) таким образом, чтобы дисковое пространство под объекты резервировалось сразу (на уровне 100%). И тогда VMDK-диски будут аллоцироваться целиком и распределяться по физическим носителям по мере необходимости.
2. Задать параметр Stripe Width в политиках VM Storage Policy таким образом, чтобы объекты VMDK распределялись сразу по нескольким физическим накопителям.
Фишка еще в том, что параметрVSAN.ClomMaxComponentSizeGB не может быть выставлен в значение, меньшее чем 180 ГБ, а значит если у вас носители меньшего размера (например, All-Flash конфигурация с дисками меньше чем 200 ГБ) - придется воспользоваться одним из этих двух способов, чтобы избежать описанной ошибки. Для флеш-дисков 200 ГБ установка значения в 180 ГБ будет ок, несмотря на то, что это уже 90% физической емкости.
Представляем гостевой пост компании 1cloud, предоставляющей услуги в области хостинга виртуальных машин по модели IaaS. С падением цен на SSD все больше компаний предлагают массивы, целиком построенные на флеш-памяти, но действительно ли они лучше гибридных массивов, содержащих как твердотельные накопители, так и жесткие диски?
Многие из вас, следящие за новостями о лучшем продукте для создания отказоустойчивых хранилищ StarWind Virtual SAN, часто задаются вопросом - а чем это решение лучше существующих аналогов от VMware и Microsoft? Первый и наиболее очевидный ответ - цена. Просто посмотрите на то, сколько стоит VMware VSAN, и сравните это со стоимостью лицензий StarWind. Разницу вы почувствуете сразу.
Но это еще не все. Компания StarWind выпустила полезный каждому сомневающемуся документ "StarWind Virtual SAN: Differentiation [from competitors]", в котором весьма подробно рассмотрены преимущества продукта перед решениями от маститых вендоров.
Например, почему StarWind Virtual SAN лучше VMware Virtual SAN:
Для работы отказоустойчивых хранилищ StarWind нужно всего 2 узла (VMware требует минимум 3). Плюс StarWind не требует какой-то особенной инфраструктуры типа поддержки 10G Ethernet или SSD-дисков. У StarWind все проще.
VMware Virtual SAN лицензируется по числу процессоров ESXi плюс требуются лицензии на сам ESXi. У StarWind лицензия выйдет дешевле - вы можете лицензировать по числу узлов кластера хранилищ, либо весь датацентр сразу, и использовать бесплатные издания ESXi.
Кластер VMware Virtual SAN вы можете использовать только для платформы vSphere, а StarWind Virtual SAN можно использовать для хранения виртуальных машин на базе любого гипервизора - хоть ESXi, хоть Hyper-V, хоть XenServer.
StarWind Virtual SAN - это продукт, который сейчас находится в 8-й версии, а Virtual SAN - это всего лишь вторая версия решения. Поскольку это решение относится к самому нижнему уровню сервисов хранения датацентра, надежность работы решения является определяющим факторов.
Более подробно об этом и других продуктах для сравнения, в частности, Microsoft Storage Spaces, Microsoft Scale-Out File Server, HP Lefthand VSA, DataCore SANsymphony, Maxta и PernixData, вы можете узнать непосредственно из документа.
Некоторое время назад мы писали об очень серьезном баге в технологии Changed Block Tracking, обеспечивающей работу инкрементального резервного копирования виртуальных машин VMware vSphere 6. Баг заключался в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могли быть потеряны. Для первого бэкапа в этом нет ничего страшного, а вот вызываемая во второй раз функция QueryDiskChangedAreas технологии CBT не учитывала потерянные операции ввода-вывода, а соответственно при восстановлении из резервной копии такой бэкап был неконсистентным.
Мы писали про временное решение, заключающееся в отключении технологии CBT при снятии резервных копий продуктом Veeam Backup and Replication, но оно, конечно же, было неприемлемым, так как скорость бэкапов снижалась в разы, расширяя окно резервного копирования до неприличных значений.
И вот, наконец, вышло исправление этого бага, описанное в KB 2137545. Это патч для сервера VMware ESXi, который распространяется в виде стандартного VIB-пакета в сжатом zip-архиве.
Чтобы скачать патч, идите по этой ссылке, выберите продукт "ESXi Embedded and Installable" и введите в поле Enter Bulletin Number следующую строчку:
ESXi600-201511401-BG
Нажмите Search, после чего скачайте обновленный билд VMware ESXi 6.0 по кнопке Download:
Про патч в формате VIB-пакета написано вот тут, а про сам обновленный релиз ESXi вот тут. Для установки VIB на сервере ESXi используйте следующую команду:
Как-то раз мы писали про баг в VMware vSphere 5.5 (и более ранних версиях), заключавшийся в том, что при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT) их резервные копии оказывались невалидными и не подлежащими восстановлению. Эта ошибка была через некоторое время пофикшена.
Суть критического бага в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могут быть потеряны. Для первого бэкапа в этом нет ничего страшного, а вот вызываемая во второй раз функция QueryDiskChangedAreas технологии CBT не учитывает потерянные операции ввода-вывода, а соответственно при восстановлении из резервной копии такой бэкап будет неконсистентным. То есть баг намного более серьезный, чем был в версии vSphere 5.5 (там надо были задеты только ВМ, диски которых увеличивали, а тут любая ВМ подвержена багу).
На данный момент решения этой проблемы нет, надо ждать исправления ошибки. Пока VMware предлагает на выбор 3 варианта:
Сделать даунгрейд хостов ESXi на версию 5.5, а версию virtual hardware 11 понизить на 10.
Делать полные бэкапы виртуальных машин (full backups) вместо инкрементальных.
Выключать виртуальные машины во время инкрементального бэкапа, чтобы у них не было никаких IO, которые могут потеряться.
Как вы понимаете, ни один из этих вариантов неприемлем в условиях нормальной работы производственной среды. Мы оповестим вас об исправлении ошибки, ну а пока поздравляем службу контроля качества компании VMware с очередной лажей!
P.S. Пока делайте полные бэкапы критичных систем. И следите за новостями от Veeam.
Сегодняшняя статья расскажет вам ещё об одной функции моего PowerShell-модуля для управления виртуальной инфраструктурой VMware - Vi-Module. Первая статья этой серии с описанием самого модуля находится здесь. Функция Convert-VmdkThin2EZThick. Как вы уже поняли из её названия, функция конвертирует все «тонкие» (Thin Provision) виртуальные диски виртуальной машины в диски типа Thick Provision Eager Zeroed.
Многие из вас знают, что в VMware vSphere есть такой режим работы виртуальных дисков, как Raw Device Mapping (RDM), который позволяет напрямую использовать блочное устройство хранения без создания на нем файловой системы VMFS. Тома RDM бывают pRDM (physical) и vRDM (virtual), то есть могут работать в режиме физической и виртуальной совместимости. При работе томов в режиме виртуальной совместимости они очень похожи на VMFS-тома (и используются очень редко), а вот режим физической совместимости имеет некоторые преимущества перед VMFS и довольно часто используется в крупных предприятиях.
Итак, для чего может быть полезен pRDM:
Администратору требуется использовать специальное ПО от производителя массива, которое работает с LUN напрямую. Например, для создания снапшотов тома, реплики базы данных или ПО, работающее с технологией VSS на уровне тома.
Старые данные приложений, которые еще не удалось перенести в виртуальные диски VMDK.
Виртуальная машина нуждается в прямом выполнении команд к тому RDM (например, управляющие SCSI-команды, которые блокируются слоем SCSI в VMkernel).
Перейдем к рассмотрению схемы решения VMware Site Recovery Manager (SRM):
Как вы знаете, продукт VMware SRM может использовать репликацию уровня массива (синхронную) или технологию vSphere Replication (асинхронную). Как мы писали вот тут, если вы используете репликацию уровня массива, то поддерживаются тома pRDM и vRDM, а вот если vSphere Replication, то репликация физических RDM будет невозможна.
Далее мы будем говорить о репликации уровня дискового массива томов pRDM, как о самом часто встречающемся случае.
Если говорить об уровне Storage Replication Adapter (SRA), который предоставляется производителем массива и которым оперирует SRM, то SRA вообще ничего не знает о томах VMFS, то есть о том, какого типа LUN реплицируется, и что на нем находится.
Он оперирует понятием только серийного номера тома, в чем можно убедиться, заглянув в XML-лог SRA:
Тут видно, что после серийного номера есть еще и имя тома - в нашем случае SRMRDM0 и SRMVMFS, а в остальном устройства обрабатываются одинаково.
SRM обрабатывает RDM-диски похожим на VMFS образом. Однако RDM-том не видится в качестве защищаемых хранилищ в консоли SRM, поэтому чтобы добавить такой диск, нужно добавить виртуальную машину, к которой он присоединен, в Protection Group (PG).
Допустим, мы добавили такую машину в PG, а в консоли SRM получили вот такое сообщение:
Device not found: Hard disk 3
Это значит одно из двух:
Не настроена репликация RDM-тома на резервную площадку.
Репликация тома настроена, но SRM еще не обнаружил его.
В первом случае вам нужно заняться настройкой репликации на уровне дискового массива и SRA. А во втором случае нужно пойти в настройки SRA->Manage->Array Pairs и нажать там кнопку "Обновить":
Этот том после этого должен появиться в списке реплицируемых устройств:
Далее в настройках защиты ВМ в Protection Group можно увидеть, что данный том видится и защищен:
Добавление RDM-диска к уже защищенной SRM виртуальной машине
Если вы просто подцепите диск такой ВМ, то увидите вот такую ошибку:
There are configuration issues with associated VMs
Потому, что даже если вы настроили репликацию RDM-диска на уровне дискового массива и SRA (как это описано выше), он автоматически не подцепится в настройки - нужно запустить редактирование Protection Group заново, и там уже будет будет виден RDM-том в разделе Datastore groups (если репликация корректно настроена):
Помните также, что SRM автоматически запускает обнаружение новых устройств каждые 24 часа по умолчанию.
Гостевая статья нашего спонсора - компании ИТ-ГРАД, предоставляющей услуги виртуальных машин VMware в аренду. В этой статье речь пойдет о плюсах интеграции среды виртуализации VMware и систем хранения NetApp. В частности, продолжим разбираться с VAAI и посмотрим, как использование такой связки может помочь в проектах по разработке ПО.
Больше 5 лет назад мы писали о технологии VMware Storage I/O Control (SIOC), которая позволяет приоритизировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены. С тех пор многие администраторы применяют SIOC в производственной среде, но не все из них понимают, как именно это работает.
На эту тему компания VMware написала два интересных поста (1 и 2), которые на практических примерах объясняют, как работает SIOC. Итак, например, у нас есть вот такая картинка:
В данном случае мы имеем хранилище, отдающее 8000 операций ввода-вывода в секунду (IOPS), к которому подключены 2 сервера ESXi, на каждом из которых размещено 2 виртуальных машины. Для каждой машины заданы параметры L,S и R, обозначающие Limit, Share и Reservation, соответственно.
Напомним, что:
Reservation - это минимально гарантированная производительность канала в операциях ввода-вывода (IOPS). Она выделяется машине безусловно (резервируется для данной машины).
Shares - доля машины в общей полосе всех хостов ESXi.
Limit - верхний предел в IOPS, которые машина может потреблять.
А теперь давайте посмотрим, как будет распределяться пропускная способность канала к хранилищу. Во-первых, посчитаем, как распределены Shares между машинами:
Общий пул Shares = 1000+2500+500+1000 = 5000
Значит каждая машина может рассчитывать на такой процент канала:
Если смотреть с точки зрения хостов, то между ними канал будет поделен следующим образом:
ESX1 = 3500/5000 = 70%
ESX2 = 1500/5000 = 30%
А теперь обратимся к картинке. Допустим у нас машина VM1 простаивает и потребляет только 10 IOPS. В отличие от планировщика, который управляет памятью и ее Shares, планировщик хранилищ (он называется mClock) работает по другому - неиспользуемые иопсы он пускает в дело, несмотря на Reservation у это виртуальной машины. Ведь он в любой момент может выправить ситуацию.
Поэтому у первой машины остаются 1590 IOPS, которые можно отдать другим машинам. В первую очередь, конечно же, они будут распределены на этом хосте ESXi. Смотрим на машину VM2, но у нее есть LIMIT в 5000 IOPS, а она уже получает 4000 IOPS, поэтому ей можно отдать только 1000 IOPS из 1590.
Следовательно, 590 IOPS уйдет на другой хост ESXi, которые там будут поделены в соответствии с Shares виртуальных машин на нем. Таким образом, распределение IOPS по машинам будет таким:
Все просто и прозрачно. Если машина VM1 начнет запрашивать больше канала, планировщик mClock начнет изменять ситуацию и приведет ее к значениям, описанным выше.
В этой заметке мы расскажем еще об одной важной новой функции пакета продуктов - Scale-out Backup Repository. Ранее пользователи Veeam Backup and Replication использовали различные устройства для бэкап-репозиториев, чтобы хранить резервные копии виртуальных машин. Это могли быть локальные диски серверов, файловые хранилища, разделы на СХД и многое другое. Так как инфраструктура растет постепенно и, зачастую, неоднородно, в итоге у администраторов оказывался примерно вот такой наборчик бэкап-репозиториев:
Эта картина плоха со всех сторон. Во-первых, таким большим числом репозиториев трудно управлять - надо следить за их доступностью, поддерживать схемы именования, смотреть за свободным пространством и т.п. Все это создает серьезные административные проблемы в большой инфраструктуре.
Во-вторых, число бэкап-задач, которые создает администратор - как минимум равно числу бэкап-репозиториев, так как одна задача не может охватывать 2 репозитория.
Ну и, в третьих, посмотрите на свободное место на каждом репозитории - его весьма много (если брать среднее, то 30%). То есть, мы используем вполовину больше того, что нам требуется.
Эта ситуация давно волновала администраторов, и в новой версии Veeam Availability Suite v9 представлена функция Scale-out Backup Repository, которая позволяет объединить все репозитории в один мета-объект (global pool), который можно задавать в качестве целевого хранилища бэкапов. Для расширения такого пула потребуется лишь добавить экстент (extent), который повысит совокупную емкость глобального репозитория. Удобно и не надо перераспределять целевые хранилища, чтобы найти свободное место под новые бэкапы.
Таким образом, можно использовать единственную задачу резервного копирования всех нужных вам машин, указав в качестве целевого этот глобальный репозиторий. При этом глобальный репозиторий можно наращивать хранилищами любого типа - локальные диски серверов, сетевые хранилища и даже, например, дедуплицирующие физические или виртуальные модули (dedup appliances) - все это для Veeam Backup and Replication будет поддерживаться и работать.
При добавлении экстента можно указать, принимает ли он полные бэкапы (full backups), инкрементальные бэкапы (incremental backups) или оба типа. Например, для инкрементальных бэкапов можно использовать быстрые all-flash хранилища, а для полных бэкапов можно применять dedup appliance в качестве целевого хранилища резервных копий, где они будут лежать в дедуплицированном виде. Возможности для фантазии тут безграничны.
Также происходит, по-сути, появление бэкап-облака, нового уровня абстракции, которое представляется пользователям как единое пространство хранения резервных копий, а его обслуживанием занимается бэкап-администратор. Теперь владельцы систем могут сами настраивать бэкап своих виртуальных машин в единое облако, не думая, какой репозиторий выбрать, а бэкап-администратор уже займется оптимизацией своего облака.
Более подробно об этом всем написано в блоге Veeam.
Бывает так, что на виртуальной или физической машине заканчивается свободное место на диске, где расположена база данных для VMware vCenter. Чаще всего причина проста - когда-то давно кто-то не рассчитал размер выделенного дискового пространства для сервера, где установлен vCenter и SQL Server Express.
В этом случае в логах (в SQL Event Log Viewer и SQL Log) будут такие ошибки:
Could not allocate space for object ‘dbo.VPX_EVENT_ARG’.’PK_VPX_EVENT_ARG’ in database ‘VIM_VCDB’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 4096 MB per database.
Could not allocate space for object 'dbo.VE_event_historical'.'PK__VE_event_histori__00551192' in database 'ViewEvent' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files tothe filegroup, or setting autogrowth on for existing files in the filegroup.
Решение в данном случае простое - нужно выполнить операцию по очистке старых данных из БД SQL Server (Shrink Database). Делается это в SQL Management Studio - нужно выбрать базу данных и выполнить Tasks -> Shrink -> Database:
Смотрим, что получится и нажимаем Ok:
Также в KB 1025914 вы найдете более детальную информацию о том, как почистить базы данных Microsoft SQL Server и Oracle. Там же есть и скрипты очистки БД:
Мероприятие пройдет 20 октября в 22-00 по московскому времени.
На вебинаре будет рассказано, почему в гиперконвергентной инфраструктуре лучше иметь 3 узла для организации отказоустойчивых хранилищ. Напомним, что мы уже писали об этой архитектуре вот тут.
Этой статьёй я хочу открыть серию статей, целью каждой из которых будет описание одной из написанных мной функций PowerCLI или так называемых командлетов (cmdlets), предназначенных для решения задач в виртуальных инфраструктурах, которые невозможно полноценно осуществить с помощью только лишь встроенных функций PowerCLI. Все эти функции будут объединены в один модуль - Vi-Module. Как им пользоваться, можете почитать здесь.
Иногда администраторам хранилищ в VMware vSphere требуется передать логический том LUN или локальный диск сервера под другие цели (например, отдать не под виртуальные системы или передать в другой сегмент виртуальной инфраструктуры). В этом случае необходимо убедиться, что все данные на этом LUN удалены и не могут быть использованы во вред компании.
Раньше это приходилось выполнять путем загрузки из какого-нибудь Linux LiveCD, которому презентован данный том, и там удалять его данные и разделы. А в VMware vSphere 6 Update 1 появился более простой способ - теперь эта процедура доступна из графического интерфейса vSphere Web Client в разделе Manage->Storage Adapters:
Теперь просто выбираем нужный адаптер подсистемы хранения и нажимаем Erase для удаления логических томов устройства (будут удалены все логические тома данного устройства):
Теперь можно использовать этот локальный диск по другому назначению, например, отдать кластеру VSAN.
Ну и также отметим, что в следующей версии утилиты ESXi Embedded Host Client компания VMware сделает возможность не только удаления таблицы разделов, но и добавит средства их редактирования:
Компания StarWind Software, известная своим лучшим продуктом для созданиях отказоустойчивых хранилищ для VMware vSphere и Microsoft Hyper-V, на отдельном подсайте сделала доступной базу знаний StarWind Knowledge Base.
Статьи KB разбиты по категориям, по всей базе доступен поиск, к каждой статье есть тэги. На данный момент в базе 41 статья, среди которых есть несколько полезных в плане обучения, например, Logical block size или StarWind LSFS FAQ.
Скачать пробную версию продукта StarWind Virtual SAN можно по этой ссылке.
Мы уже писали о новой версии решения VMware Virtual SAN 6.1, предназначенной для создания отказоустойчивых хранилищ на платформе VMware vSphere. После того, как издания "hybrid" и "all-flash" были переименованы в "standard" и "advanced" соответственно, у пользователей появилось несколько вопросов о функциональности этих изданий.
Начнем с того, что в целом все осталось как было:
VSAN
STANDARD
VSAN
ADVANCED
VSAN FOR ROBO
(25 VM PACK)
Политики хранилищ Storage Policy Based Management (SPBM)
Итак, мы видим, что отличий у изданий Standard и Advanced теперь два:
Для конфигураций только из SSD-дисков серверов можно использовать только издание Advanced.
Для "растянутых" кластеров также можно использовать только издание Advanced. Но тут есть нюанс - растянутым кластером можно считать географически разнесенные площадки (на уровне двух разных зданий). Если у вас кластер на уровне стоек в двух серверных или на разных этажах - растянутым он не считается.
Также появилось издание VSAN for ROBO (remote or branch offices). Это издание позволяет использовать решение VSAN компаниям имеющую сеть небольших филиалов, где нет большого числа хостов ESXi. Для такой лицензии можно запустить не более 25 виртуальных машин в рамках филиала и одной ROBO-лицензии.
Здесь кластеры строятся на уровне каждого из филиалов, а witness-компонент (виртуальный модуль, следящий за состоянием кластера) располагается в инфраструктуре центрального офиса. Причем на каждый кластер VSAN нужно по отдельному witness'у. Этот самый witness позволяет построить кластер на базе всего двух узлов, а не трех, так как он следит за ситуацией split brain в кластере. Это позволяет удешевить решение для филиала, использовав для инфраструктуры из 25 машин всего 2 сервера. Более подробно о ROBO-сценарии написано вот тут.
А вот как выглядит настройка ROBO-издания Virtual SAN:
Ну и, само собой, ROBO-сценарии можно реализовывать по своему усмотрению на лицензиях Standard или Advanced.
Мы уже немало писали про технологию использования хранилищ VVols (например, здесь и здесь), которая позволяет существенно увеличить производительность операций по работе с хранилищами в среде VMware vSphere за счет использования отдельных логических томов под компоненты виртуальных машин и передачи части операций по работе с ними на сторону дисковых массивов.
Давайте посмотрим, как же технология VVols влияет на процесс резервного копирования виртуальных машин, например, с помощью основного продукта для бэкапа ВМ Veeam Backup and Replication, который полностью поддерживает VVols. Для начала рассмотрим основные способы резервного копирования, которые есть в виртуальной среде:
Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
Резервное копирование по сети SAN (SAN-to-SAN backup) - в этом случае на выделенном сервере (Backup Server) через специальный механизм Virtual Disk API происходит снятие снапшота ВМ без задействования хоста ESXi и бэкап машины на целевое хранилище напрямую в сети SAN без задействования среды Ethernet.
Последний способ - самый быстрый и эффективный, но он требует наличия специальных интерфейсов (vSphere APIs и Virtual Disk Development Kit, VDDK), которые должны присутствовать на выделенном сервере.
К сожалению, для VVols способ резервного копирования по сети SAN еще не поддерживается, так как данный механизм для прямой работы с хранилищами SAN для VVols еще не разработан. Поэтому при работе с VVols придется использовать NBD backup. Однако не расстраивайтесь - большинство компаний именно его и используют для резервного копирования машин на томах VMFS в силу различных причин.
Работа хоста VMware ESXi с томами виртуальной машины VVols выглядит следующим образом:
Для процессинга операций используется Protocol Endpoint (PE), который представляет собой специальный административный LUN на хранилище. PE работает с лунами машин (VVols), которые представлены через secondary LUN ID, а VASA Provider со стороны дискового массива снабжает vCenter информацией о саблунах виртуальных машин, чтобы хост ESXi мог с ними работать через PE.
Таким образом, в новой архитектуре VVols пока не прикрутили технологический процесс соединения стороннего сервера с VVols виртуальных машин и снятия с них резервных копий.
Вернемся к процессу резервного копирования. Как известно, он опирается на механизм работы снапшотов (Snapshots) - перед снятием резервной копии у ВМ делается снапшот, который позволяет перевести базовый диск в Read Only, а изменения писать в дельта-диск снапшота. Далее базовый диск ВМ копируется бэкап-сервером, ну а после того, как базовый диск скопирован, снапшот склеивается с основным диском, возвращая диски машины обратно в консолидированное состояние.
Так это работает для файловой системы VMFS, которая развертывается поверх LUN дискового массива. Сами понимаете, что при интенсивной нагрузке во время резервного копирования (особенно больших виртуальных дисков) с момента снятия снапшота может пройти довольно много времени. Поэтому в дельта-дисках может накопиться много данных, и процесс консолидации снапшота на практике иногда занимает часы!
Для виртуальных томов VVols все работает несколько иначе. Давайте взглянем на видео:
В среде VVols при снятии снапшота базовый диск остается режиме Read/Write (это все делает массив), то есть контекст записи данных никуда не переключается, и изменения пишутся в базовый диск. В снапшоты (это отдельные тома VVol) пишется только информация об изменениях базового диска (какие дисковые блоки были изменены с момента снятия снапшота).
Ну а при удалении снапшота по окончанию резервного копирования никакой консолидации с базовым диском производить не требуется - так как мы продолжаем с ним работать, просто отбрасывая дельта-диски.
Такой рабочий процесс несколько увеличивает время создания снапшота в среде VVols:
Но это всего лишь десятки секунд разницы. А вот время консолидации снапшота по окончанию резервного копирования уменьшается во много раз:
Как следствие, мы имеем уменьшение совокупного времени резервного копирования до 30%:
Так что, если говорить с точки зрения резервного копирования виртуальных машин, переход на VVols обязательно даст вам прирост производительности операций резервного копирования и позволит уменьшить ваше окно РК.
Известный блоггер Vladan Seget написал интересную статью (и даже не одну, а несколько) о различных способах развертывания средства StarWind Virtual SAN, предназначенного для создания отказоустойчивого кластера хранилищ под виртуальные машины.
Вот 3 основных метода развертывания StarWind Virtual SAN:
Обычная установка на Windows-систему. Сделать это можно в пробном режиме бесплатно, или имея соответствующую лицензию на продукт.
Более подробно об этом методе развертывания StarWind Virtual SAN написано вот тут.
Установка на бесплатный Microsoft Hyper-V Server. Этот метод не требует вообще никаких вложений, даже в лицензию на Windows Server, так как Hyper-V Server бесплатен. Но вам потребуется Windows-машина (не обязательно сервер) для установки консоли StarWind, так как в Hyper-V Server нет оконного интерфейса.
Об этом методе установки StarWind Virtual SAN написано здесь.
Установка из виртуального модуля OVF. Этот способ и описан в последней статье Владана. Такой способ установки позволяет загрузить уже готовую виртуальную машину StarWind Virtual SAN для Microsoft Hyper-V (ее можно преобразовать в формат VMware VMDK из VHDX с помощью бесплатного StarWind V2V Converter).
Все делается достаточно просто, и весь процесс занимает не более часа. Попробуйте!
Многие из вас в курсе, что решение StarWind Virtual SAN обеспечивает лучшую в отрасли защиту виртуальных машин на платформе Microsoft Hyper-V за счет создания стабильно работающего отказоустойчивого кластера хранилищ.
Для тех, кто еще не развертывал этот продукт, компания StarWind подготовила видеоруководство "StarWind Virtual SAN Free: Virtualized Shared Storage for Microsoft Hyper-V. Step-by-step", в рамках которого вы сможете посмотреть, как меньше чем за час развернуть отказоустойчивый кластер хранилищ для виртуальных машин Microsoft Hyper-V (для просмотра видео потребуется заполнить форму):
Ну а для тех, кто видео смотреть не любит, есть простой и понятный документ "StarWind Virtual SAN Free Getting Started", где вся процедура описывается просто и наглядно на нескольких страницах.
На проходящей сейчас конференции VMworld 2015 было сделано множество интересных анонсов (впрочем, как и всегда). Конечно же, мы расскажем о всех тех, что достойны внимания. Одна из самых интересных новостей - это анонс новой версии решения для создания кластеров хранилищ VMware Virtual SAN 6.1.
Давайте взглянем на новые возможности этого решения:
1. Virtual SAN Stretched Cluster.
Теперь VSAN будет позволять создавать географически "растянутый" кластер хранилищ между датацентрами, продолжая обеспечивать функции отказоустойчивости. Репликация данных при этом работает с синхронном режиме.
2. Virtual SAN for Remote Office / Branch Office (ROBO)
В VSAN теперь появилась возможность развертывать множество двухузловых кластеров хранилищ, которыми можно централизованно управлять из одной консоли отдельного VMware vCenter Server, предназначенного для этой задачи. Этот сценарий подходит для компаний с большим числом небольших филиалов:
3. Virtual SAN Replication with vSphere Replication
Virtual SAN 6.1 теперь может использовать технологию vSphere Replication для асинхронной репликации данных на любые расстояния в комбинации с VMware Site Recovery Manager (SRM), чтобы получилось полностью законченное решения для восстановления инфраструктуры после сбоев.
Например, можно создать синхронно реплицируемый растянутый кластер хранилищ на расстояниях с latency менее 5 мс, а средствами vSphere Replication откидывать данные в географически удаленный датацентр:
4. Поддержка Multi-Processor Fault Tolerance (SMP-FT).
Теперь виртуальные машины, защищенные технологией FT, полностью поддерживаются со стороны VMware Virtual SAN 6.1, то есть кластер непрерывной доступности из виртуальных машин теперь защищен как со стороны вычислительных ресурсов, так и со стороны хранилищ.
5. Поддержка Windows Server Failover Clustering (WSFC) and Oracle Real Application Cluster (RAC).
В новой версии VSAN теперь поддерживаются технологии кластеризации от Oracle и Microsoft. Для Oracle RAC можно запускать несколько экземпляров Oracle RDBMS на одном хранилище. Точно так же можно использовать и кластеры Microsoft WSFC поверх хранилищ Virtual SAN:
6. Максимальная производительность и высокая скорость отклика.
Здесь было сделано 2 серьезных улучшения:
Поддержка ULLtraDIMM SSD хранилищ, которые втыкаются в канал оперативной памяти (слоты DIMM), работающие с очень быстрым откликом на запись (менее 5 микросекунд). Это позволяет сделать хост All Flash с емкостью на 12 ТБ в форм-факторе блейд-сервера с троекратно большей производительностью, чем у внешних массивов.
NVMe – интерфейс Non-Volatile Memory Express (NVMe), который был специально разработан для SSD, чтобы максимально распараллеливать операции на программном и аппаратном уровне. В тестах VMware, использующих эту технологию, было получено 3,2 миллиона IOPS на 32-узловом кластере при примерно 100 тысячах операций в секунду на одном хост-сервере ESXi.
7. Virtual SAN Health Check Plug-in.
Теперь плагин, который был ранее доступен только на VMware Labs, стал частью решения VMware Virtual SAN 6.1. Теперь вся необходимая информация о жизнедеятельности кластера хранилищ видна в VMware vSphere Web Client:
8. Virtual SAN Management Pack for vRealize Operations.
Теперь для решения vRealize Operations есть отдельный Virtual SAN Management Pack, который позволяет осуществлять мониторинг кластера хранилищ и своевременно решать возникающие проблемы:
Более подробно о решении VMware Virtual SAN 6.1 можно узнать на этой странице. О доступности решения для загрузки будет объявлено несколько позже.
В ближайшее время мы расскажем еще о нескольких интересных анонсах с VMworld 2015 - stay tuned.
Компания StarWind, известная своим продуктом StarWind Virtual SAN для создания программных отказоустойчивых хранилищ, выпустила интересный документ о своей журналируемой файловой системе - "LSFS container technical description".
Напомним, что файловая система LSFS изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины. Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.
Помимо этого, LSFS имеет следующие полезные функции:
встроенная поддержка снапшотов и точек восстановления хранилищ (автоматически они делаются каждые 5 минут)
поддержка непрерывной дефрагментации (она идет в фоне)
дедупликация данных "на лету" (то есть, перед записью на диск)
улучшения производительности за счет комбинирования операций записи
поддержка overprovisioning
использование технологии снапшотов и техник отслеживания изменений при синхронизации HA-узлов
Многие из вас знают о решении StarWind Virtual SAN, предназначенном для создания отказоустойчивых хранилищ. Но не все в курсе, что у StarWind есть виртуальный модуль Virtual SAN OVF (ссылка на его загрузку высылается по почте), который представляет собой шаблон виртуальной машины в формате OVF готовый к развертыванию на платформе VMware vSphere.
Недавно компания StarWind выпустила документ Virtual SAN OVF Deployment Guide, в котором описана процедура развертывания данного виртуального модуля.
Поскольку Microsoft на уровне лицензии запрещает распространение таких виртуальных модулей с гостевой ОС Windows в формате виртуальных дисков VMDK, придется сделать несколько дополнительных операций по развертыванию, а именно:
1. Запустить StarWind V2V Converter.
2. Преобразовать VHDX-диски в формат VMDK.
3. Поместить VMDK и OVF в одну папку.
4. Развернуть OVF на сервере VMware ESXi.
5. Заполнить поля IP-адреса для включения машины в виртуальную сеть.
6. Подождать окончания процесса создания и конфигурации виртуальной машины.
Больше подробностей о виртуальном модуле StarWind Virtual SAN OVF вы найдете в документе.
Таги: StarWind, Whitepaper, Virtual Appliance, OVF, Storage, HA
Интересный сервис по продвижению решения Virtual SAN предлагает компания VMware через своих партнеров. Поскольку сам продукт стоит очень дорого, и мало кого можно на него подписать вот так вот сразу, VMware предлагает воспользоваться услугой VSAN Assessment. Она бесплатна, может быть оказана любым партнером VMware и позволяет получить необходимую конфигурацию аппаратного обеспечения для консолидации существующих виртуальных машин в отказоустойчивых кластерах Virtual SAN (напомним, что емкость там формируется из емкости локальных дисков серверов, являющихся узлами кластеров VSAN).
Суть сервиса такова: партнер регистрирует в закрытой партнерской секции новое обследование инфраструктуры (VSAN Assessment), после чего отправляет инвайт на него потенциальному заказчику. Он, в свою очередь, скачивает готовый виртуальный модуль (Collector Appliance), настраивает его и держит запущенным в течение, по крайней мере, одной недели (минимально).
В течение этого времени происходит сбор профилей рабочей нагрузки по вводу-выводу, на основании чего можно уже нарисовать необходимые ресурсы кластера хранилищ, выбрать нужную модель сервера для узла VSAN и определить требуемое число таких узлов.
Сначала анализируется виртуальная инфраструктура VMware vSphere на площадке клиента:
Затем выводятся рекомендуемые к консолидации в кластере хранилищ виртуальные машины. Также показывается совместимость с типом кластера Virtual SAN (All-flash или гибридная модель, где данные размещаются на магнитных накопителях):
Затем мы видим требуемые ресурсы как для одного узла, так и для всего кластера Virtual SAN, а также видим, какой именно сервер и с какими аппаратными характеристиками имеется в виду (производителя сервера можно выбрать, само собой):
Ну и для того, чтобы заказчика отвлечь от высокой входной цены продукта Virtual SAN, используется метод убеждения по снижению совокупной стоимости владения (TCO - total cost of ownership) при внедрении решения VMware VSAN:
Ну и прямо расписывают вам экономию по годам:
Ну то есть, если вы все же решили потестировать технологию VMware Virtual SAN, обратитесь к своему поставщику - он заведет вам VSAN Assessment и вы сами посмотрите, какие железки рекомендуется использовать именно под ваши нагрузки по вводу-выводу для размещения виртуальных машин.
Послезавтра, 21 июля, компании Mellanox и StarWind проведут интересный вебинар "100 GbE Performance at 10 GbE Cost", посвященный построению решения для хранилищ виртуальных машин впечатляющей производительности (да-да, 100 GbE, Карл!).
Мероприятие пройдет 21 июля, в 21-00 по московскому времени:
Приходите на вебинар, чтобы узнать, как по цене 10 GbE-решения построить сеть 40 GbE на базе продуктов Mellanox (Infiniband/Ethernet) и добиться в ней 100 GbE производительности за счет решений компании StarWind (в частности, продукта Virtual SAN). Вебинар со стороны StarWind проводит Макс Коломейцев, так что вы можете задавать вопросы на русском языке.
Время от времени у пользователей VMware vSphere возникает ошибка, связанная с тем, что виртуальный диск VMDK виртуальной машины оказывается залоченным (то есть эксклюзивно используемым процессом VMX одного из хостов ESXi). В этом случае виртуальная машина не отвечает на попытки включить ее или переместить на другой хост-сервер средствами VMware vMotion. При этом процесс vmx вполне может быть запущен не на том хосте ESXi, на котором машина отображается в VMware vSphere Client или Web Client. Такое может случиться при падении хоста ESXi, массовом отключении питания или неполадках в сети SAN, а также и в некоторых других случаях.
Например, может быть вот такое сообщение об ошибке при включении машины:
Could not power on VM: Lock was not free
Для решения проблемы вам нужно найти хост ESXi, который исполняет vmx-процесс машины, и убить ВМ, которая не отвечает. После этого можно будет использовать VMDK-файл этой машины, а также включить ее, если она не работает.
Делается это следующим образом:
1. Находим хост, исполняющий vmx-процесс виртуальной машины с залоченным VMDK.
Для этого заходим по SSH на один из серверов ESXi (эта процедура работает для версий vSphere 5.5 P05 и 6.0, а также более поздних) и переходим в папку /bin:
#cd /bin
С помощью утилиты vmfsfilelockinfo ищем владельца лока нужного VMDK-файла:
Здесь vm1.vmdk - наш залоченный виртуальный диск, а 192.168.1.10 - IP-адрес сервера VMware vCenter. Вам потребуется ввести пароль его администратора.
Вывод будет примерно таким:
vmfsflelockinfo Version 1.0
Looking for lock owners on "VM1_1-000001-delta.vmdk"
"VM1_1-000001-delta.vmdk" is locked in Exclusive mode by host having mac address ['00:50:56:03:3e:f1']
Trying to make use of Fault Domain Manager
----------------------------------------------------------------------
Found 0 ESX hosts using Fault Domain Manager.
----------------------------------------------------------------------
Could not get information from Fault domain manager
Connecting to 192.168.1.10 with user administrator@vsphere.local
Password: xXxXxXxXxXx
----------------------------------------------------------------------
Found 3 ESX hosts from Virtual Center Server.
----------------------------------------------------------------------
Searching on Host 192.168.1.178
Searching on Host 192.168.1.179
Searching on Host 192.168.1.180
MAC Address : 00:50:56:03:3e:f1
Host owning the lock on the vmdk is 192.168.1.180, lockMode : Exclusive
Total time taken : 0.27 seconds.
Из вывода можно понять 2 важные вещи:
MAC-адрес хоста, залочившего VMDK
IP-адрес хоста, залочившего VMDK
Тип лока - Exclusive
Кстати, лок может быть нескольких типов:
mode 0 - нет лока
mode 1 - эксклюзивный лок (vmx-процесс машины существует и использует VMDK-диск)
mode 2 - лок только для чтения (например, для основного диска, в случае если у него есть снапшоты)
mode 3 - лок для одновременной записи с нескольких хостов (например, для кластеров MSCS или ВМ, защищенных технологией VMware Fault Tolerance).
2. Точно определяем хост, машина которого держит VMDK.
Если IP-адрес показан - хост определен. Если, мало ли, по какой-то причине его нет, можно ориентироваться на MAC-адрес. Выяснить его можно следующей командой на хосте ESXi:
# vim-cmd hostsvc/net/info | grep "mac ="
3. Обнаруживаем процесс VMX, который держит VMDK.
Выполняем на найденном ESXi команду:
# lsof | egrep 'Cartel|vm1.vmdk'
Получаем что-то вроде этого:
Cartel | World name | Type | fd | Description
36202 vmx FILE 80 /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/VM1/vm1.vmdk
Мы нашли Cartel ID нужного процесса VMX (36202). Теперь выполняем команду, чтобы найти ее World ID:
# esxcli vm process list
Получаем такой вывод:
Alternate_VM27
World ID: 36205
Process ID: 0
VMX Cartel ID: 36202
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a9 dc 9f bf
Display Name: Alternate_VM27
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM27/Alternate_VM27.vmx
Alternate_VM20
World ID: 36207
Process ID: 0
VMX Cartel ID: 36206
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a5 dc 94 5f
Display Name: Alternate_VM20
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM20/Alternate_VM20.vmx
...
Видим, что World ID нашей машины - 36205.
4. Убиваем VMX-процесс, залочивший VMDK.
Ну и убиваем зависший процесс VMX следующей командой:
# esxcli vm process kill --type force --world-id <ID>
После этого с машиной и ее диском можно делать уже что требуется.
Также для более ранних версий VMware vSphere посмотрите нашу статью вот здесь.
Совсем недавно компания StarWind Software, производитель средства номер 1 для создания отказоустойчивых программных хранилищ под виртуальные машины VMware и Microsoft - Virtual SAN, выпустила интересный документ по его бесплатному изданию - "StarWind Virtual SAN Free Getting Started".
Напомним, что полностью бесплатный продукт StarWind Virtual SAN Free позволяет превратить два новых или имеющихся у вас сервера в отказоустойчивый кластер хранения (с полностью дублированными зеркалированными узлами), который может служить для:
размещения виртуальных машин Microsoft Hyper-V (NFS/SMB3)
размещения виртуальных машин VMware vSphere (NFS)
размещения баз данных MS SQL Server (SMB3)
создания отказоустойчивого файлового сервера (SMB3/NFS)
Кстати, StarWind Virtual SAN Free - единственное решение, которое позволяет создавать HA-кластер из двух узлов неограниченной емкости абсолютно бесплатно. Более подробно об отличиях бесплатной и коммерческой версий продукта можно почитать вот в этом документе.
Таги: StarWind, Virtual SAN, Whitepaper, Storage, HA, Бесплатно, VMachines
Сегодня мы посмотрим, что еще нового будет в новой версии. Вторая запись в блоге Veeam рассказывает нам о том, что Veeam Availability Suite v9 будет поддерживать прямой доступ к хранилищам NAS/NFS при резервном копировании. Раньше пользователи NFS-массивов чувствовали себя несколько "обделенными" в возможностях, так как Veeam не поддерживал режим прямой интеграции с таким типом дисковым массивов, как это было для блочных хранилищ.
Теперь же появилась штука, называемая Direct NFS, позволяющая сделать резервную копию ВМ по протоколам NFS v3 и новому NFS 4.1 (его поддержка появилась только в vSphere 6.0), не задействуя хост-сервер для копирования данных:
Специальный клиент NFS (который появился еще в 8-й версии) при включении Direct NFS получает доступ к файлам виртуальных машин на томах, для которых можно делать резервное копирование и репликацию без участия VMware ESXi, что заметно повышает скорость операций.
Кроме этого, была улучшена поддержка дисковых массивов NetApp. В версии 9 к интеграции с NetApp добавилась поддержка резервного копирования из хранилищ SnapMirror и SnapVault. Теперь можно будет создавать аппаратные снимки (с учетом состояния приложений) с минимальным воздействием на виртуальную среду, реплицировать точки восстановления на резервный дисковый массив NetApp с применением техник SnapMirror или SnapVault, а уже оттуда выполнять бэкап виртуальных машин.
При этом процесс резервного копирования не отбирает производительность у основной СХД, ведь операции ввода-вывода происходят на резервном хранилище:
Ну и еще одна полезная штука в плане поддержки аппаратных снимков хранилищ от Veeam. Теперь появится фича Sandbox On-Demand, которая позволяет создать виртуальную лабораторию, запустив виртуальные машины напрямую из снапшотов томов уровня хранилищ. Такая лаборатория может быть использована как для проверки резервных копий на восстановляемость (сразу запускаем ВМ и смотрим, все ли в ней работает, после этого выключаем лабораторию, оставляя резервные копии неизменными), так и для быстрого клонирования наборов сервисов (создали несколько ВМ, после чего создали снапшот и запустили машины из него). То есть, можно сделать как бы снимок состояния многомашинного сервиса (например, БД-сервер приложений-клиент) и запустить его в изолированном окружении для тестов, ну или много чего еще можно придумать.
Veeam Availability Suite v9 ожидается к выпуску, скорее всего, в третьем квартале 2015 года. Следить за новостями по этому решению можно вот тут.
В блоге компании VMware появился интересный пост с некоторыми подробностями о работе технологии репликации виртуальных машин vSphere Replication. Приведем здесь основные полезные моменты.
Во-первых, репликация с точки зрения синхронизации данных, бывает двух типов:
Full sync - это когда требуется полная синхронизация виртуальной машины и всех ее дисков в целевое местоположение. Для этого в версии VMware vSphere 5.x использовалось сравнение контрольных сумм дисков на исходном и целевом хранилище. Если они не совпадают, и нужно делать Full sync, исходя из начальных условий - начинается процесс полной репликации ВМ. В первую очередь, основным подвидом этого типа является Initial full sync - первичная синхронизация работающей виртуальной машины, для которой репликация включается впервые.
Кроме того, полная синхронизация включается, когда по какой-либо причине произошла ошибка отслеживания блоков виртуального диска машины при дельта-репликации и передать на целевую ВМ только изменения виртуальных дисков становится невозможным.
Delta sync - после того, как полная синхронизация закончена, начинается процесс передачи целевой ВМ только различий с момента полной репликации. Тут используется технология changed block tracking, чтобы понять, какие блоки надо отреплицировать с последнего Full sync. Периодичность дельта-репликации зависит от установленной политики Recovery Point Objective (RPO).
Чтобы политика RPO соблюдалась нужно, чтобы дельта-синхронизация полностью проходила за половину времени, установленного в RPO, иначе будут нарушения политики, сообщения о которых вы увидите в vSphere Client. Почему половину? Подробно мы писали об этом вот тут (почитайте, очень интересно). Также еще и в документации VMware есть информация о расписании репликации.
Если вы настроите репликацию для виртуальной машины, то автоматически работать она будет для включенной ВМ, а если она выключена, то сама работать не будет, о чем будет выдано соответствующее предупреждение:
Вот так запускается репликация для выключенной ВМ:
Во время offline-репликации виртуальную машину нельзя включить, а ее диски будут залочены. Кроме того, вы не сможете отменить эту операцию. Поэтому при нажатии Sync Now будет выведено вот такое предупреждение:
Обычно offline-репликация используется для создания гарантированной копии ВМ на другой площадке (например, при переезде датацентра или частичном восстановлении инфраструктуры на другом оборудовании). Ну или если у вас была настроена online-репликация, а вы выключили ВМ, то в конце нужно сделать еще ручной Sync Now.
Также в VMware vSphere 6.0 было сделано существенное улучшение в производительности процесса репликации. Если раньше идентичность копий основного диска и реплики сверялась только на базе контрольных сумм (все данные диска надо прочитать - а это затратно по вводу-выводу и CPU), то теперь иногда используются данные о конфигурации виртуального диска на базе регионов. Например, если на исходном диске есть регионы, которые не были аллоцированы на целевом диске, то репликация это отслеживает и передает данные в эти регионы на целевое хранилище. Это работает значительно быстрее вычисления контрольных сумм.
Но такая оптимизация работает не для всех типов виртуальных дисков, а только для Lazy zeroed thick disks, thin disks и vSAN sparse disks и только на томах VMFS. Тома NFS, тома VVols, а также диски типа Eager zeroed thick не предоставляют информации об аллокации регионов, поэтому для них оптимизация работать не будет. Более подробно об этом написано тут.
Дункан опубликовал в своем блоге интересный пост про то, как кластер VMware Virtual SAN размещает данные больших VMDK-дисков на малых физических дисках. Напомним, что Virtual SAN оперирует понятием дисковых страйпов (disk stripes), на которые разбивается дисковый объект (в частности, виртуальный диск VMDK является дисковым объектом). Это как кирпичики Virtual SAN, на уровне которых работает кластер.
Давайте взглянем на картинку:
Здесь мы видим вот что: на уровне политики (VSAN Policy) задан параметр "Number of failures to tolerate" (подробнее об этом мы писали тут) равный 1. Это значит, что инфраструктура Virtual SAN может пережить отказ не более одного хоста.
Но также в рамках политики есть еще и параметр "Stripe Width" (он же "Number of Disk Stripes Per Object"), который позволяет разбить дисковый объект на два страйпа: stripe/a и stripe/b, причем обратите внимание, что реплика дискового объекта может храниться на разных хост-серверах (а может и на одном - это вы никак не сможете отрегулировать, гарантируется лишь, что это будут 2 разных hdd-диска). Так что, если у вас маленькие диски, а виртуальные машины с большими дисками VMDK, то задайте этот параметр вот здесь:
Кстати говоря, объекты разбиваются на страйпы не только при заданном Stripe Width, но и автоматически, когда размер VMDK превышает 256 ГБ.