Две ловушки для предприятий, внедряющих виртуализацию серверов

Виртуализация рассматривается как панацея от многих ИТ-проблем предприятий. Виртуализация, похоже, дает ответы на все вопросы: от повышения доступности приложений до упрощенного аварийного восстановления и сокращения затрат на инфраструктуру. Виртуализация также предлагает упрощенное управление ИТ и даже более «зеленые» вычислительные решения.

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

Ошибка 1: выбор неправильной платформы хранения

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

Сетевое хранилище часто используется как способ упростить предоставление хранилища виртуального сервера. Емкость сетевого хранилища очень просто настроить, а расширение емкости не требует привлечения гипервизора. К сожалению, при использовании сетевого хранилища есть недостатки в производительности. Многие приложения (например, Microsoft Exchange) просто не запускаются с использованием сетевого хранилища. По этим причинам большинство поставщиков виртуализации рекомендуют сети SAN тем, кто ищет более эффективную производительность приложений.

Сеть хранения данных Fibre Channel

При использовании сетей SAN Fibre Channel пользователям необходимо не только обосновать дополнительные затраты на хранение, коммутацию и управление Fibre Channel, но им также необходимо настроить дорогие адаптеры главной шины для каждого сервера, который они подключают к SAN. Предприятия, внедряющие существующие сети хранения данных Fibre Channel, столкнутся с небольшими препятствиями. Чтобы воспользоваться значительными преимуществами виртуализации серверов, вся инфраструктура Fibre Channel (включая коммутаторы и адаптеры главной шины) должна поддерживать протокол NPIV (N-Port ID Virtualization). Большинство продуктов в настоящее время не содержат NPIV.

Даже при использовании NPIV VMware может передавать гостевые программы только между компьютерами в зоне Fibre Channel. Это означает, что хотя вы и достигли аппаратной независимости на стороне сервера, все физические серверы в группе, которые могут доставлять клиентские приложения друг другу, не зависят от одной зоны Fibre Channel для хранения данных (обычно это массив или даже жесткий диск). ). Независимость оборудования на стороне сервера может создать опасные аппаратные зависимости нескольких приложений на стороне хранилища.

Оптимизация решений хранения данных для виртуализированных сред

iSCSI (Internet Small Computer System Interface) или IP SAN (IP Storage Area Network) обеспечивают лучшее решение для хранения данных в виртуализированной серверной среде не только из-за очевидного преимущества в стоимости, но и из-за доступности виртуальной архитектуры. лучший с точки зрения гибкости и масштабируемости. Система хранения данных iSCSI SAN также может предоставить значительные преимущества предприятиям, использующим виртуализацию аварийного восстановления глобальной сети. Снимки также можно использовать на уровне хранилища для репликации данных на локальную или удаленную площадку резервного копирования.

Кроме того, системы хранения данных локальной сети iSCSI имеют очевидные преимущества в глобальной сети по сравнению с локальными сетями хранения данных Fibre Channel. Репликация хранилища Fibre Channel в глобальной сети требует приобретения дорогостоящих шлюзов FCIP (Fibre Channel over IP). Репликация WAN для хранилища iSCSI СХД LAN не требует приобретения, внедрения, эксплуатации и управления дополнительных систем. iSCSI — это протокол TCP/IP, который изначально работает в глобальной сети. Репликация как Fibre Channel, так и iSCSI WAN может привести к снижению пропускной способности или потере пакетов на больших расстояниях. Устройства, оптимизированные для WAN или TCP/IP, для хранения iSCSI. Локальное хранилище может решить эту проблему. Это устройство оптимизации WAN или TCP/IP не оказывает или оказывает незначительное влияние на шлюзы FCIP.

Ловушка 2: дилемма избыточного обеспечения

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

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

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

На уровне отдельного диска очередь запросов ввода/вывода будет расти. Эта проблема будет более заметной при настройке более медленных жестких дисков SATA. На жестких дисках SATA глубина очереди обычно составляет от 0 до 32 запросов, тогда как на жестких дисках SAS (Serial Attached SCSI) или Fibre Channel глубина очереди составляет от 256 до 512 запросов. Это означает, что предприятиям, желающим внедрить виртуализированную инфраструктуру, необходимо решение SAN, которое не ограничивает их выбор внутренних дисков.

На уровне хранилища LUN (номер логической единицы) сам гипервизор обычно разделяет физический пул хранения или LUN на несколько виртуальных LUN. Эти LUN затем распределяются между различными виртуальными гостевыми приложениями. Эти физические LUN ​​не могут различать клиентские приложения. Чрезмерные конфликты ресурсов могут снизить производительность хранилища.

Аналогичным образом, избыточное выделение ресурсов на уровне гипервизора может вызвать проблемы на уровне инфраструктуры SAN с адаптерами главной шины, инициаторами, портами и коммутаторами. Эти ресурсы часто выделяются в соотношении 8:1 или превышают конфигурацию самой сети хранения данных. Комплексный эффект этого двойного избыточного выделения ресурсов не только снижает производительность, но также приводит к тайм-аутам запросов и сбоям приложений.

Разрешение чрезмерных конфликтов с использованием сетевого хранилища виртуальной области хранения

Один из вариантов — отключить виртуализацию хранилища в гипервизоре и вручную выделить LUN каждому гостевому приложению. Однако многие поставщики не поддерживают это. При этом также теряются важные возможности виртуализации.

Другой вариант — решить проблему со стороны хранилища, уменьшив локальные уровни избыточного выделения ресурсов в архитектуре SAN. При использовании физической сети SAN это сложно и значительно снизит эффективность сети SAN как узла виртуализации. При использовании виртуализированного хранилища SAN такая реконфигурация не только упрощается, но часто позволяет по-разному обращаться с гипервизором в зависимости от физического хоста для оптимизации общей эффективности SAN.

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