понедельник, 25 января 2010 г.

Варианты размещения swap файлов виртуальных машин в ESX/ESXi 4.0

Как должно быть многим из вас известно, при старте виртуальной машины VMware, узел ESX резервирует определенный объем дискового пространства в виде файла подкачки (swap файла) равного по размеру объему оперативной памяти, отведенной этой машине. При превышении объема доступной физической памяти (Memory overcommitment), узел может переместить часть страниц оперативной памяти этой машины на жесткий диск в swap файл(host swaping).

По-умолчанию, swap файл всегда размещается в той же директории, что и конфигурационный файл (.vmx) виртуальной машины. Однако, начиная с ESX/ESXi 3.5 появилась возможность указать хранилище для размещения swap файлов (local swap datastore). Несмотря на слово local, присутствующее в названии, никто не мешает указать в качестве места расположения swap файлов общее FC или iSCSI хранилище или NFS папку, как, впрочем, и локальные диски узла ESX.

Изменение расположения swap файла преследует две цели:

  1. Экономия места на хранилище виртуальных машин. Часто виртуальные машины располагаются на дорогом и производительном FC или iSCSI хранилище, в то время, как локальные диски ESX практически пустуют. Перенеся swap файлы, мы получим дополнительное место на хранилище, позволив тем самым разместить на нем больше виртуальных машин или большие виртуальные диски.
  2. Увеличение производительности. Если нет Memory Overcommitment, то наличие swap файлов практически не сказывается на производительности хранилища. Однако, при большом потреблении памяти и активном использовании swap файлов, вы можете использовать отдельный LUN или вообще использовать отдельное хранилище, для того, чтобы снизить нагрузку на основное хранилище. Кроме того, во многих серверах установлены вполне производительные контроллеры, которые обеспечат неплохую производительность чтения/записи, когда это потребуется. Наконец, под swap можно и SSD накопитель приспособить.
На одном узле ESX под swap можно выбрать только одно единственное хранилище. При этом, все swap файлы будут размещаться в корне.

Указать место расположения swap файлов виртуальных машин для одиночного узла ESX можно из вкладки Configuration -> Virtual Machine Swapfile Location.
При необходимости вы можете поменять место расположения swap файла для отдельных виртуальных машин, отредактировав их настройки:
Для HA/DRS кластера вы должны вначале изменить политику на уровне всего кластера и только после этого сможете задать swapfile datastore для отдельных узлов.
Учтите, что при перемещении машины с помощью VMotion в случае, когда узел назначения не может получить доступ к хранилищу, где размещается swap файл (например, при размещении swap файла на локальных дисках узлов), в процессе миграции swap файл будет скопирован в новое место (local swap datastore узла назначения или папку виртуальной машины). Это может привести к тому, что операция VMotion займет больше времени, пока по сети будет копироваться swap файл, а в случае с ESX 3.0 - к невозможности использования VMotion, до тех пор, пока swap файл не будет помещен туда, где узел ESX сможет до него 'дотянуться'.

понедельник, 18 января 2010 г.

Обзор Symantec Backup Exec System Recovery 2010

Что может быть печальнее, чем вышедший из строя почтовый сервер? Только сервер, на котором крутились виртуальные машины с почтовым сервером, контроллером домена, файловым сервером и базами какого-то там 1C. Конечно, можно и нужно всяческими силами стараться предотвратить эту неприятную ситуацию, но можно и подготовиться к ней, чтобы смягчить неприятные (а для кого-то и болезненные) последствия.


Сегодня только ленивый производитель средств резервного копирования данных не снабдил свои продукты поддержкой виртуальных сред. И монстрообразные, вроде HP Data Protector или Symantec NetBackup, и специализированные, вроде Veeam Backup & Replication обеспечивают необходимый функционал по резервному копированию и восстановлению виртуальных машин. Чем же на фоне большого количества конкурирующих, да и собственных решений Symantec отличается Backup Exec System Recovery 2010?

Backup Exec System Recovery позиционирует как решения для малого бизнеса, но имеет в запасе много интересных функций таких, как: GRT (Granular Recovery Technology), позволяющей восстанавливать отдельные объекты: письма и папки почтового сервера Exchange (поддерживается Exchange Server 2010), документы SharePoint или файлы и директории из резервной копии диска; позволяет монтировать резервные копии в качестве томов для быстрого поиска и восстановления нужных данных; обладает возможностью конвертирования резервных копий в виртуальные диски .vmdk или .vhd. В случае поломки сервера вы можете восстановить резервную копию на новое оборудование (bare-metal recovery), загрузившись со специального образа. Среди поддерживаемых ОС присутствуют Windows 7 и Windows Server 2008 R2.

При этом, как продукт начального уровня, в настройке и управлении Symantec Backup Exec System Recovery крайне прост.

Ниже будет приведено небольшое описание настройки процедуры резервного копирования сервера и конвертирования получившейся резервной копии в виртуальный диск.

Установка продукта
Для тестирования вы можете воспользоваться trial версией продукта, доступной по ссылке.

Запустите установку с помощью файла setup.exe из дистрибутива Symantec Backup Exec System Recovery 2010 и нажмите Install Now.

Примите лицензионное соглашение, выберите вариант установки по-умолчанию (Install Now) или укажите путь и выберите необходимые компоненты вручную (Custon Install).
После завершения установки система предложит перезагрузиться.

При первом запуске Backup Exec System Recovery 2010 запустит небольшой мастер и предложит ввести лицензионный ключ (либо продолжить использовать триальную версию), а также обновить компоненты системы при помощи Symantec Live Update.

Установка агента
Для резервного копирования сервера с помощью Symantec Backup Exec System Recovery требуется предварительно установить на сервер агент. Сделать это можно локально, используя дистрибутив, либо удаленно с помощью консоли, нажав на панели управления Computer -> Add.
В окне Add remote computer укажите DNS имя или IP адрес удаленного сервера и нажмите OK.
Если агент не установлен на удаленном сервере, консоль выведет окно с ошибкой о невозможности подключения. Выберите вариант Deploy agent (на удаленном сервере должен быть разрешен доступ по протоколам RPC и SMB). Система запросит у вас учетные записи пользователя от имени которого будет запущена установка.
Если у вас включен Windows Firewall, то после завершения установки, настройте брандмауэр на удаленном сервере, создав правило для программы Backup Exec. По-умолчанию, агент устанавливается в папку:
"C:\Program Files (x86)\Symantec\Backup Exec System Recovery\Agent\VProSvc.exe" для x64 систем
"C:\Program Files\Symantec\Backup Exec System Recovery\Agent\VProSvc.exe" для x86 систем.
В консоли управления нажмите Reconnect для повторения попытки подключения к удаленному серверу.

Теперь вы сможете переключаться между разными агентами в меню Computers на панели управления.
Создание резервной копии
Для управления заданиями на резервное копирование нажмите Run on Manage Backups на вкладке Home или Tasks.

Создать новое задание можно через мастер Define Backup Wizard, нажав Define New.
На стартовой странице мастера нажмите Next.

На странице Drives укажите один или несколько дисков (зажав Ctrl), которые требуется забекапить. Переключатель Show Hidden Drives покажет скрытые разделы, например системный раздел в ОС Windows 7/Windows Server 2008 R2. Нажмите Next.
На странице Recovery Point Type укажите тип резервных копий - инкрементальные (Recovery point set), сохраняющие только изменения с момента последней полной резервной копии или полные (Independent recovery point). Нажмите Next.

На странице Backup Destination укажите папку, в которой будут размещаться резервные копии. При размещении копий в сетевой папке, с помощью кнопки Edit вы можете задать учетные данные пользователя, которые будет использовать агент резервного копирования.
Вдобавок вы можете настроить агента на сохранение резервных копий сразу в нескольких местах (Offsite Copy), например, одновременно на локальном диске резервируемое сервера, сетевой папке и съемном носителе. Нажмите Next.

На странице Options вы можете задать дополнительные настройки связанные с заданием на резервное копирование: проверку целостности резервной копии после создания (Verify recovery point after creation), глубину хранения резервных копий (Limit the number of recovery point sets...), защищать резервную копию паролем и шифровать ее (Advanced -> Security Options) настраивать выполнение сценариев до и после выполнения резервного копирования (Command Files...). После задания необходимых настроек, нажмите Next.
На странице Backup Time вы можете настроить расписание резервного копирования, частоту создания контрольных точек (recovery point set - полных резервных копий при инкрементальном копировании), а также дополнительные события, при наступлении которых будет запускаться задание на резервное копирование (Event Triggers), например: установка/удаление приложения, рост объема данных на определенное значение и д.р. Нажмите Next.
На финальной странице вы можете запустить задачу на резервное копирование (run backup now) сразу после завершения мастера.

Проверить текущий прогресс создания резервной копии вы можете из меню View -> Progress and Performance в окне Run or Manage Backups.
Конвертирование резервной копии
Symantec Backup Exec System Recovery позволяет конвертировать архив с резервной копией в виртуальный диск. Эта возможность может пригодиться для P2V миграции серверов или для создания постоянно обновляемых реплик виртуальных машин на резервном сервере виртуализации. Процесс конвертирования можно запустить однократно или настроить задание по расписанию для создания постоянной синхронизирующейся копии.
Поддерживаются форматы виртуальных дисков .vmdk (для VMware Workstation, VMware Server и VMware ESX) и .vhd (для Microsoft Virtual PC, Microsoft Virtual Server, Microsoft Hyper-V и Citrix XenServer). В случае VMware ESX вы можете не только конвертировать диск, но и скопировать его сразу на удаленный сервер. Процесс создания задания конвертирования схож с процессом создания задания на резервное копирование.

Для VMware ESX: на вкладке Tasks нажмите Run or Manage Virtual Conversions. В открывшемся окне нажмите Define New.

На первой странице Welcome to the Define Virtual Conversion выберите формат, в который требуется конвертировать диск. Нажмите Next.
На странице Source укажите путь к файлу .sv2i резервной копии. Выберите диски, которые требуется восстановить из бекапа. Нажмите Next.
На странице Virtual Disk Destination введите DNS имя или IP адрес ESX сервера, а также учетные данные для подключения. С помощью кнопки Browse укажите путь, где будут размещаться виртуальные диски. При желании, каждый раздел вы можете разместить на отдельном виртуальном диске (Create one virtual disk per volume). Нажмите Next.
На странице ESX Options задайте временную папку для размещения сконвертированных .vmdk дисков. Нажмите Next.

На странице General Options задайте имя для задания, а также укажите, требуется ли выполнить мини-установку с использованием файла ответов при первой загрузке виртуальной машины. Нажмите Next.

На странице Conversion Time настройте расписание для задания. Нажмите Next.
На финальной странице вы можете запустить задачу на конвертирование (Run virtual conversion now) сразу после завершения мастера.

После завершения процесса конвертирования, .vmdk файл будет скопирован на сервер ESX и удален из временной папки. Единственным неприятным моментом является то, что диск создается в Thick формате, что в некоторых случаях может быть не очень удобно и практично.

Заключение
Symantec Backup Exec System Recovery 2010 является отличным средством резервного копирования для небольших компаний и позволяет делать резервные копии всего сервера целиком, защищать почтовые базы Microsoft Exchange и документы SharePoint, а также автоматизировать процесс создания актуальных реплик для ваших серверов в виртуальной среде.

С другой стороны, многим может показаться недостатком необходимость установки агента Backup Exec на каждый защищаемый сервер (физический или виртуальный). Хотя, при приобретении лицензии Symantec Backup Exec System Recovery Virtual Edition на сервер виртуализации, вы получаете возможность защищать неограниченное количество виртуальных машин на этом сервере.

среда, 30 декабря 2009 г.

Ограничения при управлении хостами ESX из SCVMM

Microsoft позиционирует System Center Virtual Machine Manager 2008 R2 как продукт для централизованного управления инфраструктурой виртуальных машин. Одной из особенностей SCVMM 2008 R2 является возможность работы с хостами VMware ESX. Однако, существует ряд ограничений, о которых должны знать администраторы перед тем, как решиться на подобную интеграцию.

1) Для управления хостами ESX/ESXi вам потребуется VMware vCenter. SCVMM не управляет хостами напрямую, а использует для этого функционал, схожий с тем, который vCenter предоставляет через Web Access.

2) SCVMM поддерживает ESX 3.0/ESXi 3.5 и выше, в том числе ESX/ESXi 4.0 U1, однако все новые функции vSphere - Fault Tolerance, Host Profiles, VMDirect Path, Distributed Switches, Thin Disks, vShield Zones не поддерживаются.

3) Через консоль SCVMM вы не можете создавать и настраивать Resource Pools и кластеры VMware HA и DRS, создавать и настраивать сетевые подключения для Service Console и VMKernel, изменять настройки DPM, настраивать iSCSI, Fibre Channel или NFS, добавлять, расширять и просматривать хранилища.

4) Перед использованием шаблонов машин VMware, вам потребуется импортировать их в библиотеку SCVMM. Customization Specification не поддерживается. Аналогично, для подключения ISO образов требуется также перенести их в библиотеку.

5) При создании новой виртуальной машины из SCVMM, она автоматически создается с Virtual Machine version 7; вы не можете указать/изменить тип сетевой карты и SCSI контроллера. Кроме того, требуется принудительно поменять тип подключения диска с IDE на SCSI, даже если вы используете ESX 4.0.

6) SCVMM имеет собственный журнал событий/операций, с помощью SCVMM вы не можете просматривать Alerts от ESX/vCenter и настраивать задания по расписанию.

7) При переводе хоста ESX в Maintenance Mode с помощью vCenter, в консоли SCVMM информация о состоянии хоста не изменится, однако, ни запустить, ни изменить свойства виртуальных машин вы не сможете.

8) Встроенный Physical Server Convert не позволяет делать P2V миграцию на узлы ESX.

9) Многие функции по управлению VI/vSphere реализуются через плагины к VIC/vSphere Client, поэтому консоль SCVMM их не поддерживает.

Из всего вышеперечисленного складывается ощущение, что SCVMM крайне ограниченно подходит для управления инфраструктурой VMware. С другой стороны, он может пригодиться в случаях, когда вы планируете перевод вашей виртуальной инфраструктуры с одной платформы на другую, например, чтобы иметь возможность мигрировать машины с VMware Infrastructure на Hyper-V, либо, наоборот, чтобы ваши администраторы, привыкшие к SCVMM, могли более плавно адаптироваться к vSphere.

четверг, 17 декабря 2009 г.

Настройка Hyper-V Server R2 Failover Cluster из командной строки (Часть II)

Сегодня продолжим наши эксперименты с Hyper-V из командной строки. В предыдущей части я рассказал о настройках на узле Hyper-V. На очереди самое интересное - создание кластера.


Настройка кластера
Для создания кластера введите:
cluster /cluster:<ИМЯ_КЛАСТЕРА> /create /node:<ИМЯ_УЗЛА> /ipaddress:<АДРЕС_КЛАСТЕРА>
, где <ИМЯ_КЛАСТЕРА> - имя, по которому можно будет обращаться к кластеру;
<ИМЯ_УЗЛА> - имя узла, входящего в кластер
<АДРЕС_КЛАСТЕРА> - IP адрес и маска подсети для кластера в полном или сокращенном формате (например 192.168.10.13/24 или 192.168.10.13/255.255.255.0)

Теперь можно полюбоваться на кластер, набрав:
cluster /list

и посмотреть список доступных ресурсов:
cluster res

Как видите в списке отсутствуют дисковые ресурсы, поэтому придется добавлять их вручную. При создании кластера Windows Server 2008 настраивает две группы для размещения ресурсов: Cluster Group и Available Storage. Увидеть доступные группы можно с помощью команды:
cluster group
По-умолчанию, все дисковые ресурсы размещаются в группе Available Storage. Исключение составляет только диск, предназначенный для кворума - он будет помещен в группу Cluster Group. Создадим новый дисковый ресурс:
cluster res "<ИМЯ_РЕСУРСА>" /create /group:"Cluster Group" /type:"Physical Disk"
, где <ИМЯ_РЕСУРСА> - произвольное имя
После создания дискового ресурса требуется сопоставить его с физическим диском. В Windows Server 2003 у ресурса physical disk был параметр Drive, соответствующей букве физического диска. В Windows Server 2008 синтаксис команды изменился, и теперь вместо Drive используется параметр DiskSignature. Для определения DiskSignature нам потребуется воспользоваться Diskpart.

После запуска Diskpart выберите нужный диск и выполните:
detail disk
В свойствах найдете нужный параметр Disk ID, представляющее собой шестнадцатиразрядное число. Для дальнейшего использования требуется перевести
это число в десятичный формат и затем выполнить команду, подставив в качестве значения параметра DiskSignature:
cluster res "<ИМЯ_РЕСУРСА>" /priv DiskSignature=<ID_ДИСКА>
Кстати о конвертировании - в Powershell есть встроенный преобразователь типов:
[Convert]::ToInt32("<16-РАЗРЯДНОЕ_ЧИСЛО>", 16)
Теперь переведем ресурс в активное состояние.
cluster res "<ИМЯ_РЕСУРСА>" /on
Проделаем аналогичные операции для второго диска:
Теперь требуется указать кластеру, где размещать кворум (в качестве примера, кластер будет работать в режиме Node and Disk Majority):
cluster /quorum:"<ИМЯ_РЕСУРСА>"
Настройка Cluster Shared Volume
Как и в случае с работой из GUI, перед преобразованием диска в CSV, вам потребуется включить поддержку CSV на кластере:
cluster /prop EnableSharedVolumes=1
Запустите Powershell. Добавьте модуль для поддержки работы с кластером:
Import-Module FailoverClusters
Добавление CSV выполняется командой:
Add-ClusterSharedVolume "<ИМЯ_РЕСУРСА>"
Добавление второго узла в кластер
Остались последние штрихи - добавить еще один узел в кластер Hyper-V. Все настройки на втором узле - конфигурация IP, ввод в домен, iSCSI Initiator выполняются аналогичным образом, поэтому я не буду заострять на них внимание.

Когда второй узел будет готов, добавьте его в кластер командой:
На этом настройка кластера завершена. Вам осталось развернуть или скопировать виртуальные машины и запустить их.

За бортом осталось описание создание/добавление виртуальных машин в кластер и работа с ними из командной строки. Не исключено, что этому я посвящу отдельную статью.

Материалы
При подготовке статьи использовались следующие материалы:
  1. Q. How can I change a Windows Server 2008 cluster quorum from the command line?

вторник, 8 декабря 2009 г.

Настройка Hyper-V Server R2 Failover Cluster из командной строки (Часть I)

Готовясь к сертификации по Windows Server 2008, я решил более обстоятельно поработать с SCVMM 2008 R2 и Hyper-V R2. Среди прочих задач захотелось поднять двухузловой отказоустойчивый кластер. Вот только его настройка из оболочки sconfig и оснасток MMC показалась мне довольно тривиальной, поэтому решил выполнить аналогичные операции, используя только лишь командную строку.

Схему организации кластера выбрал самую простую:

Один контроллер домена (W2K8-DCS01), один сервер, выполняющий роль iSCSI Target (W2K8-STR01), два узла Hyper-V Server R2 (W2K8-HYP01 и W2K8-HYP02) с двумя сетевыми адаптерами: один - для доступа к узлам, работы с виртуальными машинами, а также подключения к iSCSI Target'ам, второй - для передачи heartbeat. Кворум предполагается размещать на одном LUN'е (Quorum), презентованном по iSCSI, раздел для хранения виртуальных машин - на втором (Storage).


Первоначальная настройка
Перед тем, как начать собирать кластер, потребуется выполнить настройку сети на сервере Hyper-V.

Закрываем неприглядное окно sconfig'а, на передний план выходит cmd.

Сначала включим несколько дополнительных компонентов (службы кластера, PowerShell и Framework для него):
dism /online /enable-feature /featurename:FailoverCluster-Core
dism /online /enable-feature /featurename:NetFx2-ServerCore
dism /online /enable-feature /featurename:MicrosoftWindowsPowerShell


Они понадобятся нам на более поздних этапах настройки.

Кстати, получить список доступных (активных/неактивных) компонентов можно с помощью команды:
dism /online /get-features


С помощью netsh настроим сетевые подключения. Сначала узнаем имена, которые система назначила сетевым адаптерам:
netsh interface show interface

В моем случае адаптер "Local Area Network" подключен к общей сети, адаптер "Local Area Network 3" к частной (heartbeat). Исходя из первоначального плана, назначаем адреса, маски, DNS, Default Gateway:
netsh interface ipv4 set address "Local Area Connection" static 192.168.10.11 255.255.255.0 192.168.10.254
netsh interface ipv4 set dnsserver "Local Area Connection" static 192.168.10.1 primary
netsh interface ipv4 set address "Local Area Connection 3" static 10.0.0.1 255.255.255.252


Без RDP может быть скучно, поэтому включим и его:
Cscript.exe "C:\Windows\System32\Scregedit.wsf" /AR 0

И разрешим подсоединятся старым RDP клиентам:
Cscript.exe "C:\Windows\System32\Scregedit.wsf" /CS 0

Хотя, мне больше нравится удаленно управлять сервером с помощью WinRM.

Перед присоединением сервера к домену, изменим его имя на что-то более благозвучное:
netdom renamecomputer %computername% /newname <НОВОЕ_ИМЯ_СЕРВЕРА>

Перезагрузим сервер:
shutdown -r -t 00

Добавим сервер в домен:
netdom join %computername% /domain:<ИМЯ_ДОМЕНА> /userd:<УЧЕТНАЯ_ЗАПИСЬ> /passwordd:<ПАРОЛЬ>

и снова перезагрузим сервер.

Подключение дисков
Перед созданием кластера нам понадобится настроить iSCSI Initiator чтобы получить доступ к презентованным дискам. Сделать это можно в несколько щелчков мыши, запустив графическую настройку iscsicpl.exe.

Однако, мы не ищем легких путей, поэтому будем настраивать все из командной строки. :)

По-умолчанию служба iSCSI Initiator выключена, поэтому для начала запустим ее:
net start msiscsi

А чтобы не повторять эту операцию каждый раз при загрузке сервера вручную настроим ее на автоматический старт:
sc config msiscsi start= auto

На очереди сама консольная утилита - iscsicli. С ее помощью и настроим iSCSI Initiator на узле. Подключимся к iSCSI Target серверу:
iscsicli qaddtargetportal <ИМЯ_СЕРВЕРА>
, где <ИМЯ_СЕРВЕРА> - имя или IP адрес iSCSI хранилища.

Посмотрим на список доступных целей:
iscsicli listtargets

Подключимся к обоим целям:
iscsicli qlogintarget <IQN>
, где <IQN> - IQN целей, к которым требуется подключиться

а также сделаем так, чтобы они автоматически подключались после перезагрузки сервера:
iscsicli persistentlogintarget <IQN> t * * * * * * * * * * * * * * * 0


Разбиение дисков
Теперь потребуется создать отформатировать разделы на подключенных дисках. Сделать это можно с помощью консольной утилиты Diskpart.

Запустим Diskpart и посмотрим на подключенные диски:
list disk
Выберем первый диск, создадим и отформатируем на нем раздел под кворум:
select disk 1
create partition primary
format fs=ntfs label="Quorum" quick


аналогичные операции выполним для второго диска под хранилище виртуальных машин:
select disk 2
create partition primary
format fs=ntfs label="Storage" quick


Заключение
На этом первая часть завершена. В следующий раз я опишу процесс настройки самого кластера и подключения второго узла. До встречи!

Материалы
При подготовке статьи использовались следующие материалы:
  1. Сделай сам: стенд с решениями для виртуализации — настройка узлов кластера для использования общего хранилища

вторник, 1 декабря 2009 г.

Домашний сервер All-In-1 в качестве тестового полигона

Сегодняшнее повествование будет несколько отличаться от привычных вам статей на VM Press. Не будет в нем примеров настройки или описания какой-либо технологии или продукта. Вместо этого я расскажу о своем домашнем виртуальном сервере.


Помню, как год назад был рад, когда, наконец, задушил свою жабу и собрал отдельный тестовый полигон. Потому как бы не был хорош мой настольный компьютер с VMware Workstation 6.5, но душа желала чего-то большого и производительного. Этим чем-то стал самосборный сервер:

  • четырехъядерный процессор Intel Core 2 Quad Q6600;
  • мат.плата Asus P5BV-E (с двумя гигабитными сетевыми адаптерами Broadcom BCM 5721 и интегрированным SATA контроллером ICH7R);
  • память 8 Gb DDR-II 800Mhz;
  • дискретный 8-канальный SATA/SAS Raid-контроллер Intel SRCSASRB с 256Mb кэш памяти;
  • три жестких диска SATA - WD 1001FALS 7200RPM 32Mb.
Все это было собрано в хорошем корпусе с качественным БП, довольно тихим куллером и вентиляторами.

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

На сервер был поставлен ESXi 3.5 U3. Подбирались комплектующие как раз исходя из требований совместимости (спасибо Tim'у Jacobs'у за его статью). Другие решения виртуализации я также рассматривал (VMware Server 2.0, Windows Server 2008 + Hyper-V/Hyper-V Server R1, Citrix Xen Server 5.0), но все они по тем или иным причинам не подошли. Решающими для меня стала поддержка Memory Overcommit и наиболее удобная, на мой взгляд, работа с шаблонами виртуальных машин через vCenter. На ESXi были подняты две служебные машины - Windows Server 2003 в качестве контроллера домена и сервера VMware vCenter 2.5 U3 и Windows Server 2008 - файловый сервер.

Сами виртуальные машины (служебные, а потом и тестовые) ютились на одном единственном 640Гб жестком диске. Три терабайтных жестких диска были объединены в массив RAID 5 силами Intel SRCSASRB, затем разбиты на два LUN'а по терабайту (условно для software и media) и проброшены внутрь ВМ при помощи RDM. Не то, чтобы я не доверял файловой системе VMFS, но при возникновении какой-либо внештатной ситуации мне хотелось быстро и просто получить доступ к моим данным. Да, и я очень удивился скорости записи контроллера на диски в режиме Write Through (~14 Mb/sec), так, что пару раз хотел заехать молотком по несчастной железке, благо, режим Write Back, оказалось, можно включить без батарейки (которая позже все же была куплена, во избежание). И еще эта диагностика контроллером всех дисков в случае простоя, которая вымораживала меня на протяжении двух недель, пока не удосужился прочитать инструкцию и отключить.

Кроме того, на виртуальном сервере был настроен NFS и для ESXi расшарена папка с ISO образами для подключения через консоль Infrastructure Client.

При такой организации, служебные виртуальные машины и сам ESXi отъедали 1.5-2Гб от оперативной памяти и совсем немного мегагерц от процессора, оставляя для экспериментов достаточные вычислительные ресурсы. Однако, как я уже сказал, доволен я был этим сервером полгода.

Во-первых, о том, чтобы обстоятельно протестировать другие гипервизоры (Hyper-V, Xen Server) пришлось забыть. Кхм, скажем так - даже кратковременное отсутствие виртуальной машины, на которой хранился весь мой софт, музыка, фильмы, делало меня очень грустным.

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

В-третьих, возник вопрос об удаленном доступе к серверу и виртуальным машинам. Долгое время я ограничивался простой публикацией RDP на одной из виртуальных машин с установленной консолью Infrastructure Client. Надо сказать, что работать так с виртуальными машинами - удовольствие сомнительное, консоль ощутимо притормаживала, что при открытии в RDP сессии, что при более изощренном доступе через TS Remote Apps, что при TS Gateway. Чуть позже начал использовать возможность подключения к виртуальной машине по протоколу VNC - даже внутри RDP сессии управление стало намного приятнее. Один недостаток - приходилось вручную править .vmx файл настроек и запоминать порты для подключения.

И все это происходило на фоне моей постоянной и неуемной страсти к покупке новых железок. Я всерьез начал прикидывать во что мне обойдется апгрейд на платформу Intel S1366 с Xeon E5520 и 16 Гб памяти. Останавливало меня от этого шага только отсутствие вменяемых корпусов, в которых бы разместилась полноразмерная серверная E-ATX плата. Короче, голос разума победил.

С другой стороны, в рознице начали появляться серверные мат.платы под S1156, весьма неплохие за свои деньги (а трехканальный контроллер памяти и второй сокет как бы и не нужен совсем).

Поэтому в ожидании подарков от Деда Мороза решил обновиться до ESXi 4.0. 640 Гб диск был заменен на 1 Тб, а сам ESXi был установлен на flash накопитель (что чертовски удобно). Все виртуальные машины переставлены заново.

Из-за требований vCenter 4.0 не может быть установлен на контроллере домена. Поэтому пришлось установить его на Windows 2008 Server R2. И вот тут возникла одна неприятная особенность - при установке драйвера для виртуальной видеокарты из комплекта VMware Tools машина начинала периодически зависать. Поиск в Google быстро решил проблему.

А через несколько дней стал доступен Update 1, который позволил нормально создавать машины Windows Server 2008 R2 и Windows 7 из шаблона и подготавливать их с помощью Customization Specification. Надо ли говорить, что благодаря поддержке Thin Provisioning из GUI я смог легко уменьшить место занимаемое виртуальными машинами, не мучаясь теперь с командной строкой и ssh. Стоит отметить и негативную сторону данного события - я начал забывать параметры команды vmkfstools. :)

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

На этой позитивной ноте я заканчиваю свой рассказ. Надеюсь, что он был не слишком утомителен.

среда, 18 ноября 2009 г.

Удаленная работа с виртуальными машинами ESX/ESXi

Иногда возникает необходимость предоставить пользователю доступ к виртуальной машине, расположенной на сервере ESX/ESXi. Хотя консоль VMware Infrastructure/vSphere Client и справляется с данной задачей, но является достаточно громоздкой. В качестве альтернативных методов выступают VNC и Remote Console.

Для включения VNC клиента, отредактируйте файл .vmx виртуальной машины, добавив туда следующие строчки:
remotedisplay.vnc.enabled=”true”
remotedisplay.vnc.password = “<ПАРОЛЬ>
remotedisplay.vnc.port=”<ПОРТ>

, где <ПАРОЛЬ> - любой подходящий пароль, <ПОРТ> - порт, используемый для подключения.


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

Теперь вы сможете подключаться с помощью VNC клиента (например, UltraVNC).


Недостатком данного метода является то, что VNC может подсоединяться к виртуальной машине только, когда та включена, и к тому же, недоступны различные операции с машиной - выключение, перезагрузка, монтирование ISO-образа.

В качестве альтернативного варианта вы можете воспользоваться VMware Remote Console, входящей в состав VMware Player. Просто запустите из командной строки:
vmplayer -h <АДРЕС_ESX> <ПУТЬ_К_VMX>

Например так:
Обратите внимание на формат пути к .VMX файлу (после квадратных скобок должен быть пробел).

При подключении у вас запросят имя пользователя и пароль учетной записи ESX, у которой есть права на подключение:
 

Одно замечание - при попытке подключиться к ESXi 3.5 U4 с помощью Remote Console от Vmplayer 3.0, консоль закрывается без объяснения причин. В качестве решения, вы можете скачать модифицированную версию Remote Console от компании Minicom. С ESX 4.0 такой проблемы не наблюдается.

Update: если вы планируете подключаться с помощью Remote Console к ESX/ESXi версии 4.1 и выше, то вам требуется вручную создать на хосте учетную запись из-под которой производится подключение, так как доменная авторизация при интеграции с Active Directory не работает.