Новая гиперконвергенция, старое хранилище

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

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

Конечно, существуют очевидные варианты: вернуть арендованное оборудование, списать более старое или продать ещё полезное. Это жизнеспособные опции, и их стоит рассматривать. Избавление от старого оборудования или техники, которая плохо вписывается в текущие планы, может быть выгодным: мы упрощаем сети, снижаем энергопотребление и, возможно, частично возмещаем вложения.

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

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

Разумеется, всё, что пригодно для резервного копирования, может также использоваться для архивного хранения. Потребности в архивировании, как правило, менее распространены (лишь часть компаний нуждается в архивном хранении, тогда как резервное копирование нужно всем) и менее приоритетны, поэтому этот вариант — скорее нишевый, но его тоже следует рассматривать — особенно для организаций, которые стремятся перепрофилировать большое количество возможно разнородных устройств хранения. Однако стоит отметить, что переход к гиперконвергенции действительно имеет тенденцию «выравнивать» вычислительное и дисковое пространство таким образом, что может наглядно подчеркнуть ценность низкопроизводительного архивного хранилища с низким приоритетом — той ценности, которой прежде не существовало или которая не была столь очевидна до переосмысления архитектуры среды.

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

Как SAN, так и NAS могут быть подключены непосредственно к виртуальным машинам, работающим поверх гиперконвергентной инфраструктуры. Таким образом их можно продолжать использовать в традиционном режиме до тех пор, пока они не перестанут быть нужными или уместными. Хотя подключение сетевого хранилища напрямую к виртуальной машине нередко не является рекомендуемым подходом, для него существуют свои сценарии использования, и он позволяет системам вести себя в будущем так же, как они всегда вели себя в физической среде. Это особенно удобно для подключённых дисков и пользовательских каталогов через NAS — как мы уже упоминали применительно к конечным устройствам пользователей, — хотя сценарии использования, разумеется, не ограничиваются этим.

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

Работа с существующей инфраструктурой при внедрении новой действительно представляет определённую сложность, однако подойти к ней можно творчески и с логичным подходом. Хранилище — почти бесконечная задача, и наличие существующих ресурсов хранения для перепрофилирования вполне может оказаться исключительно выгодным.