Процесс миграции ИТ в облака, начавшийся несколько лет назад, очень напоминает Великое переселение европейских народов в IV–VI веках, начавшееся после падения Римской империи. Переселению народов — как и сейчас в технологиях — предшествовала эпоха стабильности, и ничто не предвещало подвижек, но вдруг все пришло в движение. Подобно своему историческому аналогу, эпоха великого переселения ИТ рано или поздно закончится, и тогда мы станем свидетелями нового устойчивого миропорядка, причем не только в ИТ. А пока стоит посмотреть, кто и куда переселяется.

Облака: что выбрать?

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

Среди экспертов бытует мнение, что облака — это возврат к мэйнфреймам, которые в отличие от «большого железа» 60–70-х годов обладают качествами, сформулированными Национальным институтом стандартов и технологии США (NIST):

  • модель оплаты по мере использования ресурсов с минимальным начальным вкладом;
  • эластичность — пользователь потребляет ровно столько ресурсов, сколько ему нужно;
  • отсутствие привязки к определенному местоположению;
  • доступ к ресурсам в виде сервисов из произвольных мест в различных форматах.
Мэйнфреймы XXI века

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

Леонид Черняк

Облака могут стать источников для предоставления трех основных типов сервисов: инфраструктурных (Infrastructure as a Service, IaaS), включающих серверы, системы хранения и сетевые ресурсы; платформных (Platform as a Service, PaaS), необходимых для развертывания приложений; транспортных, необходимых для доставки приложений по подписке (Software as a Service, SaaS). Если функционал облака ограничен корпоративной информационной системой, тогда можно говорить о частном облаке, и для создания такого облака используется собственная аппаратно-программная инфраструктура, но может быть арендована инфраструктура и у внешнего провайдера. Услуги публичных облаков предлагают специализирующиеся на них компании-провайдеры. Гибридные облака сочетают в себе свойства первых двух.

Из всего этого разнообразия предприятиям сейчас приходится делать выбор, а в том, что делать выбор рано или поздно придется, сомнений нет — о мощи миграционного потока можно судить по оценкам Gartner, эксперты которой оценивают в 112 млрд долл. затраты на облака в мировом масштабе на ближайшие пять лет. Эта оценка может измениться в большую сторону — ситуация заметно меняется, например, по данным британских аналитиков, в 2009 году 57% местных предприятий еще не рассматривали для себя облачную перспективу, а два года спустя уже 77% были либо уже в процессе миграции, либо в стадии подготовки к ней.

Проблемы частных облаков

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

Создаваемое облако должно быть динамичным, поэтому в проекте миграции должны быть предусмотрены средства мониторинга инкапсуляции новых компонентов. Затем закупается необходимое для начального периода существования облака аппаратное и программное обеспечение (с учетом возможности масштабирования), а далее составляется план работ по переносу приложений на IaaS частного облака. К этой работе помимо программистов необходимо привлечь представителей ИТ-подразделений, отвечающих за серверы, системы хранения, сети, а также владельцев и пользователей приложений. Наконец, поскольку отношения с потребителями переводятся в сервисный режим, должны быть подготовлены и заключены соглашения об уровне обслуживания (Service Level Agreement, SLA).

ITSM, набросок книги

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

Леонид Черняк

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

Одно из самых серьезных препятствий на пути в частные облака заключается в отсутствии полноценных комплексных методик и решений, используя которые можно собрать инфраструктуру частного облака. Несмотря на многообещающие заявления, по состоянию дел на начало 2012 года ни один производитель, ни один интегратор не в состоянии предложить полный набор технологий и услуг, необходимых для создания частного облака, который включал бы не просто виртуализацию серверов, сетей и систем хранения, но и средства автоматизации управления ресурсами и оркестровки сервисов. Неслучайно поставщики сегодня лукавят, предлагая свои собственные определения частных облаков, которые сводятся к виртуализации, а нередко и вовсе ограничивая создание облака всеобщей виртуализацией. Однако виртуализация ресурсов — это лишь часть целого. Можно с успехом тотально виртуализовать все возможные пулы ресурсов, но результатом будет их простая совокупность, которую нельзя рассматриваться как облако. Здесь уместна аналогия частного облака с мэйнфреймом — компьютером, все узлы которого объединены устройствами управления и операционной системой. В облаках эту интегрирующую функцию выполняет оркестровка (orchestration), суть которой в координации доставки ресурсов для формирования единого процесса, позволяющего за кратчайшее время из отдельных пулов создать среду для выполнения того или иного приложения. Иначе говоря, сделав один запрос к облачной «операционной системе», получить все необходимое. Отработка такого запроса должна выполняться с минимальным участием человека.

 

Миграция без проблем

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

Мы не предлагаем каких-либо специализированных решений для облаков или программных решений по виртуализации, однако наши продукты отвечают потребностям заказчиков и партнеров, активно использующих облачные решения, в том числе, например, Amazon EC2. Поэтому начиная с 2010 года решения InterSystems Cache и InterSystems Ensemble работают не только под управлением ОС Windows или Unix, но и на Amazon EC2 с ОС Red Hat Enterprise Linux. Каждый релиз продуктов InterSystems специально тестируется и оптимизируется для работы под Amazon EC2.

Мы стараемся, чтобы при использовании наших технологий затраты заказчиков на миграцию приложений в облака были минимальны. Сегодня в компании ведется работа по подготовке дистрибутива InterSystems Cache и Ensemble, который можно будет разворачивать и настраивать для платформы компании RightScale, специализирующейся на решениях по миграции приложений в облако и управлении гибридными инфраструктурами, поддерживающими облачные сервисы Amazon EC2, GoGrid, Eucalyptus и Rackspace. Одновременно идет работа по оптимизации продуктов InterSystems для работы в виртуализированных средах, в частности, совместно с инженерами VMware выполнялось тестирование технологий для конкретных заказчиков.

— Олег Оленин (oleg.olenin@intersystems.com), технический консультант компании InterSystems (Москва).

 

Как ни странно, место и значение оркестровки были признаны совсем недавно, хотя, казалось бы, очевидно, что инфраструктура не может существовать без средств управления, иначе это просто набор пулов разных ресурсов. Тем не менее процесс заимствования технологий и методов и средств управления из публичных облаков в частные начался с заметным опозданием. Среди этих технологий следует отметить средства для измерения и взимания оплаты (metering and chargeback), инструменты автоматизированного конфигурирования (automated configuration) и автономного снабжения сервисами (self-service provisioning). Одна из наиболее продвинутых работ в этом направлении осуществляется в рамках проекта с открытыми кодами OpenStack, инициированного компанией Rackspace и NASA. К 2011 году число его участников возросло до 138, включая AMD, Citrix, Dell, HP, Intel и NEC. На базе OpenStack некоторые компании создают коммерческие продукты, например Project Olympus от Citrix.

Мэйнфрейм для бедных?

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

Леонид Черняк

Еще одно непременное качество настоящего внутреннего облака — динамическое масштабирование, имеющее два разных лица, но общую основу в виде виртуализации, обеспечивающую развод между приложениями и серверами, на которых эти приложения работают. Одно лицо обращено вовнутрь, отражая изменения в аппаратно-программной инфраструктуре, отличающие обычный ЦОД от облачного, — работая с облаком, инженеры могут оценивать его свойства как единого целого и развивать частное облако в процессе эксплуатации. Иногда для этого типа деятельности используют более точное название — re-architecture. Второе обращено вовне — это предоставление ресурсов IaaS пользователям в соответствиии с их изменяющимися потребностями. Пользователи могут заказать для своих приложений столько ресурсов, сколько считают нужным. То обстоятельство, что технологии виртуализации и автоматизации «отвязывают» приложения от заранее выделенных серверов, приводит к перераспределению функций между пользователями и обслуживающим персоналом: последний перестает контролировать, где и как работают приложения, — автоматизация позволяет выполнять эту работу пользователям опосредованно, арендуя нужные им ресурсы.

Миграция и типы сервисов

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

  • Трафик глобальных сетей. Какие бы методы оптимизации трафика ни обеспечивал провайдер, можно предположить, что работа с приложениями, обмен данными с другими ЦОД и вообще все действия, связанные с обменом данными, будут создавать значительный объем трафика, что может оказаться заметной статьей расходов.
  • Безопасность данных и надежность хранения. За последние годы в вопросах безопасности облачных данных достигнут заметный прогресс, о чем свидетельствует деятельность таких организаций, как Cloud Security Alliance, комиссий Евросоюза и других структур, тем не менее еще далеко не все компании и организации готовы передать вовне критически важные сведения. Что же касается надежности, то известны случаи потери клиентами своих данных и ухода провайдеров облачных сервисов с рынка. В этой связи примечателен пример компании Mag.nolia, которая одной из первых предоставила сервисы в области социальных закладок, сегодня монополизированной Twitter. Другие пионеры были потеснены, но живут, а Mag.nolia не повезло — она в одночасье ушла с рынка из-за потери базы пользовательских данных. Печальный эпизод случился 25 января 2009 года из-за недостаточной надежности системы резервного копирования. Вице-президент Oracle Тодд Спрагинс сказал по этому поводу: «Если облако падает, оно превращается в туман». Гибель Mag.nolia стала предметом исследования для тех, кто занимается надежностью облаков, и уроком для провайдеров сервисов Web 2.0, таких как Wikipedia, Flickr, Twitter и WordPress, вошедших в состав современной культуры.
  • Наличие унаследованных приложений. Публичные облака обычно создаются на базе виртуализированных серверов стандартной архитектуры, работающих под управлением ОС Windows или Linux, но в багаже компании могут быть и Unix-приложения или приложения, разработанные для AS/400, серверы для выполнения которых можно включить в состав частного облака.
  • Требования безопасности и соответствие нормативным требованиям. Если система находится в собственности компании, то удовлетворить этим требованиям иногда проще.

Типовых решений для миграции пока нет, поэтому каждая организация вынуждена искать свои решения, и на выбор предпочтительного типа облака влияют самые разнообразные требования: производительность, объем данных и трафика, готовность, критическая важность, имеющиеся технологические ресурсы, размер инвестиций и другие факторы, в том числе принятые на предприятии нормативы. Для решения отдельных проблем существуют средства автоматизации, например Novell PlateSpin Recon или VMware Capacity Planner. При этом для некоторых приложений больше подходит миграция в публичные облака, а для других предпочтительны частные. К последним относятся критически важные задачи, требующие отказоустойчивых платформ и особых условий обеспечения безопасности, а также приложения, в которых реализованы специфичные алгоритмы, работающие на специализированном оборудовании. В основном это унаследованные приложения, но есть и новые, удачно реализуемые в облаках, — прежде всего они так или иначе связаны с Web, где нагрузка сильно варьируется, могут быть пики и спады, требуется собирать большие объемы данных. Иногда такие приложения выглядят неожиданно — например, одна известная антивирусная компания использует публичное облако для анализа данных о вирусных угрозах. В некоторых случаях наиболее удачной оказывается схема, когда в период разработки используются ресурсы публичных облаков, а на период эксплуатации приложение переносится в частное.

Если учесть, что для предприятий уровня Fortune 1000 наиболее важным является обеспечение сохранности данных, а все остальные задачи вторичны, то очевиден выбор в пользу частного облака или, в крайнем случае, внешнего частного, но обслуживаемого собственным персоналом. Предприятия меньшего масштаба могут отдать предпочтение и публичным облакам. По мнению аналитиков Gartner, основной поток инвестиций в ближайшее время будет направлен в частные облака с моделью IaaS.

Software as a Service. Переход на модель SaaS сводится лишь к перемещению в облака данных. Предполагается полный отказ от существующих приложений и использование взамен них тех, которые предлагает провайдер. Преимущество SaaS — это возможность избавиться от работ, связанных с развертыванием и поддержкой инфраструктуры и приложений, что привлекает, но не следует забывать о том, что критичными становятся такие факторы, как качество обслуживания, возможность портирования данных, стоимость аренды приложений в долговременной перспективе и безопасность.

  • SLA. С точки зрения качества обслуживания очень важно, чтобы поставщик сервисов SaaS был в состоянии четко сформулировать показатели готовности, надежности и производительности предлагаемых ресурсов, а также то, как обеспечиваются поддержка и модернизация предоставляемых им приложений. То же самое относится и к средствам поддержки и информационной безопасности.
  • Перенос данных. Провайдер SaaS обязан показать заказчику, как за ним обеспечивается сохранение права владения данными и каким образом он может их контролировать. Пользователи должны иметь возможность в любой момент экспортировать принадлежащие им данные в тех форматах, в которых они доступны, для разбора и импорта обратно в их собственные или какие-то иные внешние приложения. Это чрезвычайно важно, и даже весьма известные провайдеры страдают сегодня тем, что готовы вернуть данные, скажем, в текстовой форме, предоставляя далее клиенту возможность самому разбираться в сложившейся ситуации.
  • Затраты в долговременной перспективе. Модель SaaS обладает привлекательностью, особенно для предприятий малого и среднего бизнеса, по той причине, что исключает необходимость каких-либо затрат на собственные ЦОД и требует минимальных вложений на начальной стадии. Однако она имеет ровно те же самые недостатки, как и любые финансовые лизинговые схемы, — может оказаться, что сумма выплат окажется выше, чем стоимость владения собственной инфраструктурой.

Platform as a Service. Данное направление миграции приложений в наибольшей степени подходит для платформ Java EE 5 или Microsoft. NET. В этой модели провайдер управляет платформами приложений и обеспечивает доступ к общим сервисам, например к базам данных на SQL. Пользование платформой может быть распределено между множеством потребителей, а то, как такая платформа отображена на физическую инфраструктуру, контролируется провайдером. Решающим фактором в выборе этого пути миграции служит наличие соответствующего сервера приложений, однако некоторые платформы PaaS не поддерживают всех функций серверов приложений и тогда потребуется внести какие-то изменения в приложения. При этом, как и в случае SaaS, возникают вопросы, связанные со SLA и переносом данных, а также новые, связанные с установкой интерфейса между платформой и приложениями.

  • SLA. Провайдер PaaS должен гарантировать заданный уровень готовности и производительности, ясные правила и практику управления, а также контроль версий, но главное — интерфейс между платформой и приложениями.
  • Перенос данных. В модели PaaS данные обычно хранятся в базах, предоставляемых провайдерами, поэтому чрезвычайно важно, чтобы заранее была оговорена возможность экспорта хранимых в них данных именно в форматах, приемлемых для пользователя.
  • Затраты в долговременной перспективе. Прежде чем переходить на модель PaaS, необходимо самым тщательным образом провести сравнение с альтернативным решением, предоставляемым IaaS, — в ряде случаев выгоды могут оказаться не на стороне PaaS.
  • Управление. В модели PaaS сочетаются два типа управления: приложение контролирует пользователь, а сервер приложений — провайдер, он же должен гарантировать динамическое масштабирование платформы, а с точки зрения безопасности — «мирное сосуществование» разных приложений в пределах одной платформы.

Infrastructure as a Service. Действия по этой модели миграции начинаются с проверки соответствия серверов и ОС провайдера тем серверам и ОС, на которых работают приложения заказчика в текущий момент. Если полного соответствия нет, то предстоят перекомпиляция и повторное развертывание. Требования к провайдеру IaaS ниже, чем в двух предшествующих случаях.

  • SLA. Эти требования сводятся к показателям производительности и готовности. Размещение приложений от разных пользователей на разных физических машинах упрощает требования к безопасности.
  • Перенос данных. В основном следует обращать внимание на возможность репликации данных из СУБД, предоставляемых провайдером.
  • Затраты в долговременной перспективе. Эта статья затрат мало отличается от издержек, связанных с созданием собственных ресурсов, к тому же есть очевидное преимущество — проще решаются вопросы масштабирования.
  • Управление. Пользователь берет на себя все три функции — администратора серверов, приложений и данных.
  •  

Портал в облака

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

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

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

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

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

— Анатолий Третьяков (anatoly.tretyakov@ts.fujitsu.com), менеджер по маркетингу сервисных продуктов компании Fujitsu (Москва).

 

Smart Style — модель для сборки

Представление о том, что такое частное облако, дает продукт Smart Style Computing, предложенный индийской компанией Zenith Infotech. Хотя он ориентирован на небольшие предприятия со стандартными запросами, в нем отражается вся облачная картина и его вполне можно рассматривать как модель или учебное пособие по частным облакам.

С архитектурной точки зрения Smart Style — это типичный грид из узлов трех типов: вычислительный узел (CPU/RAM Node), узел хранения (Storage Node) и комбинированный узел (Combination Node). Для небольшого предприятия можно ограничиться комбинированными узлами. Компания Zenith Infotech в основном производит ПК и занимает второе место на индийском рынке, но в данном случае предлагает свой продукт партнерам, развертывающим облака на предприятиях клиентов. В минимальный комплект Evaluation Kit, который может заказать партнер, входит три комбинированных узла — этого достаточно для поддержки двух виртуальных серверов и десяти рабочих мест. Для виртуализации серверов используется гипервизор, работающий поверх ОС Linux. Реальное облако собирается из произвольного сочетания узлов трех типов, и главное в том, что этот кластер превращается в облако благодаря нескольким программным решениям: управляющему центру Cloud Management Center, который служит для администрирования серверов и виртуальных машин; обеспечивающей Smart Style надежность технологии BitSpread, позволяющей объединить недорогие узлы в массив, в котором в случае выхода из строя одного узла его функции перераспределяются между оставшимися; и технологии резервного копирования Mirror Cloud.

 

Ориентация на частные облака

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

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

Традиционные ЦОД будут постепенно превращаться в частные облака, но перемены могут не затронуть унаследованные приложения, не поддающиеся виртуализации. Остальные приложения должно быть готовы для запуска в облачном окружении, что иногда потребует модификации кода с помощью решения IBM Rational. Собственно миграция осуществляется средствами IBM Tivoli и таких специализированных компонентов как Galapagos — системы на основе моделей, позволяющей доставлять бизнес-приложениям данные, разбросанные по разным территориально распределенным системам хранения. Кроме этого, в зависимости от задач, для осуществления миграции мы предлагаем такие решения, как IBM Service Delivery Manager, IBM Tivoli Service Automation Manager, IBM Workload Deployer и IBM SmartCloud Provisioning.

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

— Алексей Мирошкин (alexey.miroshkin@ru.ibm.com), руководитель направления разработки средств виртуализации Научно-технического центра IBM в России и СНГ (Москва).

 

***

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

___________

1 В число технологических лидеров массового движения к частным облакам, несомненно, входит компания VMware, а альтернативного движения — Citrix. Для первой груз наследования — виртуализация серверов, а для второй — доставка приложений, отсюда и противоположные направления векторов облачной стратегии. — Прим. автора.

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF