Как СХД предыдущего поколения “съедают” положительную рентабельность виртуализации

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

Виртуальные машины, развернутые на физических серверах, обслуживают десятки бизнес-приложений с различными I/O профилями данных, которые поступают от разных приложений, сильно отличающихся друг от друга. В этих условиях оптимальная настройка производительности подсистемы хранения становится очень трудоемкой задачей. Чтобы с ней справиться, администраторам приходится вручную вести детальную опись всех LUN на всех ВМ и уже на её основе пытаться определить в реальном времени, из-за какого узла падает производительность.

Иногда системные архитекторы намеренно создают сверхпроизводительные хранилища и/или минимизируют количество ВМ, создаваемых на гипервизоре чтобы перестраховаться от падения производительности. Но это губит все блага виртуализации – прежде всего – снижение затрат на инфраструктуру и простоту управления ЦОДом. И не так уж неправы те системные архитекторы, которые описывают как хвост-хранилище машет виртулизированной собакой. На самом деле нужно кардинально менять подход к организации хранения данных в средах виртуализации. На недавнем вебинаре Storage Switzerland и Tintri участникам задали вопрос: “Что для вас самое сложное в организации хранения – помимо показателей производительности СХД?”

Ответы распределились следующим образом:

 

Из этого следует, что администраторы обоснованно считают, что СХД предыдущего поколения попросту не справляются с превратностями мультипользовательской виртуализации.

Этот фактор, в свою очередь, негативно влияет на ROI и стоимость проекта виртуализации в целом. Во-первых, если из-за низкой производительности хранилище не обеспечивает SLA, необходимый для обслуживания ключевых ВМ, владельцы приложений, которые расположены на этих ВМ, просто сменят поставщика. Альтернативой могут стать активно развивающиеся облачные технологии: такие компании, как Amazon ждут подходящий момент, чтоб перейти на их использование. Во-вторых, системные администраторы будут тратить львиную долю времени на оперативные задачи, это может просто уничтожить выгоду от консолидации серверов, полученную на начальном этапе проекта. И, наконец, если ВМ на серверах будут намеренно размещаться с низкой плотностью из-за ограничений системы хранения данных, это помешает гибкости бизнеса и увеличит расходы. Дело в том, что принципы хранения должны меняться, чтобы соответствовать развитию виртуализации.

Администрирование СХД необходимо предельно упростить, чтобы у администраторов всегда была полная актуальная информация о состоянии виртуальной среды сервера и связанной с ним СХД. Сами хранилища должны быть снабжены структурированной информацией о всех связанных с ними ВМ. Настройка производительности тоже нуждается в автоматизации. Если в подсистемы хранения еще на стадии проектирования закладывать способность обработки 99% I/O запросов исходя из требовательности процесса и распределять хранение неактивных данных на более дешевом хранилище, вместо более быстрой флэш-памяти, из чего следует, что на гипервизорах можно будет расположить больше ВМ. Это намного более выгодно экономически и администраторы смогут меньше времени тратить на настройку. Более того, для предоставления необходимой полосы пропускания виртуальным приложениям больше не придется создавать хранилища с избыточной производительностью.