Как извлечь максимум из «Перевёрнутой пирамиды смерти»

Архитектура 3-2-1, известная как «Перевёрнутая пирамида смерти», по многим причинам стала изгоем IT-отрасли. К сожалению, многие компании узнают об опасностях этого дизайна лишь после того, как оборудование уже доставлено, а деньги ушли со счетов.

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

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

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

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

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

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

Но, скорее всего, простой переход на одиночный сервер с надеждой найти применение оставшемуся оборудованию «в другом месте» не будет нашим лучшим вариантом. В ситуациях, когда IPOD предназначался только для одной рабочей нагрузки или набора рабочих нагрузок, а в других областях бизнеса также есть потребность в оборудовании, может быть очень выгодно перейти к подходу «одиночный сервер» для предполагаемой нагрузки IPOD и использовать оставшееся оборудование в других частях бизнеса.

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

Эти узлы затем можно настроить по одной из двух моделей высокой доступности. В прошлом распространённым дизайнерским решением (по соображениям стоимости) была асинхронная модель репликации (часто называемая подходом Veeam), которая реплицирует виртуальные машины между узлами и позволяет очень быстро включить ВМ, сократив время простоя с момента отказа вычислительного узла до восстановления до нескольких минут.

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

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

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

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

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

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

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

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