Виртуальные яйца и корзины

В беседах со специалистами в области IT для малого бизнеса одним из ключевых факторов нерешительности при развёртывании виртуализации оказывается то, что описывается как принцип “не клади все яйца в одну корзину”.

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

Смысл идиомы о яйцах и корзинах состоит в том, что не следует одновременно подвергать риску все свои ресурсы. Традиционно она применяется в сфере инвестиций, призывая инвесторов диверсифицироваться и вкладывать средства в различные компании и типы ценных бумаг: облигации, акции, фонды и сырьевые товары. В случае с яйцами (или деньгами) речь идёт о взаимозаменяемом товаре. Одно яйцо ничем не хуже другого. Набор яиц по своей природе избыточен.

Если у нас есть дюжина яиц и мы разобьём шесть, мы всё равно сможем приготовить омлет — возможно, поменьше, — но поесть всё-таки удастся. Съесть омлет поменьше, скорее всего, почти так же приятно, как и большой: голодными мы в любом случае не останемся. Раскладывание уже по природе своей избыточных яиц по нескольким корзинам позволяет снизить риски. Да, переноска двух корзин означает, что на каждую из них приходится меньше внимания, а значит, риск потерять часть яиц возрастает, зато снижается вероятность потерять все яйца сразу. В случае с яйцами — разумное решение. Аналогично — грамотный подход к формированию пенсионных накоплений.

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

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

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

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

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

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

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

При консолидации мы сокращаем количество оборудования, которое IT-отдел должен отслеживать и обслуживать. Меньше серверов означает, что больше времени и внимания можно уделить тем, что остались. Больше внимания означает лучшие шансы выявить проблемы на ранней стадии и больше возможностей держать запасные части под рукой. Лучший мониторинг и техническое обслуживание ведут к повышению надёжности.

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

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

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

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

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

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

В том же ключе виртуализацию нередко опасаются из-за того, что воспринимают её как новую, непроверенную технологию. Это, безусловно, не соответствует действительности, однако именно такое впечатление сложилось в сфере малого бизнеса и товарных серверов. В действительности же виртуализация была впервые введена компанией IBM в 1960-х годах и с тех пор является неотъемлемой частью высококлассных мейнфреймов и RISC-серверов — тех систем, которые предъявляют наивысшие требования к надёжности. На рынке товарных серверов виртуализация представляла собой более серьёзную техническую задачу и очень долго оставалась недостаточно эффективной для практического применения. Но даже в сегменте товарных серверов виртуализация доступна с конца 1990-х годов — то есть ей уже около пятнадцати лет, что значительно превышает возраст, при котором технологию ещё можно считать новой. В мире IT это поистине почтенный возраст. Виртуализация на товарных платформах — зрелая область с несколькими уважаемыми, чрезвычайно продвинутыми вендорами и продуктами. Использование виртуализации в качестве стандарта для всех или почти всех серверных приложений является давно устоявшимся и признанным «корпоративным паттерном», который теперь легко может быть принят компаниями любого размера.

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