11.Виртуализация систем хранения данных

**11.Виртуализация систем**
хранения данных

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

Ниже перечислены типовые задачи, которые возникают при обслуживании СХД, а также показаны те возможности, которые появляются при внедрении систем виртуализации.

* **Подключение новых серверов, их настройка.**

Что необходимо сделать при подключении нового сервера к СХД? Добавить новую зону в настройки коммутаторов; создать новую RAID-группу или выбрать уже созданную; выделить на ней место (LUN) подходящее данному серверу; установить драйверы на сервер, которые соответствуют выбранной дисковой системе. Если мы захотим подключить к серверу различные дисковые системы, то с драйвером могут возникнуть существенные затруднения из-за проблем с совместимостью. Конечно можно использовать универсальные решения (например, Symantec Storage Foundation, а точнее, его часть - DMP), но они, во-первых, стоят отдельных денег, а, во-вторых, сами имеют списки совместимости, которым нужно следовать.
Система виртуализации заметно упрощает картину. Зонирование достаточно настроить для каждого сервера однократно - выделение дополнительного пространства не потребует перенастройки зон, так как весь трафик идет "от лица" системы виртуализации. Выделение дискового пространства не требует знаний по администрированию конкретной СХД - достаточно уметь управлять системой виртуализации. Проблем с драйверами также не возникает - нужен только один драйвер, независимо от того, на какой СХД физически находятся данные. А это значительно упрощает не только первоначальную инсталляцию, но и дальнейшее сопровождение.

* **Выделение дополнительного дискового пространства серверу.**

Выделение дополнительного дискового пространства серверу является практически самой простой задачей для администратора. Число необходимых действий действительно минимально. Но это верно только в том случае, когда на подключенной СХД нашлось свободное место? А если нет? Хорошо, если рост требований был спрогнозирован и дополнительные диски были заказаны, а если нет? Или если дополнительные диски для данной системы уже нельзя заказать? Тогда это приведёт к гораздо более серьезными трудностям . Если есть система со свободным пространством и ее можно безболезненно подключить к серверу, то все усложнения сводятся к изменению зонирования в коммутаторах SAN. Но если в резерве есть другая дисковая система, например, другого производителя, то задача усложняется на порядок: необходимо полностью мигрировать данные между системами. Это, в свою очередь, потребует остановки сервера, а значит и всех сервисов, которые на нем работают на довольно продолжительное время. Вероятность потери данных из-за человеческой ошибки довольно велика!
Система виртуализации снимает большую часть возникших проблем. Мы можем выделить дополнительное дисковое пространство серверу практически несколькими кликами мышкой. Фактически оно может располагаться на любых дисковых системах, кроме того, оно может располагаться одновременно на разных СХД. Нам не требуется изменять зонирование на коммутаторах, а значит и привлекать администратора, который за это отвечает. Длительная остановка сервера также не требуется, возможно,  нужна будет его перезагрузка, но это уже будет определяться программным обеспечением сервера. Все действия могут быть выполнены в рабочее время, либо во внеурочное,  когда время на работы сокращено в разы (как и непосредственные затраты).

* **Миграция данных между системами хранения.**

Миграция данных между системами является одной из основных проблем в больших инфраструктурах. Какие могут быть причины для миграции? Перенос данных на новую, более быструю систему; временный вывод системы из обслуживания (например, для модернизации). Даже миграция внутри одной системы хранения (например, для переноса тома с дисков FC на диски SATA ) может быть довольно сложным процессом, который потребует остановки серверов на длительное время. Многие производители предлагают специальные решения, которые способны упросить эту задачу, но они не универсальны и довольно сложны. Так как в первую очередь необходимо обеспечить консистентность данных, то после начала переноса данных, они не должны изменяться, следовательно, сервисы , которые обращаются к ним, должны быть остановлены все время, пока осуществляется перенос. Если объем данных велик, то не всегда есть возможность уложиться в выделенный промежуток времени. И остаётся только выбрать между дополнительными затратами на решение по миграции и потерями от длительного простоя. Но есть и третий вариант - в случае, когда внедрена система виртуализации, миграция данных может быть проведена совершенно прозрачно для сервера (не потребуется ни изменение каких-либо настроек в нем, ни даже его перезагрузка). Перемещение данных (как между различными СХД , так и внутри одной) происходит на уровне системы виртуализации, при этом, сервер имеет постоянный доступ к данным и продолжает к ним обращаться в нормальном режиме. Единственный эффект от миграции - незначительно понижение скорости работы в процессе миграции, поэтому для нагруженных критичных систем лучше ее спланировать на время наименьшей нагрузки. Но участие администратора в процедуре миграции минимально и требуется только во время запуска процедуры (или ее планирования), поэтому к минимуму сведены не только непосредственные расходы, но и вероятность человеческой ошибки.

* **Решение проблем недостаточной производительности.**

Другая проблема, которая периодически возникает - это недостаточность производительности системы. Решить ее можно несколькими способами: добавлением дисков в RAID-группу (так как производительность зачастую определяется числом дисков в системе); переносом данных с медленных (SATA, FC 10k) дисков на более быстрые (FC 15k, SSD ); переносом данных на новую более производительную систему. Как видно, в большинстве случаев в первую очередь необходимо миграция данных со всеми вытекающими сложностями. И, конечно, использование систем виртуализации упрощает эту задачу. Но есть и еще одна возможность, которая в ряде случаев может помочь решить задачу без закупки нового оборудования: использовать распределение дискового пространства между несколькими дисковыми системами ("страйпинг"). Во-первых, это дает возможность распределить том по большему числу дисков (а это явным образом повышает производительность), а, во-вторых, когда мы "упираемся" в производительность одной СХД, параллельное использование двух систем может снять это ограничение и достичь лучших результатов. Кроме того, некоторые системы виртуализации (например, IBM SAN Volume Controller, HDS USP/USP-V) позволяют использовать свой кэш для операций чтения и записи (который зачастую больше того, который установлен в СХД), что также дает заметное увеличение производительности.

* **Построение катастрофоустойчивых систем.**

В случае, когда нужно организовать резервную площадку в основном дата-центре, возникает проблема обеспечения актуальной и консистентной копии данных на удаленной площадке. Для этого существует целый ряд методов, но, в тех случаях, когда для зеркалирования данных используются встроенные средства дисковых систем, действует ряд строгих ограничений (системы должны быть одного производителя, зачастую одного поколения, есть ряд ограничений на версию прошивки). В случае, когда закупки СХД осуществляются поэтапно, эти требования очень сложно соблюсти, и тем более это проблематично сделать, когда резервная площадка появляется в результате слияния двух компаний). Системы виртуализации помогают решить возникшие проблемы. Репликация данных осуществляется на уровне систем виртуализации и уже не накладывает столь строгие ограничения на сами СХД,  отсутствие проблем с зеркалированием данных, например, между IBM DS4700 и HP EVA4000. В таком случаеуже не требуется лицензия на репликацию для самих СХД и они могут ее вообще не поддерживать, что дает возможность использовать системы нижнего ценового сегмента, в которых функционал репликации зачастую вообще не реализован. Ряд систем (например, Falconstor NSS) позволяют использовать в качестве транспорта IP протокол без применения каких-либо дополнительных аппаратных средств, что также может удешевить построение катастрофоустойчивого решения.

* **Плановое обслуживание СХД.**

Как правило, системы хранения предназначены для постоянной эксплуатации, но могут возникнуть ситуации, когда потребуется остановить систему: для модернизации (добавления дисковой полки), для смены прошивки (иногда ее нельзя проводить без остановки системы), для переноса системы в другой шкаф. Такие работы потребуется проводить во вне рабочее время, это может повлечь ошибки, которые потенциально могут привести к потере данных. Система виртуализации позволяет провести плановое обслуживание СХД совершенно прозрачно для серверов и сделать это в рабочие часы.