Виртуализация Виртуализация систем хранения

Виртуализация систем хранения

Можно сказать, что "виртуализация" в дисковых системах используется очень давно (ведь, по сути своей, даже создание RAID-группы и выделения не ней части пространства конкретному серверу уже является виртуализацией, так как скрывает фактическую организацию дискового пространства от сервера). Однако, сейчас под виртуализацией понимают в большинстве случаев более сложную систему, которая полностью скрывает от сервера организацию дисков в SAN.

виртуализцаия СХД, SNIA

Виртуализация может быть реализована на разных уровнях, но во всех случаях тип, количество и организация систем хранения - все это остается для сервера за кадром. Исключение составляет виртуализация на уровне сервера (ярким примером такого решения можно назвать Symantec Storage Foundation), ниже речь пойдет в основном для решений на уровне сетей и систем хранения. Для серверов "видны" просто выделенные им дисковые тома, независимо от того, на каких системах хранения они находятся и как организованы. Такой подход конечно заметно упрощает администрирование самих серверов, но виртуализация в системах хранения данных позволяет упростить и решение очень многих других задач.

Как правило, эффективность решения наиболее очевидна в случае, когда уже имеется несколько дисковых систем и требуется дальнейшее увеличение дискового пространства. Типичным примером является динамично развивающаяся компания, в которой уже несколько лет используются системы хранения данных и развернута сеть хранения. В результате того, что регулярно осуществляются закупки нового оборудования, а также после нескольких слияний, используются дисковые системы различных поколений и производителей. Эффективное использование такого парка оборудования вызывает существенные трудности, администраторам требуется уметь управлять совершенно различными системами. Как следствие, растут затраты на обслуживание и эти затраты не сопровождаются адекватной отдачей. Существует ли решение для данной проблемы?

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

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

Что необходимо сделать при подключении нового сервера к СХД? Добавить новую зону в настройки коммутаторов; создать новую 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 протокол без применения каких-либо дополнительных аппаратных средств, что также может удешевить построение катастрофоустойчивого решения.

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

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

Как видим, система виртуализации не только упрощает непосредственное администрирование СХД, но и значительно снижает расходы на решение остальных задач по эксплуатации систем хранения. Мы подробно не остановились на технологии "thin provisioning" (выделение дискового пространства по мере необходимости), которая появились в системах виртуализации (IBM SVC, HDS USP/USP-V) не так давно. Данная технология позволяет выделить серверу заведомо больший объем дискового пространства, чем требуется, но реальное дисковое пространство будет выделяться по мере записи новых данных. Это позволяет оптимизировать использование дискового пространства, при этом существенно экономя на закупке новых дисков.
Конечно, не стоит рассматривать системы виртуализации как панацею от всех бед - в ряде случаев их использование может быть и не совсем эффективно (например, когда два-три сервера подключены к одной системе хранения данных). Но в большинстве случаев, эффект от внедрения будет положительным, хотя начальные затраты будут в большинстве случаев выше, чем при простом добавлении новой системы хранения в имеющуюся инфраструктуру. Поэтому оценивать эффективность решения необходимо с точки зрения снижения стоимости владения и возврата инвестиций (TCO, ROI).


 


 

Система Orphus