Скриншоты

Когда-нибудь выложу свою свою коллекцию скриншотов.

Вот, например, сегодняшний:
Суперскорость


Veeam Backup v6.x. Архитектура. Депозитарий для резервных копий

О том, как масштабировать репозитарии, я уже писал http://www.veskin.ru/2012/07/veeam-backup-v6x.html.
С хранением резервных копий все также достаточно гибко – возможны различные варианты, но у каждого есть свои нюансы.

Само собой резервные копии желательно хранить вне пределах виртуальной инфраструктуры, чтобы избежать «одной корзины» (или «single point of failure»). Так что так или иначе желательно иметь отдельный массив под резервные копии. Все остальное зависит от задачи, которую необходимо решить.
Репозитарии – серверы, которые осуществляют запись на диск – могут быть различные по типу установки:
   a) Виртуальные
   b) Физические
По типу ОС:
   a) Windows
   b) Linux
По месту хранения:
   a) Локальный диск – то, что видно сервером как локальные диски: локальные диски, DAS-полка с дисками, FC- и iSCSI-хранилища, USB-накопители и т.п.
   b) CIFS-шара
   c) NFS-шара

SureBackup'им RHEL

Решение проблемы смены MAC-адреса ВМ с RHEL/CentOS в Veeam Backup VirtualLab.

RedHat в конфигурационном файле сетевого интерфейса (/etc/sysconfig/network-scripts/ifcfg-eth<номер_интерфейса>) содержит строчку привязки конфигурационных настроек к MAC-адресу. Выглядит строка так:
HWADDR=xx:xx:xx:xx:xx:xx

При старте система проверяет текущий MAC, и если он не соответствует заданному значению, то конфигурационный файл переименовывается в .bak и создается новый файл с пустыми настройками (использует DHCP для получения адреса и т.п.). Это может привести к нежелательным результатам: например, приложение web-сервера может отказываться запуститься.
С этой проблемой сталкиваются при клонировании ВМ или запуске ВМ из резервной копии в Veeam Backup VirtualLab.

Решение: закомментировать через "#" эту проверку в конфигурационном файле и произвести повторное резервное копирование.

Перезагрузка FC HBA на хостах ESX(i)

Есть такая проблема. При подключении хоста ESX(i) (замечено на QLogic FC HBA) к новым создаваемым LUNам на некоторых массивах необходима перезагрузка хоста. Т.е., когда вы в vClient пытаетесь подключить только что созданный новый LUN, вы этот раздел не увидите.
Так как перезагрузка хоста бывает делом проблематичным (особенно в продуктиве), есть более быстрый способ: воспользоваться командной строкой HBA-адаптера для перезагрузки самого интерфейса. На ESXi для этого командую строку придется включить.

Процедура выглядит так:

1. Подключаемся к серверу по SSH или входим в консоль сервера ESX(i).


2. Определяем, какие идентификаторы SCSI HBA у нас есть:
# ls -l /proc/scsi/qla2xxx/
-rw-r--r-- 1 root root 131072 Jun 15 09:21 3
-rw-r--r-- 1 root root 131072 Jun 15 09:21 4
В моем примере это 3 и 4 (здесь и далее я их специально выделил цветом).


3. Затем для каждого производим инициацию ("LIP login") для каждого из интерфейсов:
# echo "scsi-qlalip " > /proc/scsi/qla2xxx/3
и
# echo "scsi-qlalip " > /proc/scsi/qla2xxx/4
Производить крайне желательно для каждого адаптера, у которого есть путь до данного LUNа, чтобы заработал мультипассинг.


4. Делаем рескан. Либо в vClient, либо командой "esxcfg-rescan", либо запросом на HBA-адаптер:
# echo "scsi-qlascan " > /proc/scsi/qla2xxx/3
и
# echo "scsi-qlascan " > /proc/scsi/qla2xxx/4



5. Проверяем. LUN должен быть виден сервером.



На самом деле проблема встречается не только при презентации LUN, но и при создании/изменении зон SAN и т.п. операциях.

Шура, бэкап! Как и с чем едят SureBackup


SureBackup — один из инструментов Veeam Backup. Работает он благодаря двум функциям: vPower (запуск ВМ из архива) и VirtualLab (изолированная виртуальная среда).
В автоматическом режиме, по расписанию, с рассылкой результатов проверки на почту, SureBackup позволяет запустить группу ВМ и проверить их работоспособность на уровне ОС, сети и приложений.

Вот на третьем способе проверки (приложений) я и хочу остановиться подробней.
Для проверки стандартных приложений есть возможность выбора: AD, Global Catalog, SQL, Web, Mail, DNS. Проверка идет просто: опрашивается сетевой порт, и если на соответствующий порт приложение отвечает, значит считаем, что приложение работает.

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