Виртуализация, облако и традиционные вычисления: каков правильный ответ?

Введение

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

Давайте начнем

Давайте начнем эту статью с быстрого опроса: сколько раз сегодня вы видели или слышали слово «облако» на веб-сайтах, которые вы посещаете, в технической литературе, которую вы читали, или в презентациях, которые вы слышали? Готов поспорить, что это слово встречалось много-много раз, во многих контекстах и что с ним было связано много обещаний.

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

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

Виртуализация также принесла с собой огромный спрос на новые наборы навыков. В то время как более крупные организации всегда нуждались в таких навыках, как глубокое управление хранилищем, Fibre Channel и т. п., виртуализация подтолкнула потребность в такого рода наборах навыков в небольших организациях, которые хотят воспользоваться всеми преимуществами волны технологий виртуализации. Кроме того, потребность в изучении самого гипервизора стала серьезной потребностью для таких компаний, как VMware, которые устанавливают популярные и востребованные сертификаты для удовлетворения этого спроса. Виртуализация и необходимость иметь возможность тщательно отслеживать и управлять этими современными средами также привели к созданию очень успешных новых компаний, таких как Veeam и VKernel, и к успеху запустили множество сайтов, посвященных этому ремеслу, включая наш собственный virtualizationadmin.com.

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

Войдите в облако

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

Хотя облако может быть похоже на аутсорсинг услуги, оно также может предоставлять организациям измеряемые услуги, которые позволяют им платить только за то, что они используют, а не платить за инфраструктуру, которая в противном случае могла бы простаивать. Когда выбраны правильные поставщики, облачная установка также может обеспечить масштабируемость по требованию и позволить организации развертывать массовые услуги без необходимости покупать массивную инфраструктуру. Или облако может позволить организации работать 98 % времени на одном уровне производительности, а когда, например, запускается новый продукт, наращивать мощность на оставшиеся 2 % времени.

Панацея

Итак, каков правильный ответ? Вернуться во времена физических серверов? Является ли правильным ответом просто продолжить путь виртуализации в одиночку? Или организации должны просто выбросить свои центры обработки данных и перенести абсолютно все в облако?

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

Физическая инфраструктура

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

• Сервер камеры видеонаблюдения. Мы поддерживаем сервер, предназначенный для управления и хранения всех различных видеопотоков с наших IP-камер безопасности. Эта система использует довольно значительные ресурсы сети и хранилища, и на самом деле ей не нужны функции доступности, которые можно найти в нашей виртуальной среде. Хотя мы могли бы массово развернуть относительно недорогое хранилище на основе iSCSI для поддержки этой службы, вместо этого мы решили развернуть службу с большим количеством недорогих дисков SATA с прямым подключением.
• Службы резервного копирования. В Вестминстере мы продолжаем поддерживать традиционную службу резервного копирования серверов и данных на основе Microsoft Data Protection Manager 2010. Хотя DPM 2010 может работать виртуально, фактически мы размещаем нашу резервную копию в безопасном дополнительном кампусе.
• Система базы данных. В настоящее время наш основной экземпляр SQL Server 2008 R2 работает на физическом сервере. Однако это связано в первую очередь с ресурсами в виртуальной среде. Недавно мы расширили нашу виртуальную среду новой SAN и дополнительной оперативной памятью, и теперь я чувствую, что инфраструктура справится со всем, что мы можем ей предложить. Таким образом, в ближайшем будущем эта служба будет перенесена на виртуальную машину.

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

Когда дело доходит до чистой производительности и локальной масштабируемости, то есть внутри организации, физические серверы превосходят своих виртуальных аналогов. Некоторые из самых мощных на сегодняшний день физических серверов имеют 24 вычислительных ядра, невероятную плотность оперативной памяти 192 ГБ и поддержку многих терабайт внутренней памяти. Если вы серьезно загружаете огромную рабочую нагрузку и не можете разбить ее на более мелкие части, физические серверы остаются острой необходимостью. Если для вас важны процессорные ядра, ограничение VMware vSphere в 8 виртуальных ЦП может быть слишком строгим для ваших нужд.

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

Виртуальная инфраструктура

Я уже упомянул о некоторых основных преимуществах виртуализации, но это был следующий шаг на пути ИТ, и он был великим. Сегодня мне не нужно ждать недели, чтобы предоставить новую услугу; Я просто запускаю новую виртуальную машину, что занимает всего 5 минут. Если служба начинает загружать процессор на 100 %, я просто добавляю еще один процессор. Если места на диске становится мало, я расширяю виртуальный диск. Виртуализация предоставила ИТ-отделу невероятную гибкость и возможность быстро и немедленно реагировать и исправлять проблемы с ресурсами.

Если бы мне пришлось указать на недостатки виртуализации, я бы назвал сложность, хотя я вижу всю среду элегантно простой. Однако, когда я отступаю назад, я понимаю, сколько движущихся частей — серверов, хранилищ, гипервизора, сетевого оборудования, коммутаторов Fibre Channel — нужно, чтобы все это работало. Тем не менее, это все равно проще, чем управлять 50 или 60 физическими серверами!

Облачные сервисы

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

Предположим для этой статьи, что облачные игры вращаются вокруг использования таких сервисов, как Amazon Cloud или Microsoft Azure. Например, при использовании Azure и при условии, что клиенты используют Hyper-V, существует возможность перемещения виртуальных машин туда и обратно между локальными экземплярами Hyper-V и облаком на основе Azure. Представьте себе потенциальные сценарии аварийного восстановления или сценарии, в которых компания должна была быстро и эффективно масштабировать услуги сверх того, с чем могла справиться их существующая скорость подключения к Интернету. Кроме того, я рассматриваю пропускную способность Интернета как ахиллесову пяту облака, и пока мы не получим дешевое, быстрое и надежное подключение везде и всюду, весь потенциал облака не может быть реализован.

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

Ответ

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

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