«Дешевое» решение

После одного из европейских VMUG (VMware User Groups – когда собираются те, кто не равнодушен к технологиям виртуализации от VMware и делятся опытом) появились скрипты, как самому сделать DR для сервисов в виртуальной инфраструктуре VMware.

Первоисточник с презентацией тут.

Состав:

Площадки с развернутой VMware vSphere – 2 штуки
СХД с репликацией между ними – 2 штуки
ВМ – в ассортименте
скрипты Power Shell (вот прямая ссылка) – 1 набор
голова и руки – по вкусу

Готовка:

Дальше »

Консолидация производителей

Вот пресс-релиз от NetApp. Вот от LSI. NetApp покупает часть LSI, которая отвечает за производство систем хранения - Engenio external storage systems.

Конкурентный юмор

Dell купил Compellent Technologies, Inc.
Таким образом из партнера он превратился в конкурента EMC²
Вот этому и посвящен сайт TRASH THE SAME OLD SAN

Я думаю, EMC не пропадут без серверов Dell - будут теснее работать в альянсе с Cisco. Ну, если Cisco не начнет хранить данные на коммутаторах :)

Как еще может пригодиться Veeam Backup?

"Тонкие" диски в vSphere по мере наполнения данными разрастаются. Но при удалении данных сделать их снова тоньше vSphere даже и не пытается.
Как быть?
Сделать резервную копию с помощью Veeam Backup & Replication, а потом восстановить в фомате диска "Force to thin".

Понятно, что это решение больше для SMB, чем для Enterprise.

Оригинальный пост у М.Михеева: thin shrink : Виртуализация. VMware vSphere, MS Hyper-V, Xen, etc...
Спасибо, DjoN

Veeam Monitor

Те, кто использует Veeam Monitor знают, что он показывает снапшоты VMware.

Наверное буду в этот пост добавлять еще факты о Мониторе.

Disk & disk array calc

Одной из часто встречаемых проблем при проектировании является подсчет IOPS (Input/Output Operations Per Second) - количество операций ввода/вывода, которое может поддержать дисковая подсистема.
Необходимо учитывать ТТХ дисков, параметры настройки массива, подсистему ввода-вывода хостов.

Вот хороший калькулятор для подсчета IOPSов.
Из приятного - сбоку подсказывается методология расчета с формулами и введена небольшая база предустановок по характеристикам дисков производства Seagate.

раздел страницы: http://www.wmarow.com/strcalc/ (открыть в Google ВикиКомментариях)

P.S. Tip: страницу с калькулятором можно сохранить на локал и пользоваться им в офф-лайн

Дефрагментация дисков ESX

Важное замечание. Статью писал несколько лет назад. Потому стоит учесть, что она касается VI3. В vSphere есть технология CBT (changed bloacks tracking), которая очень помогает для быстрого резервного копирования. В этом случае дефрагментация только ухудшит работу. Точно также дефрагментация отрицательно будет влиять на тонкие диски.
В любом случае, дефрагментация внутри ВМ не даст приращения в скорости, поскольку доступ к всему тому LUN, при наличии большого количества файлов дисков ВМ, доступ будет не последовательный, а случайный.
Рекомендация одна: выберийте быстрые массивы для файлов ВМ.

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

Стоит разбить тему на две части: дефрагментация информации на диске внутри виртуальной машины (ВМ), и дефрагментация самих дисков ВМ в разделе VMFS (файловая система для виртуальных машин).

По первому вопросу: да, стоит. Сильно фрагментированный диск будет тормозить дисковую подсистему ВМ.
Но, нужно учитывать следующее:
1. Дефрагментация сама по себе дает интенсивный ввод-вывод на диски, а значит будет влиять на всю дисковую подсистему, что затронет все ВМ на данной партиции, включая запущенные на других ESX-серверах. И самое главное: не дефрагментируйте все ВМ скопом! Хотя... есть неплохой шанс проверить ваш SAN на прочность ;)
Короче, выбирайте время для дефрагментации, и запускайте дефрагментацию по очереди.

2. А вот это серьезней, и менее очевидный риф: Не дефрагментируйте ВМ с активными snapshot'ами! Во-первых, ваш файл дисковой разницы будет очень быстро пухнуть - так как много изменений происходит внутри виртуального диска. А, во-вторых, дисковая подсистема для всех ваших ВМ в данной партиции VMFS будет жутко тормозить, потому как snapshot начнет расти 16МБ блоками, а каждое изменение в размере файла на VMFS приводит к локированию всей VMFS-партиции.
От себя добавлю, выход есть: вначале дефрагментация, потом snapshot.

Что касается второй части - дефрагментации файлов ВМ на VMFS-партиции, мне понравилась в той статье фраза:
"Ответим на этот вопрос: нет, по двум причинам. Во-первых, не существует механизма, ни встроенного, ни разработанного кем-то еще, который бы позволил это осуществить"
Отличное замечание, не правда ли? :) Вам вторая причина еще нужна?
"Вторая причина в том, что хост в реальности и не фрагментирует данные, ввиду принципа создания и работы виртуальных дисков на VMFS"
Ага, мне второе замечание тоже понравилось. :) Причины две: нет ни возможности, ни надобности.

А далее статья рассказывается сам принцип создания дисков ВМ. На самом деле данные все-таки могут фрагментироваться, но не так, как это происходит с файлами в обычных ОСах. Заметим, что в отличие от обычных операционнок, здесь складывается противоположная ситуация: хранятся, по большей части, огромные файлы и в относительно небольшом количестве.
Если вы создаете обычный ("толстый") диск ВМ, или копируете с помощью утилиты vmkfstools, то виртуальный диск будет создан максимально большим куском, как правило, единым блоком, а затем уже будет наполнятся данными в случае копирования.
Фрагментация может произойти, если был создан так называемый "thin" диск, который будет расти по мере необходимости нового пространства, или если вы ошибочно копируете диск другой ВМ с помощью SCP (пользуйтесь vmkfstools!).
Также фрагментация происходит, когда вы создаете и удаляете snapshotы, и при автоматическом создании/удалении разных сопутствующих мелких файлов ВМ: логи, свопы и слепки памяти и т.п.

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