Рубрика: Статьи

Проблема выбора

Больше двух лет лежала в черновиках заметка, решил опубликовать.  К сожалению, тема «Как генерировать правильные и хорошие решения?» не раскрыта. 😉

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

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

Второй проблемой стало резервное копирование. В компании имеет FC-хранилище entry-уровня и резервные копии с одних LUNов с данными кладутся на другие LUNы.  На вопрос «вы понимаете, что в случае проблем со хранилищем вы потеряете всё?» получен ответ «да, понимаем!».

Третье проблемой является наличие бородатых серверов 3-5-7 летней старости временами тормозящих, и ИТ хочет обновить часть из них.

Со своими проблемами ИТ приходит к бизнесу и требует сделать ВЫБОР, предлагая варианты решения.

Первое развитие. «Мы не хотим просить»

Решение проблем:

  1. Первой — не будем виртуализовать новые сервисы, у нас итак 3 сервака виртуальных.
  2. Второй —  Положить резервные копии с одних 10 серверов на локальные диски другие 10 серверов, ведь там есть свободное место.
  3. Третьей — оставить инфраструктуру как есть, подкрутить настройки, перекомплектовать сервера, пересобрать RAID’ы.

Второе развитие. «Раз вы просите, то держите»

ИТ-отдел почесал репу и предложил «комплексное» решение:

Давайте купим блейд-центр с 8 лезвиями, напичканными самыми крутыми процессорами, завиртуализируем на них часть сервисов, плюс пару серверов дополнительно будем их использовать по классической схеме без виртуализации. На вопрос «а разве сервисы, которые будут на этой паре запущены проблематично виртуализовать?» дают «чтобы избежать пустых разговоров что 1с7 тормозит из-за того, что сервер виртуальный, я решил сделать так». Решение вышло порядка 100 тысяч баксов, оно решило бы пару проблем, а резервные копии видать предлагается делать по первому варианту развития.

Муки выбора

Бизнес спрашивает: «оба варианта работают?», — «да, первый это как теперь, правда, иногда тормоза и бэкап не старее пары дней, а вот если второй должно всё хорошо работать.»

А теперь посмотрите на позицию  бизнеса, ему предложили целых ДВА варианта: один не требует ЗАТРАТ и всё работает с мелкими косяками, а второй — возьми и выложь 100 000 баксов с вероятным улучшением ситуации.

В итоге, ИТ в горести, печали и обиде, бизнес тоже недоволен.

«Принимай решение не торопясь, взвесив все возможные варианты.» — один из принципов менеджмента Toyota.

ИТ выступил стороной готовящей решения, и сделал два ПЛОХИХ варианта, первый плохой и для ИТ, и для бизнеса, а по второму не поинтересовался доступным бюджетом. Бизнес выступил стороной принимающей решения и выбрал из принципа «из двух зол выбирают меньшее», денег столько тратить не готовы, и можно сделать «бесплатно».

Вместо этого ИТ необходимо было подготовить 3-4 ХОРОШИХ варианта. Определить критичность и приоритет задач, разделить в соответствии с этим закупки на этапы, человеческим языком на уровне пользователя кратко пояснить, что даёт и какие проблемы закрывает каждый вариант, каждый этап. Чтобы бизнес правильно принял решение у него должны быть варианты правильных решений.

VMware tool update

Почерпнул отсюда.
По умолчанию, при обновлении VMware Tools в автоматическом режиме происходит перезагрузка ВМ. На просторах инета есть скрипты для PowerSHell, позволяющие обновить все ваши машины без автоматической перезагрузки.
Если же с PowerSHell вы не дружите, то для вас есть следующий вариант:
Выбираете в контекстном меню Guest->Install/Upgrade VMware Tools, там выбираете Automatic Tools Upgrade и в строке с опциями указываете

/S /v»REBOOT=R /qb»

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

UPD: Михаил подсказывает, что для пятой версии подходят другие параметры.

/S /v “/qn REBOOT=R”

И опять про бэкапы

Знаковый опрос на тему «Кто должен делать бэкап 1С«?

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

Мы периодически забываем о том, для чего делаются резервные копии. А нужны они только для восстановления данных. Поэтому правильные бэкапы — те, которые восстанавливаются. Пример использования виртуализации для тестирования резервных копий MS Exchange в рабочее время.

Ввиду того, что средний системный администратор (СА) — существо либо ленивое, либо занятое, бэкапы он не тестирует. Это справедливо для большинства компаний из сектора SMB (малый/средний бизнес).

Кроме того, СА может не делать бэкапы, придумывая следующие оправдания:

  1. Нет достаточного места под резервные копии / нет выделенного сервера под резервные копии;
  2. Нет системы автоматизированного создания резервных копий (СРК — система резервного копирования);
  3. Нет времени на проверку резервных копий (либо некуда восстанавливать), а раз так — зачем их нерегулярно делать;
  4. Отсутствует лицо, заинтересованное в создании резервных копий или целостности данных;
  5. Просто влом.

Читать далее «И опять про бэкапы»

Обновление ESX3,5i->ESX4i — продолжение

Недавно я писал о переходе своей виртуальной инфраструктуры на vSphere 4. Почти сразу же я попался на том, что новоявленный ESX4i перестал мониторить железо (DAS). Погнавшись за апдейтами, я также обновил vCenter4 до Update1. Как и следовало ожидать, один из ESXi тут же отвалился от vCenter. Откат на старую версию vCenter ничего не дал (если внимательно почитать workaround к статье, можно понять почему).

Соответственно, почва для послерабочих бдений (у меня vSphere Essentials) подготовлена.

Читать далее «Обновление ESX3,5i->ESX4i — продолжение»

Рекомендации при использовании VMware VI

Портал VMGuru.nl выдает зачетные рекомендации для использования виртуальной инфраструктуры VMware.
Эти рекомендации особенно полезны при создании новой инфраструктуры, хотя и для существующей будут полезны. Переведем 😉
Рекомендации касаются:
— ESX(i);
— vCenter;
— Лицензирование;
— СХД;
— Сеть;
— Виртуальные машины.
Читать далее «Рекомендации при использовании VMware VI»

Заметка про защиту данных

Андрей Иванов написал замечательную статью про защиту данных (Вам чай с сахаром или руки с мылом помоете?).
Данная тема мне тоже интересна и я давно думал что-нибудь подобное написать.
Если вкратце, то есть несколько уровней защиты информации:
— аппаратный;
— программный;
— организационный.
Вообще говоря, деление довольно условное и позже я приведу решения, которые находятся на стыке нескольких уровней.
Читать далее «Заметка про защиту данных»

Виртуализация это

Виртуализация — это одно из самых популярных и неоднозначных понятий в ИТ за последнее время. Я попытаюсь предложить вариант этого определения, а также развеять несколько мифов, которыми окружена виртуализация:
Миф №1: виртуализация — это супер, давайте все виртуализоваться.
Миф №2: вот я сейчас куплю шасси с кучей блейд-серверов и запущу на ней суперсервер с десятками гигагерц и сотнями гигабайт.
Миф №3: даешь 100% виртуализацию.
Миф№4: виртуализация — это медленно.
Читать далее «Виртуализация это»

Параметры VMX или защита ВМ

Этот перевод навеян шикарной статьей от Robert Patton, посвященной параметрам VMX-файлов виртуальных машин, предназначенным для устранения определенных уязвимостей. Как водится, перевод пристрастный 🙂
Читать далее «Параметры VMX или защита ВМ»

Устройство снимков виртуальных дисков в VMware VI3

Оригинал данной статьи находится здесь, я же являюсь не более, чем пристрастным переводчиком данного текста. 🙂 Статья рекомендуется к прочтению всем адептам VMware VI3 и VMware vSphere.

Введение

Вчера я потратил полдня, решая проблему, возникшую из-за рассинхронизации снимка VMware VI3. Это был неприятный опыт, зато я узнал о важности CID-цепи!
После нескольких часов пинания мертвой ВМ, мой коллега, Дан, и я натолкнулись на CID-цепи.
Мы пришли к выводу, что .vmdk-файлы, которые создаются в VI3 каждый раз при снятии снимка, связаны с другими .vmdk через сгенерированные случайным образом значения CID. VI3 присваивает каждому новому файлу снимка CID, причем это значение меняется при каждой перезагрузке ВМ.
Если цепь CID разрывается, то ВМ не может подключить свой виртуальный диск.

Проблема

Ваши виртуальные диски не подключаются при включении ВМ, вы получите следующее сообщение об ошибке:
“Cannot open the disk ‘/vmfs/volumes/INSERT SPECIFIC VALUE HERE.vmdk’ or one of the snapshot disks it depends on.
Reason: The parent virtual disk has been modified since the child was created.”
“Не удается открыть диск ‘/vmfs/volumes/lalala.vmdk’ или один из файлов снимков, от которых он зависит.
Причина: первичный виртуальный диск был изменен, после создания вторичного.”

Черт!

Что вам делать?!
1) Только не паникуйте 🙂
2) Полностью выключите ВМ.
3) Ничего не изменяйте!
4) Прочтите эту статью!
Если вы не вносили изменения в .vmdk файлы, вероятнее всего, у вас получится исправить эту проблему.

Анализ

Эта проблема возникла, вероятно, потому что вы сделали один или несколько снимков одного или нескольких виртуальных дисков, связанных с ВМ, и снимки рассинхронизировались. Скорее всего, вы получили эту проблему в средах ESX/VI3.
Причина этой проблемы связана с тем, как VI3 управляет снимками и дельтами изменений относительно первоначального виртуального диска (.vmdk). Вероятно, нарушилась логика иерархии снимков, и вторичные .vmdk-файлы, уже не ссылаются на первичные.
Ключ к складыванию головоломки из снимков находится в восстановлении цепи CID.
Каждому .vmdk файлу назначается свой CID-идетификатор. Кроме того, в каждом .vmdk содержится ссылка на CID и .vmdk предыдущего (родительского) файла. CID “родителя” должен указывать на .vmdk файл, созданный непосредственно перед созданием снимка.
При загрузке ВМ CID в .vmdk-файлах меняется на случайным образом. Если после загрузки ВМ цепь CID не в том же состоянии, как и до загрузки, то связь вторичный CID -> первичный CID нарушается. Таким образом VI3 определяет подлинность снимков. Единственный способ вновь синхронизировать CID-цепь – вручную отредактировать все .vmdk файлы в этой цепи.
Пример CID-цепи:
Первичный .vmdk = vdisk.vmdk
.vmdk, созданный после 1 снимка = vdisk-000001.vmdk
.vmdk, созданный после 2 снимка = vdisk-000002.vmdk
Если эта цепочка нарушается, то:
вручную делаем ссылку vdisk-000002.vmdk -> vdisk-000001.vmdk;
vdisk-000001.vmdk -> vdisk.vmdk.

Обратим внимание на три поля в .vmdk-файле:
— поле CID;
— ссылка на parentCID;
— поле parentNameHint.
Примечание: первичный .vmdk не содержит поля «parentNameHint», а его «parentCID» всегда равняется «ffffffff».

Примеры

Пример содержимого первичного vdisk.vmdk:
[root@myvi3server]# cat vdisk.vmdk
# Disk DescriptorFile
version=1
CID=7f81b951
parentCID=ffffffff
createType=»vmfs»
# Extent description
RW 50331648 VMFS «vdisk-flat.vmdk»
# The Disk Data Base
#DDB
ddb.virtualHWVersion = «4»
ddb.geometry.cylinders = «3133»
ddb.geometry.heads = «255»
ddb.geometry.sectors = «63»
ddb.adapterType = «lsilogic»
ddb.toolsVersion = «7202»

Пример второго файла — vdisk-000001.vmdk:
[root@myvi3server]# cat vdisk-000001.vmdk
# Disk DescriptorFile
version=1
CID=8eb633b8
parentCID=7f81b951
createType=»vmfsSparse»
parentFileNameHint=»/vmfs/volumes/478b9802-ce7ed955-96a4-0015c5fd9308/servername/vdisk.vmdk»
# Extent description
RW 50331648 VMFSSPARSE «vdisk-000001-delta.vmdk»
# The Disk Data Base
#DDB
ddb.toolsVersion = «7202»
Примечание: файл из “parentNameHint” находится на iSCSI SAN. Длинный шестнадцатиричный GUID – идентификатор этого VMFS-хранилища.

Пример третьего — vdisk-000002.vmdk:
[root@myvi3server]# cat vdisk-000002.vmdk
# Disk DescriptorFile
version=1
CID=249e6aff
parentCID=8eb633b8
createType=»vmfsSparse»
parentFileNameHint=»sryulris0cogp01-000001.vmdk»
# Extent description
RW 50331648 VMFSSPARSE «vdisk-000002-delta.vmdk»
# The Disk Data Base
#DDB
ddb.toolsVersion = «7202»
Примечание: Путь к файлу в «parentNameHint» поле указывает на файл, который располагается в том же каталоге, что и vdisk-000002.vmdk. Если файл находится в другом каталоге, то в пути указывается каталог.

Решение

Следующие шаги синхронизируют файлы снимков VI3 так, что ESX/ESXi успешно проверит их связь друг с другом, а также их подлинность:
Примечание: Выполните следующие действия в текстовом редакторе. Сохраните резервную копию оригинального файла до внесения каких-либо изменений.

Измените vdisk-000002.vmdk:
1) Запомним CID у vdisk-000001.vmdk (= 8eb633b8);
2) Запомним путь к vdisk-000001.vmdk (= локальный каталог);
3) Исправьте parentCID для vdisk-000001.vmdk -> ParentCID=8eb633b8;
4) Исправьте parentNameHint на vdisk-000001.vmdk -> ParentFileNameHint=»vdisk-000001.vmdk».

Измените vdisk-000001.vmdk:
1) Запомним CID у vdisk-000001.vmdk (=7f81b951);
2) Запомним путь к vdisk-000001.vmdk (=»/ vmfs/volumes/478b9802-ce7ed955-96a4-0015c5fd9308/servername /);
3) Исправьте parentCID для vdisk.vmdk -> ParentCID=7f81b951;
4) Исправьте parentNameHint на vdisk.vmdk файл -> ParentFileNameHint=»/ vmfs/volumes/478b9802-ce7ed955-96a4-0015c5fd9308/servername/vdisk.vmdk».

Если виртуальные диски не были изменены, вас можно поздравить. Если же виртуальные диски были изменены или вы удаляли их из виртуальной машины, а затем добавляли снова, необходимо будет вручную изменить настройки соответствующего виртуального SCSI-контроллера в файле настроек ВМ — .vmx-файле (указать .vmdk последнего снимка в вашей CID-цепи).

Примечание: Выполните следующие действия в текстовом редакторе. Естественно, сохраните резервную копию исходного файла до внесения каких-либо изменений. 🙂

Измените servername.vmx:
1) Найдите SCSI контроллер, на котором находится виртуальный диск, который мы восстанавливаем. Первый виртуальный диск, как правило, назначается на SCSI-контроллер scsi0:0, второй — scsi0:1, а третий — scsi0:2;
2) Предположим, что мы восстанавливаем второй виртуальный диск. Найдите раздел, ссылающийся на scsi0:1;
3) Укажите в поле ссылку на .vmdk последнего снимка в нашей цепи:
scsi0:1.fileName=»/ vmfs/volumes/46fd62d479749c9697e30015c5fd9308/servername/vdisk-000002.vmdk».
Примечание: Путь к файлу может быть изменен, хотя по умолчанию снимки сохраняются в том же каталоге, что и первичный .vmdk (vdisk.vmdk). Поэтому введите полный путь к .vmdk снимка (vdisk-000002.vmdk), включая iSCSI GUID и т.д…
4) Сохраните файл и перезагрузите ВМ;
5) Если ВМ не загружается, или выдает ошибку “The parent virtual disk has been modified since the child was created.”, проверьте иерархию CID и пути к файлам, а затем повторите попытку. Если ВМ прежнему не загружается, а CID-сеть и пути к файлам корректны, то первичный или последующие .vmdk-файлы, вероятно, были изменены некорректным образом и их не удается восстановить!