Лучшее решение по защите данных виртуального окружения
Категория: Статьи
Альтернативы VCB для резервного копирования Vmware Защита данных в среде VMware имеет собственные проблемы, которые ещё проявятся полностью в ЦОДах во всей красе. Существует три общепринятых способа защиты VMware: метод гостевой ОС, метод консольного копирования и метод VCB. Каждая способ резервного копирования имеет свои собственные недостатки и преимущества, но их можно компенсировать альтернативными методами, например таким как инкрементальное копирование блочного уровня.
Методы резервного копирования VmwareПервый способ, возможно самый старый - это метод гостевой ОС. Эта практика однозначно трактует каждую виртуальную машину как отдельный сервер; программный агент устанавливается на виртуальный сервер, который впоследствии защищается как будто он физический сервер.
Этот метод защиты данных VMware имеет свои преимущества. Первое и самое главное - то, что администратор копирования уже с ним знаком, и это не требует существенных изменений в процессах или процедурах. Встроенные модули агента резервного копирования полноценно обрабатывают приложения баз данных и ситуации открытых файлов.Второй способ - это консольное резервное копирование, при котором администраторы виртуализации резервируют сервер VMware ESX без оглядки на работающие виртуальные машины.
Последняя, и самая новая практика - это VCB. Практика копирования VCB требует как VMware Infrastructure 3 (VI3), так и общих хранилищ как основу архитектуры, например, Fibre Channel, либо iSCSI SAN. Поставив VI3 и создав общее хранилище можно добавить выделенный Windows Server 2003, выступающий в роли посредника резервного копирования. Затем Вы устанавливаете программное обеспечение VCB на Windows Server и обеспечиваете доступ к тому же SAN Logical Unit Number (LUN), который используется для файлов виртуальных дисков VMware. На Windows сервер, где установлена система резервного копирования, Вы также должны установить агента VCB, а затем выполнить этапы по интеграции VMware и приложения резервного копирования. Приложение резервного копирования запускает копирование указанной виртуальной машины и затем связывается с VMware VirtualCenter и соответсвующим сервером ESX для подготовки виртуальной машины к копированию. После этого виртуальная машина сбрасывает на диск операции ввода-вывода и для каждой защищаемой виртуальной машины создаётся журнал повторного выполнения(redo log). После его создания виртуальные машины могут быть возвращены в их нормальное состояние. Затем посредник копирования монтирует файлы дисков виртуальных машин и позволяет агенту копирования отправить по сети копии на сервер копирования, который затем записывает поток на резервный носитель. VCB имеет свои недостаткиХотя VCB и выглядит как совершенный метод копирования многие заказчики его не используют. Самым большим препятствием является требование общего хранилища и необходимость установить VMware 3.1. Также он всё ещё требует скриптов для правильного выполнения.
Также VCB достаточно сложно настраивать и управлять. Многие заказчики не имеют лишнего места в их общей среде SAN для обработки больших требований к хранилищам со стороны создаваемых наборов данных VCB. Копирование области VCB - это пофайловое копирование, которое отнимает время, подвержено ошибкам. И последнее - VCB не обеспечивает специфичную поддержку баз данных, и как результат есть опасения по поводу получения чистых снимков среды. Восстановление состоит из двух этапов: на посредника копирования, затем в основную область хранения. Из-за недостатков VCB большинство заказчиков по большей части защищают свои системы используя практику гостевых ОС. Другими словами, они устанавливают стандартного агента резервного копирования на виртуальную машину(гостевая ОС), и копируют её как отдельную физическую машину. Хотя большинство поставщиков программ резервного копирования сейчас поставляют модули VCB для управления копиями снимков VCB только некоторые из них озадачились проблемами копирования гостевых ОС. Как назло метод гостевых ОС является предпочтительным для заказчиков в обозримом будущем. Вызовы копированию гостевых ОС и причины почему была создана VCB весьма существенны. Например, установка агента копирования на каждую гостевую ОС с последующим включением копирования на больших серверах VMware с множеством гостевых ОС может потреблять столько процессорной мощности, что гостевые ОС останавливаются или процесс копирования замедляется настолько, что кажется что никогда не закончится. Чтобы обойти это администраторы копирования должны разрабатывать очень сложные процессы копирования для предотвращения копирования слишком многих ОС на одном физическом ESX сервере одновременно. Лёгкая альтернатива агентам копирования гостевых ОСРешение с задействованием агентов копирования гостевых ОС использует приложение копирования, которое потребляет очень мало ресурсов процессора виртуальной машины. Одно из таких решений - это инкрементальные копии блочного уровня(BLI). BLI копии работают с гостевой ОС на самом низком уровне, поэтому не требуют просмотра сложной файловой системы в отличие от традиционных агентов копирования. Изменённые блоки данных идентифицируются быстрее и с меньшим воздействием на процессор, чем изменённые файлы. После идентификации изменённых блоков только они передаются по сети и поэтому данные на сервер копирования передаются очень быстро.
Первая копия BLI копирует каждый виртуальный сервер поблочно, воссоздавая поблочно виртуальный сервер на отдельном резервном дисковом хранилище вне виртуальной среды.
До выполнения второй и всех последующих копий делается снимок копируемого диска с сохранением информации по версиям файлов. После взятия снимка в резервное хранилище отправляется только изменённые блоки. Для большинства серверов, если не всех, мы имеем в результате очень маленькую нагрузку от копирования, которая занимает менее пяти минут до завершения. У некоторых поставщиков резервного копирования образ копии - это живая, просматриваемая файловая система, которая может быть использована немедленно.
Одним из преимуществ этого метода является то, что он позволяет перемещение виртуальных серверов на физические. Так как резервная копия - это просматриваемая файловая система, можно подключить резервную копию по iSCSI как отдельный физический сервер, после чего приложение может работать с этими данными. Это может иметь значение не только для целей тестирования, а например, если приложение имеет проблемы при работе в виртуальном состоянии всегда есть возможность быстро перенеси его в физическое состояние. Приложения баз данных также часто поддерживаются программным обеспечением BLI копий, чего нет у VCB.
Дополнительные вызовы копирования гостевых ОСМетод копирования гостевых ОС не затрагивает состояние среды ESX. Существуют утилиты от VMware которые легко это делают, но это требует дополнительного этапа вне процесса резервного копирования для сбора и защиты этой информации. Также можно использовать агента приложения резервного копирования для защиты среды посредством вышеупомянутой практики консольного копирования. Практика консольного копирования противоположна практике гостевой ОС. Для копирования сервера ESX используется серверная консоль и сама ОС и виртуальная машина - это всего лишь «файлы» внутри самой ОС. Сервисная консоль - это специальная виртуальная машина, построенная на Red Hat Linux, которая работает на каждом сервере ESX. При этом методе на сервисную консоль VMware устанавливается linux-клиент. Сервисная консоль видна VMFS. В этой файловой системе существуют файлы виртуальных дисков, конфигурационные файлы различных виртуальных машин, и ESX, и файлы журнала повторного выполнения. Агент посылает поток копирования по сети на сервер резервного копирования, который записывает образ резервной копии на соответствующий резервный носитель. Затем приложение резервного копирования работает с этими данными как и с любыми другими.
Метод копирования VCB имеет собственные преимущества в обеспечении единой точки копирования вынесенной за пределы сервера ESX, но его влияние на ресурсы может быть очень велико и трудно переносимо. Гибридный подход копирования гостевой ОС и консольного может обеспечить более разумное решение. Применение консольного резервного копирования совместно с копированием гостевой ОС, подразумевает, что нужно только собрать конфигурационные файлы виртуальных машин и ESX, что означает что файлы виртуальных дисков могут быть проигнорированы. Практика копирования для сетевых ОС использованием BLI снижает нагрузку на процессор, что приводит к удобному планированию и снижает количество данных передаваемых на сервер копирования и резервные носители. Та же самая технология BLI может быть использована на сервисной консоли VMware для копирования файлов среды ESX, предлагая полное решение. Об авторе:Джордж Крамп - это президент и старший аналитик в Storage Switzerland, аналитической фирме IT, сфокусированной на сегментах хранения и виртуализации с 25тилетним опытом конструирования систем хранения и ЦОД по всей США. Он видел рождение таких технологий, как RAID, NAS и SAN. До основания Storage Switzerland он был техническим директором одного из крупнейших национальных интеграторов систем хранения, где отвечал за тестирование технологий, интеграцию и выбор продуктов.
Оригинал документа находится по адресу http://www.syncsort.com/PDF/SearchVMwareWPCrump.pdf Скачать статью Джорджа Крампа в .pdf
Статья "Конкурентное сравнение Syncsort Backup Express и Symantec NetBackup" Совместное решение по защите данных от Syncsort и NetApp Совершенная защита виртуальной среды VMware Пресс-релиз о выходе новой версии Syncsort Backup Express 3.1 |
