Следующим логическим уровнем являются внешние сети (Exter­nals net­work). Этот сегмент инфраструктуры под контролем администратора vCD. По сути это выход во внешний (относительно организации) мир, например в Интернет или на территорию заказчика по средствам VPN. К внешним сетям подключаются сети организаций и тут как и в случае с vApp есть варианты зависящие от уровня привилегий.

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

Администратору vCD кроме описанных выше доступен еще один вариант, позволяющий подключить сеть организации к внешней сети на прямую, как часть ее сегмента. При соответствующей настройки сетей vApp это практически позволит на прямую взаимодействовать ВМ с внешним миром.

С уровеня vSphere то все эти сети являются обычными группами портов (Port­group) виртуального коммутатора vSwitch, Dis­trib­uted vSwitch или же Nexus 1000V часто отличающиеся лишь VLAN id и способом коммутации с физическими интерфейсами.

6. Виртуальные системы и приложения.

Виртуальные системы и ISO образы хранятся в каталогах и представлены как объекты каталога. Виртуальные системы хранятся в виде шаблонов, используя открытый стандартный формат OVF (1.0). Эти шаблоны могут быть получены по каталогам и преобразованы в виртуальные системы и приложения, называемые vApps, посредством проведения процесса создания экземпляров, который связывает требования абстрактных ресурс шаблона с доступными в VDC ресурсами.

НЕ нашли? Не то? Что вы ищете?

vApp содержат один или более индивидуальных виртуальных машин (ВМ), вместе с параметрами, которые определяют различные возможности и детали, в том числе:

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

На уровне vCD отсутствует понятие виртуальной машины как самой по себе здесь используется концепция vApp - виртуальных приложений. Т. е. vApp это группа ВМ, вместе выполняющих некую задачу и не обязательно, но обычно работающие в одной под сети одного сегмента (VLAN). Например сервер баз данных и подключенный к нему веб-сервер обрабатывающий некое веб-приложение является классическим примером vApp. Эти ВМ в идеале действуют как единое целое. Так же на уровне vApp могут быть определены особые правила сетевого взаимодействия между ВМ и отличный от других vApp способ связи с внешним миром. Даже если необходима просто отдельно стоящая ВМ то сперва нужно создать vApp и лишь «внутри» него появится возможность разместить ВМ.

2.2. vCloud Director Cell


vCloud Director Cell – компонент сопряжения, обеспечивающий связь между vCenter Server, vShield Manager и ESX/ESXi хостами.

vCloud Director Cell может быть развернут и запущен на ОС Red Hat Enterprise Linux Server и позволяет запускать облачный портал вебсервера  для вебконсоли vCD.

Для корректной работы компонента vCloud Director Cell  необходимо наличие:

    Физического сервера на виртуальной машине. LDAP сервера для удобства пользовательского управления. SMTP сервера для поддержки механизма уведомлений. Компонента vCD work file system server (NFS) для работы VMware vSphere и vAPP

Модель использования компонента vCloud Director Cell приведена на рис.2.7.

Рис. 2.7. Модель использования компонента vCloud Director Cell

На базе данной модели (рис.2.7.) показано взаимодействие vShield Edge, vCenter и vCD Cell. Общий вид сценария использования vCloud Director Cell приведен на рис. 2.8.

Рис. 2.8. Общий вид сценария использования vCloud Director Cell

Структурная схема архитектуры vCloud Director Cell приведена на рис.2.9.

Рис. 2.9. Стуктурная схема архитектуры vCloud Director Cell

2.3. NFS Server


NFS абстрагирован от типов файловых систем как сервера, так и клиента, существует множество реализаций NFS-серверов и клиентов для различных операционных систем и аппаратных архитектур. Наиболее свежая версия NFS поддерживающая различные средства аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов).

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

NFS-клиенты получают доступ к файлам на NFS-сервере путём отправки RPC-запросов на сервер. Это может быть реализовано с использованием обычных пользовательских процессов — а именно, NFS-клиент может быть пользовательским процессом, который осуществляет конкретные RPC-вызовы на сервер, который так же может быть пользовательским процессом.

Для клиента одинаково представлены локальные и NFS-файлы, ядро определяет, когда файл открыт.

NFS-клиент отправляет RPC-запросы NFS-серверу через стек TCP/IP. NFS обычно использует UDP, однако более новые реализации могут использовать TCP.

NFS-сервер получает запросы от клиента в виде UDP-датаграмм на порт 2049. Несмотря на то, что NFS может работать с преобразователем портов, что позволяет серверу использовать динамически назначаемые порты, UDP-порт 2049 жёстко закреплен за NFS.

Когда NFS-сервер получает запрос от клиента, он передается локальной подпрограмме доступа к файлу, которая обеспечивает доступ к локальному диску на сервере.

Серверу может потребоваться время, для того чтобы обработать запросы клиента. Даже доступ к локальной файловой системе может занять некоторое время. В течение этого времени сервер не хочет блокировать запросы от других клиентов, которые также должны быть обслужены. Чтобы справиться с подобной ситуацией, большинство NFS-серверов запускаются несколько раз, то есть внутри ядра существует несколько NFS-серверов. Конкретные методы решения зависят от операционной системы. В большинстве ядер Unix-систем не используется несколько NFS-серверов, вместо этого запускается несколько пользовательских процессов (которые обычно называются nfsd), которые осуществляют один системный вызов и остаются внутри ядра в качестве процесса ядра.

NFS-клиенту требуется время, чтобы обработать запрос от пользовательского процесса на узле клиента. RPC выдается на узел сервера, после чего ожидается отклик. Для того, чтобы пользовательские процессы на узле клиента могли в любой момент воспользоваться NFS, существует несколько NFS-клиентов, запущенных внутри ядра клиента. Конкретная реализация также зависит от операционной системы. Unix-система обычно использует технику, напоминающую NFS-сервер: пользовательский процесс, называемый biod, осуществляет один единственный системный вызов и остается внутри ядра как процесс ядра.

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

1. Тонкое резервирование.

Виртуальные диски (VMDK), созданные на базе NFS хранилищ данных уже включают механизмы тонкого резервирования. Эта возможность предлагает лучшее использование дискового пространства на основе регулярного мониторинга и свбодного дискового пространства, т. е. VMware определяеть неиспользуемое но распределенное дисковое пространство. Реализованная технология динамического отслеживания и выделения памяти удаляет значительное количество неиспользуемого дискового пространства.

Для NFS хранилищ данных, формат виртуального диска по умолчанию является тонким. Таким образом, выделение менешего объема памяти, чем необходимо для того же набора виртуальных дисков, который предусмотрен для толстого формата резервирования. При этом, тонкий формат виртуальных дисков дополнительно может быть интегрирован в блок на основе хранилищ данных VMFS. VMware vCenter  обеспечивает поддержку создания тонких виртуальных дисков и мониторинга хранилища данных (т. е. может реализовать систему оповещения).

2. Дедупликации

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

3. Резервное копирование и восстановление

Резервное копирование с помощью NFS можно реализовать несколькими способами. Некоторые общие методы: размещение агентов в каждой гостевой ОС, использование массивов данных на основе технологии моментальных снимков. Тем не менее, процесс восстановления виртуальной машины является более сложным, т. к. на практике часто существует множество уровней детализации, запрошенные сервером для восстановления.        Некоторые решения способны восстановить все хранилище данных, а другие могут реплицировать только определенную виртуальную машину или виртуальный диск для виртуальной машины. Использование NFS массива на основе снимков имеет наибольшую легкость и гибкость благодаря тому, что данные любой детализации  могут быть восстановлены. С массива на основе снимка в хранилище NFS, можно быстро смонтировать копию всего NFS хранилища, а затем выборочно извлекать любой уровень детализации.

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9