Разработка архитектуры сети учебного класса

Структурная схема обычного учебного класса показана на рисунке 1.

Рисунок 1 Структурная схема компьютерной сети кафедры

При разработке архитектуры учебного класса с использованием технологии виртуализации необходимо учитывать следующую особенность – операционные системы на виртуальных машинах работают с виртуальными же аппаратными средствами. То есть, устройства подключены не напрямую к компьютеру, а подключены через какой–либо внешний интерфейс сервера, а уже с помощью его программных и аппаратных возможностей подключены к виртуальной машине, либо вообще с имитированы и не имеют реальных физических устройств.

При разработке следует найти возможность передачи файлов из виртуальной среды и обратно, а также возможность печати на принтере из виртуальной среды.

Так как все терминалы объединены физической локальной сетью, а виртуальные машины объединены виртуальной локальной сетью, а сервер виртуализации обеспечивает мостовое соединение между внешним физическим сетевым адаптером к которому подключена физическая сеть и внутренним виртуальным сетевым адаптером, к которому подключена виртуальная сеть, то можно считать, что и физические терминалы и виртуальные машины объединены одной локальной сетью.

Исходя из этого можно решить задачи печати и обмена файлами. Для обмена файлами предлагается организовать на одной из виртуальных машин или на машине оператора файловый сервер. Файловый сервер будет доступен как в физической среде, так и в виртуальной. Следовательно на него можно будет производить запись в одной среде и считывать в другой и наоборот.

В качестве задачи печати, предлагается использовать сетевые принтеры или принтеры подключенные через принт–сервер к локальной сети. Из–за того что, как мы уже установили, физическая и виртуальная сеть объединены воедино, операционная система на виртуальной машине будет " видеть" сетевой принтер или принт-сервер абсолютно идентично тому, если бы ОС стояла на физической машине, подключенной напрямую к физической сети с сетевым принтером или принт-сервером.

Доступ к виртуальным машинам будет осуществляться с терминальных машин черезтонкие клиенты с помощью протокола удаленного рабочего стола RDP.

Так же в процессе создания виртуальных машин, предлагается создать эталонную виртуальную машину, полностью настроенную, с установленным, необходимым для работы студентам с первого по последний курсы, программным обеспечением. А уже виртуальные машины для новых рабочих мест создавать путем копирования эталонной машины и изменения всего 2х параметров:

1. имени машины;

2. IP–адреса машины.

Предлагается в каждом учебном классе выделить дополнительный, ПК, с установленной на него ОС Windows и клиентом гипервизора vSphere Client, который позволит запускать группы виртуальных машин или единичные машины, тех студентов которые занимаются сейчас в классе или останавливать виртуальные машины после занятий во избежание излишней нагрузки на сервер. Также с помощью vSphere Client оператор сможет создавать новые виртуальные машины из эталонной или с нуля. А также, операторский ПК оснастить программным обеспечением для резервного копирования виртуальных машин.

Предлагается, каждому студенту создать по личной виртуальной машине. Данное решение повысит ответственность каждого студента перед своим рабочим местом, а также повысит удобство работы и надежность хранения информации. Соответственно, студент получит свою виртуальную машину на первом курсе обучения и продолжит работу с ней, до окончания обучения.

Так как нет привязки какого–либо терминала к какой–либо виртуальной машине, предлагается каждому студенту выдавать по загрузочному CD или USB диску, на который будет записан, сконфигурированный только для его виртуальной машины, тонкий клиент. Такое решение позволит также повысить безопасность подключения к виртуальной машине, а так же уберет привязку студента к какому–то определенному терминалу.

На случай забытого или утерянного/поврежденного загрузочного диска предлагается изготовить несколько дисков с универсальной конфигурацией, позволяющей подключиться к любой виртуальной машине. Такое решение не подвергнет риску чужие виртуальные машины, так как вход в систему будет защищен паролем Windows.

Структурная схема разрабатываемого учебного класса можно представлена на рисунке 2.

Рисунок 2 Структурная схема компьютерной сети кафедры с использованием сервера виртуализации

Антивирусная защита

Так как, тонкие клиенты, как правило, базируются на ядре Linux, то вирусная угроза для UNIX–подобных систем значительно ниже, чем для систем Windows. Функционал ядра крайне урезан до необходимых для работы команд, что в принципе ставит под сомнение способность запуска вируса на терминале. В добавок, накопители, подключенные к терминалу, либо " пробрасываются" до виртуальной машины, либо неактивны. То есть основные пути проникновения вирусов, в виде съемных накопителей, на терминале не доступны. Пользователь при выходе в сеть Интернет будет выходить по сути с самой виртуальной машины. Следовательно все загружаемые файлы, среди которых могут отказаться и вирусы, будут попадать исключительно на виртуальную машину.

Если терминал будет запускаться с компакт-диска, вирусная опасность терминалу не будет угрожать. Если и каким-то образом вирус и попадет в память терминала, при следующей загрузке его уже не будет, так как вирус не сможет попасть в постоянную память – записать себя на CD.

Виртуальная же машина, будет подвержена вирусной угрозе абсолютно в той же мере, что и реальный персональный компьютер. То есть вирусы могут попасть с зараженных накопителей, " проброшенных" через терминал, так и через сеть Интернет. Однако и средства защиты идентичны с персональным компьютером – установка антивирусов на каждую виртуальную машину, настройка брандмауэров.

Однако, в связи с тем, что в предложенной архитектуре присутствует достаточно большое количество виртуальных машин, то при установленном антивирусе на каждой, возникает угроза резкого увеличения трафика при обновлении сигнатур угроз каждой виртуальной машиной в отдельности.

Предлагается, выделить одну из виртуальных машин, например машину с файловым сервером, в качестве вторичного (локального) сервера для обновлений сигнатур угроз. Эта машина будет настроена таким образом, чтобы загружать на свой виртуальный диск сигнатуры из сети Интернет, а остальные виртуальные машины будут настроены на загрузку их с этого сервера обновлений.

2.3 Системные требования к аппаратной части для выбранной платформы

Для определения требований к аппаратной части необходимо первоначально определить параметры аппаратной части обыкновенного учебного класса. Усредненные параметры системного блока каждого рабочего места следующие:

1. Intel Core i3–4130; (3МБ Кэш–памяти, 3.40 ГГц)

2. 1 GB DDR3; 1133МГц;

3. Интегрированный видеоадаптер;

4. HDD 200 ГБ.

Так как сервер виртуализации позволяет перераспределять ресурсы между запущенными машинами, а приложения, выполняемые на рабочих местах находятся на достаточно низком уровне системных требований (текстовые редакторы, графические редакторы, программы для вычислений), то вполне маловероятно, что всем 20 пользователям понадобится вычислительная мощность 20 процессоров, и скорее всего, пики нагрузки на центральный процессор будут у разных пользователей в разные моменты времени, так что вполне достаточным будет использование 2х процессоров с 4-мя ядрами Xeon E5–2603; 1.80 ГГц

Оперативной памяти обычно необходимо 1024Мб или более. В отношении памяти сервер виртуализации позволяет также перераспределять ресурсы, но не стоит забывать о возможном запуске большого количества виртуальных машин, каждой из которых постоянно требуется какой–то минимальный объем. Исходя из минимальных требований в 1024 Мб и ориентировочное количество виртуальных машин в 15 штук, требуется 15360 МБ памяти.

Гипервизор имеет функцию избегания дубликатов страниц памяти. С учетом того, что на всех виртуальных машинах будет запущенна одна и та же ОС, с одинаковым набором драйверов, то неизменяемые страницы памяти будут находиться на сервере в единственном числе, что снизит потребность в объеме памяти сервера. Однако эта функция требует дополнительного тестирования на практике.

С учетом некоторой вероятности повышенного потребления памяти в виде сложных расчетов или при большом количестве запущенных виртуальных машин (возможно даже больше чем реальных рабочих мест) разумно использовать 16384МБ памяти (2048МБ x 8планок).

Обработку видеоинформации будет выполнять компьютер–терминал, так что каких–то особых требований к платформе нет.

Объем дискового пространства минимально необходимый пользователю составляет 30 ГБ. Но и в отношении дискового пространства Гипервизор позволяет осуществлять перераспределение. Пользователю будет виден и доступен тот объем, который будет указан в параметрах виртуальной машины, но на самом деле на реальном, физическом, диске будет занято столько места, сколько реально занято файлами пользователей.

Оценивая минимально необходимый объем дискового пространства, учитывая, что с первого по пятый курсы на каждом курсе есть две группы. Среднее количество человек в группе равно пятнадцати, т.е. суммарное количество студентов и виртуальных машин составляет 150. При выделении 30 ГБ на одну виртуальную машину минимальный объем дискового пространства сервера составляет 4, 5 ТБ. С учетом необходимого запаса и возможностей перераспределения места, в качестве носителя информации с виртуальными машинами предлагается использовать 2 жестких диска по 3 Tb. При нехватке места, предлагается использовать внешние сетевые хранилища данных (NAS, iSCSI).

Сам гипервизор не обязательно должен устанавливаться на одно и тоже хранилище, на котором будут размещаться файлы–образы виртуальных машин, а если учесть небольшой размер фалов гипервизора (около 150 Mb) то предлагается в качестве носителя, на который будет установлен гипервизор, использовать SSD диск ввиду низкого времени доступа к памяти, что должно благотворно сказаться на производительности.

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

Сервер виртуализации позволяет " пробрасывать", подключенное к его реальным USB портам, устройство с интерфейсом USB до виртуальной машины. Однако стоит отметить следующую особенность – " проброс" устройства возможен одновременно только для одной виртуальной машины, плюс для проброса необходимо специально настраивать в гипервизоре специальную конфигурацию оборудования. Исходя из этого, для повседневного использования " проброс" USB устройств подходит плохо. Следовательно для проброса USB устройств требуется использовать по возможности функции терминальных клиентов.

CD/DVD привод с компьютера–терминала также " пробрасывается" до вириальной машины. Однако, " проброс" CD/DVD привода, как и в случае с USB устройствами, так же возможен единовременно только для одной виртуальной машины и, также, для этого, необходимо специально конфигурировать параметры виртуальной машины. Следовательно для проброса CD/DVD привода требуется использовать по возможности функции терминальных клиентов.

Принтер наиболее целесообразно подключить через сетевой интерфейс с помощью принт-сервера и подключенного к нему принтера (либо принтера имеющего встроенный принт-сервер).

 

Резервное копирование

В качестве одного из наиболее важных средств обеспечения безопасности работы на компьютере и надежности хранения данных является резервное копирование.

Резервное копирование виртуальной инфраструктуры является неоднозначно решаемой задачей для большинства администраторов VMware ESX/ESXi. С одной стороны – виртуальные машины можно рассматривать как физические системы и делать бэкап " по старинке" с установкой агентов в гостевые ОС. С другой же стороны независимость виртуальных машин от аппаратного обеспечения серверов позволяет более гибко подходить к резервному копированию виртуальных машин на VMware ESX и пробовать различные способы бэкапа.

В процессе работы были выявлены следующие способы резервного в виртуальной инфраструктуры VMware / vSphere:

1. фреймворк VMware Consolidated Backup / vSphere Data Protection API и интеграция этих механизмов с продуктами для резервного копирования сторонних производителей (например, Symantec Net Backup или ARCserve);

2. продукт Veeam Backup, который интегрирован со средствами VMware Consolidated Backup / vSphere Data Protection API и позволяет производить не только резервное копирование ВМ на уровне образов и восстановление на уровне образов, отдельных дисков и файлов, но и делать реплики виртуальных машин на других хостах ESX;

3. создание снапшотов LUN в SAN напрямую средствами дисковых массивов или репликация томов в SAN;

4. установка агентов резервного копирования для резервного копирования на уровне файлов и ВМ целиком из гостевой ОС;

5. использование ghettoVCB;

6. продукт Acronis vmProtect 6.

 

VMware Consolidated Backup.

 

Резервное копирование данных и восстановление систем после сбоев является критически важным процессом для ИТ–инфраструктуры организации. Компания VMware предлагает простой и эффективный механизм, решающий задачи резервного копирования – фреймворк VMware Consolidated Backup (VCB).

VCB используется для создания резервных копий виртуальных машин, отдельных серверов VMware ESX Server, а также работает в совокупности со средством управления виртуальной инфраструктурой VMware Virtual Center. Поскольку VCB является всего лишь фреймворком для резервного копирования в виртуальной инфраструктуре, требуется либо использование ПО для резервного копирования сторонних производителей для автоматизации задач архивирования (которые поддерживают средства VCB), либо вручную писать сценарии командной строки, добавляя их в планировщик задач Windows.

VCB реализует следующие возможности:

1. создание архивных копий виртуальных машин посредством специального прокси–сервера VCB, который снимает нагрузку по созданию резервных копий с серверов производственной сети LAN за счет операций непосредственно в сети хранения данных SAN;

2. не требует установки дополнительных агентов на серверы ESX и в гостевые ОС;

3. предоставляет широкие возможности по интеграции с продуктами сторонних производителей средств резервного копирования. При этом поддержка многих пакетов уже встроена в VCB (а кроме того и, наоборот, эти продукты имеют VCB–поддержку). К ним относятся: Symantec Backup Exec, Veritas NetBackup, Tivoli Storage Manager, EMC Networker, CA Bright Store ARCServe, Commvault Galaxy.

На рисунке 3 представлена схема резервного копирования VCB.

Рисунок 3 Принцип работы резервного копирования VCB

На этой схеме показано то, что, поскольку виртуальные машины (то есть их виртуальные диски и файлы конфигурации) находятся на общем хранилище, есть возможность сделать мгновенный снимок файлов виртуальных дисков и скопировать их на прокси–сервер (или смонтировать тома гостевой ОС). Далее резервную копию виртуальной машины или ее файлы с прокси–сервера VCB можно скопировать на архивный носитель, например, ленточную библиотеку.

Реализуется это следующим образом – VCB заставляет ESX Server сделать снапшот виртуальной машины в то время, когда она запущена. Таким образом из одного файла виртуального диска на время получается два – один сохранил свое состояние на момент снимка, второй же накапливает все изменения виртуального диска, пока первый файл выкачивается прокси–сервером. Как только файл виртуального диска загружается на прокси–сервер, эти два файла на системе хранения снова сливаются в один.

На прокси–сервере VCB мы получаем полноценную резервную копию виртуальной машины, при этом в процессе создания копии не загружается сеть производственной среды LAN, поскольку снапшот делается на системе хранения и по Fibre Channel или iSCSI загружается на прокси–сервер. Серверы ESX также нагрузки не испытывают, поскольку все делается только на уровне хранилища, не затрагивая серверную часть, поэтому бэкап виртуальных машин можно делать в течение дня, а не только в периоды наименьшей нагрузки.

После того, как копия виртуальной машины попала на прокси–сервер VCB, ее можно отправить уже на ленточную библиотеку или другое хранилище.

 

VMware Data Recovery

Вместе с продуктом VMware vSphere 4 компания VMware выпустила также продукт VMware Data Recovery, позволяющий осуществлять резервное копирование образов виртуальных машин и их файлов, а также восстанавливать их из графического интерфейса.

Рассмотрим продукт и его связь с фреймворком VMware Consolidated Backup (VCB). Новыйпродукт, наследник VMware Consolidated Backup сталназываться VMware vStorage API for Data Protection. А продукт VMware Data Recovery стал надстройкой (GUI) над VMware vStorage API for Data Protection, которая позволяет делать бэкап из графического интерфейса с поддержкой дедупликации и восстановления виртуальных машин и их файлов.

VMware Data Recovery полностью интегрирован с VMware vCenter и управлять резервным копированием можно прямо из консоли vSphere Client. При бэкапе виртуальной машины делается ее снапшот средствами vStorage API (VCB), забирается vmdk-диск и конфигурационные файлы, данные дедуплицируются и складываются на хранилище. При этом:

1. не требуется устанавливать агентов ни на ВМ, ни на хосты VMware ESX;

2. работа виртуальной машины не прерывается (можно снимать резервную копию в течение дня).

Рисунок 4 Особенности резервного копирования VMware Data Recovery

 

Рисунок 5 Устройство архитектуры VMware Data Recovery

То есть, с точки зрения архитектуры, решения VMware Data Recovery выглядит так: специальная виртуальная машина (Virtual Appliance импортируемый на vCenter) функционирует на хосте VMware ESX и обеспечивает операции по резервному копированию виртуальных машин и их файлов (не только данного хоста ESX, но и всех остальных). На сервере же VMware vCenter установлена специальная надстройка VMware Data Recovery, которая обеспечивает управление бэкапом и восстановлением из vSphere Client. Резервные копии виртуальных машин можно хранить на хранилищах любого типа, включая CIFS/SMB ресурсы.

У резервного копирования VMware Data Recovery есть следующие особенности:

1. все резервные копии виртуальных машин подлежат дедупликации. Технология дедупликации – собственная от VMware. Поддерживается хранилище емкостью до 2 ТБ;

2. первая резервная копия делается полной, все остальные – инкрементальные;

3. для задачи резервного копирования могут быть определены следующие параметры: источник, целевое хранилище, окно резервного копирования и политика хранения по времени (retention policy). Можно управлять целевым хранилищем (Prepare, Mount, Unmount, Extend);

4. одновременно может быть запущено до 8 задач резервного копирования и восстановления.

5. при резервном копировании и восстановлении можно выбрать отдельные виртуальные диски машин;

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

7. изнутри виртуальной машины поддерживается технология VSS (Volume Shadow Service) – для получения целостных бэкапов, извне – Change block tracking для отслеживания изменившихся блоков и получения более эффективных бэкапов;

8. можно резервно копировать целые сущности vCenter, такие как Cluster или пул ресурсов;

9. присутствует поддержка шифрования целевого хранилища резервных копий;

10. один VMware Data Recovery Appliance может осуществлять резервное копирование до 100 виртуальных машин. Для резервного копирования большего количества понадобятся дополнительные Appliances;

11. каждая задача резервного копирования может иметь только один backup destination;

12. старые хосты ESX 3.5 / VC 2.5 не поддерживаются. Виртуальные машины с поколением виртуального Hardware меньше 7 необходимо обновить до седьмого для более эффективного создания резервных копий;

13. поддерживается резервное копирование типа Off–LAN, когда трафик резервного копирования идет только по SAN, не загружая сеть передачи данных;

14. VMware Data Recovery может создавать резервную копию виртуальной машины только на уровне образа (файлов vmdk), а восстанавливать может как образ целиком, так и отдельные файлы в гостевую ОС (пока поддерживается только экспериментально).

Рисунок 6 Технологически процесс резервного копирования с помощью VMware Data Recovery

VMware Data Recovery – это очень простой продукт, направленный только на сектор SMB, где критичность данных (как и квалификация администраторов) невысока и требуется лишь простейший механизм резервного копирования[12].

 

Скрипт ghettoVCB

Бесплатная альтернатива всем выше предложенным способам – ручное копирование виртуальных машин. Но, копировать руками машину каждый раз, когда нужно внедрить какое–то оборудование, или просто для сохранения данных, это безумно неудобно. Вот для этого и была разработана технология автоматизированного бэкапа, написанная энтузиастами на скриптах perl: ghettoVCB.

Данный скрипт можно свободно скачать в Интернете.

В данном примере представлено самое простейшее резервное копирование с помощью этого скрипта, без использования особых конфигураций, для резервного копирования одной виртуальной машины в локальное хранилище ESXi хоста.

1. загружается скрипт ghettoVCB.sh;

2. скрипт передается на ESXi хост;

3. далее необходимо подключиться по SSH к хосту;

4. скрипт распаковывается на хосте;

5. при необходимости, скрипт исправляется под требуемые настройки;

6. создается файл vms_to_backup, в котором прописываются имена виртуальных машин, которые необходимо забэкапить;

7. запускается команда./ghettoVCB.sh –f vms_to_backup.

После этого создание резервной копии виртуальной машины завершено.

Упрощенный принцип работы скрипта заключается в следующем: Создается снапшот виртуальной машины. Далее на основе этого снапшота создается копия виртуальной машины, которая кладется в указанное в настройках место. Снапшот удаляется.

Пример восстановления виртуальной машины:

1. загружается скрипт ghettoVCB–restore.sh;

2. скрипт передается на ESXi хост;

3. далее необходимо подключиться по SSH к хосту;

4. скрипт распаковывается на хосте;

5. создается файл vms_to_restore, в котором указывается перечень восстановления в следующем формате: [Полный путь к бэкапу][Путь к хранилище куда происходит восстановление][Тип диска];

6. запускается команда./ghettoVCB–restore.sh –c vms_to_restore.

В итоге будет запущена процедура восстановления. Особенности данного скрипта заключаются в следующем – для того чтобы выполнить восстановление необходимо удалить виртуальную машину. При желании, скрипт можно сконфигурировать, указав следующие параметры:

1. директорию создания бэкапов;

2. формат сохраняемого диска, возможны варианты: zero ed thick, eager zero ed thick, thin, 2gbsparse;

3. количество бэкапов на одну машину (каждый последующий будет удаляться скриптом). Если, например, скрипт будет бэкапить машины каждый час, то при указании числа 24, мы получим бэкапы каждый час на протяжении одного дня;

4. требуется ли отключение машины перед бэкапом;

5. формат диска машины (возможны: buslogic, lsilogic);

6. сохранение на удаленном сервере;

7. отправка логов по работе скрипта на почту [13].

 

Acronis vmProtect 6

 

Acronis vmProtect 6 использует программный интерфейс VMware vStorage API for Data Protection (VCB), чтобы обеспечить резервное копирование и восстановление без установки дополнительных агентов для виртуальных машин на один или несколько хост-серверов ESXi в удаленном режиме. Использование агентов на виртуальных машинах не требуется.

С помощью Acronis vmProtect 6 возможно использовать следующие варианты восстановления:

1. восстановление виртуальной машины целиком поверх уже существующей виртуальной машины или в виде новой виртуальной машины на любой хост–сервер ESX/ESXi;

2. восстановление отдельных файлов или папок для поддерживаемых гостевых файловых систем;

3. монтирование носителя с резервной копией к хост-серверу ESX/ESXi в качестве NFS–ресурса и запуск виртуальной машины напрямую из резервной копии, что обеспечивает почти мгновенное восстановление.

Acronis vmProtect 6 Windows Agent устанавливается на выделенную Windows–машину и берет на себя часть операций по резервному копированию и восстановлению с основных хост–серверов ESXi.

Acronis vmProtect 6 предназначен для поддержки постоянно–инкрементного режима, в котором более старые инкрементные резервные копии можно удалять для освобождения места под новые резервные копии без необходимости в консолидации, требующей значительного объема ресурсов, а использование технологии VMware Change Block Tracking (CBT) обеспечивает достаточно высокий уровень скорости инкрементного резервного копирования.

Для общих хранилищ, таких, как сети хранения данных SAN, vmProtect 6 может считывать данные напрямую через сеть хранения данных, выполняя резервное копирование в обход локальной сети.

Acronis vmProtect 6 детально рассматривает содержимое дисков и томов, чтобы проанализировать файловую систему и перенести в резервную копию только те блоки, которые фактически заняты данными вместо копирования виртуальных дисков целиком в виде файлов (.vmdk). Благодаря этому vmProtect 6 создает резервные копии быстрее и меньшего размера по сравнению с альтернативными решениями, когда происходит полное копирование файлов–образов виртуальных машин.

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

Acronis vmProtect 6 может восстанавливать элементы на уровне отдельных файлов из резервной копии виртуальной машины для всех основных файловых систем в Windows и Linux. Так же присутствует возможность исключать отдельные файлы и папки/каталоги из резервной копии виртуальной машины, чтобы уменьшить объем занимаемого места в хранилищах и сократить длительность резервного копирования.

В качестве управления Acronis vmProtect 6 используется интуитивно понятный веб–интерфейс. Доступная через веб–браузер, панель мониторинга Acronis vmProtect 6 предоставляет наглядный сводный обзор всех действий по резервному копированию и восстановлению, а также их статусов. Возможно настроить уведомление по электронной почте, таким образом, чтобы информировать администратора об успехе или неудаче операций, а также о любых новых предупреждениях.

Лицензия на Acronis vmProtect 6 покупается исходя из количества ЦП на сервере виртуализации. То есть, лицензия не ограничивает количество виртуальных машин, подлежащих бэкапу, занимаемое ими пространство или ресурсы, и не ограничивает свое действие по времени. Так же возможно подписание годового соглашения на хранение бэкапов в облачном хранилище Cloud Storage. Хранилище позволяет в любой момент времени, при наличии связи с сетью Интернет, загрузить новые бэкапы или произвести восстановление виртуальных машин с сетевого хранилища предоставляемого компанией Acronis.

Из рассмотренных вариантов резервного копирования предлагается использовать:

1. в качестве бесплатного решения скрипт ghettoVCB из–за его малых размеров, гибких возможностей конфигурирования и авторитетного признания многими системными администраторами VMware ESXi. Из недостатков можно отметить не совсем удобное конфигурирование, в виде текстовой правки самого скрипта, что отражается на удобстве пользования, особенно при необходимости смены настроек;

2. в качестве более удобного, в плане управления и использования, однако платного решения, предлагается использовать Acronis vmProtect 6. Выбор аргументирован в связи с относительно не высокой стоимостью лицензирования и отсутствия ее временного ограничения, удобными возможностями управления, технологиями позволяющими снизить объем занимаемый бэкапами [14].

 

⇐ Предыдущая1234Следующая ⇒

Поделиться: