Корпоративное облако: Варианты подключения

По данным Gartner, облачные технологии становятся все более востребованными. Если в 2012 году доля рынка IaaS составляла $6,1 млрд, то в 2015 году эта цифра выросла до $16 млрд. Более того, темпы роста популярности IaaS не снижаются.

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

Сегодня все больше компаний переводят свою инфраструктуру в облако. Такой подход экономически оправдан, выгоден и удобен. Один из моментов, которые могут вызывать вопросы, это выбор подходящего метода подключения. Для подключения к облачным сервисам, как правило, применяются следующие решения: RDP-клиент, RemoteApp, веб-доступ, Remote access VPN, VPN site-to-site, DirectAccess, VDI.

RDP-клиент или подключение посредством удаленного рабочего стола является одним из самых удобных и универсальных инструментов, дающих доступ к рабочему месту, развернутому в облаке. В его основе лежит проприетарный протокол RDP (Remote Desktop Protocol) – именно он обеспечивает удаленную работу пользователя с компьютером, на котором запущен сервис терминального доступа. Пользователь через RDP-клиент подключается к серверу терминалов и видит рабочий стол удаленной системы.

В рамках установленной сессии он может запускать развернутые на сервере терминалов приложения. Безопасность такого подключения гарантирует Remote Desktop Gateway (шлюз удаленных рабочих столов), который использует RDP поверх протокола HTTPS, обеспечивая надежный метод шифрования. На сегодняшний день существуют клиенты практически для всех операционных систем семейств Windows, Linux, FreeBSD, Mac OS X, iOS, Android, Symbian.

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

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

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

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

Однако возможен и такой сценарий: сотрудникам компании из своей необлачной инфраструктуры нужно подключение к ресурсу в облаке. Для этого есть Site-to-site VPN, который подразумевает наличие двух устройств, между которыми образуется туннель.

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

Например, здесь VPN Server 1 устанавливает VPN-соединение с сервером VPN Server 2, после чего пользователь видит содержимое запрашиваемого ресурса. На стороне клиента при этом отпадает необходимость создания исходящего VPN-подключения.

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

Еще один способ – это виртуальная инфраструктура рабочих столов (VDI). Он реализован на многих облачных площадках корпоративных IaaS-провайдеров. Данная технология позволяет централизовать рабочие станции пользователей на серверах виртуализации, создав при этом единую точку управления, развертывания и обслуживания. В облаке провайдера выделяется сервер с гипервизором, на котором разворачиваются отдельные ВМ. Пользователь запускает клиент и подключается к инфраструктуре.

Такой тип подключения, на первый взгляд, мало чем отличается от RDP-подключения. Но в чем же разница? В случае RDP-подключения к терминальному серверу – это отдельная сессия на общем сервере Windows. В случае VDI – это отдельный изолированный контейнер с клиентской операционной системой.

Как мы уже упоминали выше, все большее число компаний начинают работать с облаком. Большее число… но не все. Чем облако так пугает бизнес? Одной из причин является вопрос конфиденциальности. Здесь нет ничего страшного, и чтобы спать спокойнее, необходимо просто разобраться в современных нюансах работы с информацией. Защита облачной среды принципиально ничем не отличается от традиционного ЦОД. Зачастую возможно даже использование привычных инструментов обеспечения безопасности. В частности, IaaS позволяет внедрять любые механизмы защиты и получать требуемый уровень конфиденциальности.

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

На рисунке выше представлена краткая эволюция продуктов VMware – от первых систем виртуализации до комплексных решений для корпораций и коммерческих центров обработки данных. В основе всех решений лежит технология с более чем 10-летней историей – гипервизор ESXi.

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

В качестве реального примера работы «больших» приложений в виртуальной и облачной среде можно привести продукт SAP HANA. Компания SAP давно зарекомендовала себя как ведущий мировой производитель АСУП. HANA представляет собой высокопроизводительную СУБД для требовательных приложений. Вся пользовательская информация БД хранится в оперативной памяти сервера и доступна для запроса с минимальной латентностью. Производитель подтвердил полную работоспособность этой платформы в виртуальной среде VMware.

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

Поскольку точный расчет ресурсов под терминальный сервер все-таки сложен, предлагаем рассмотреть методики, которые помогут это сделать.

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

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

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

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

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

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

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

Как видите, существуют различные методики и инструменты, с помощью которых выполняется расчет необходимых ресурсов при развертывании сервера терминалов в облаке IaaS-провайдера. Главным остается одно – это правильность использования всех рассмотренных способов.

P.S. Наши материалы по теме на Хабре:

Автор: ИТ-ГРАД

Источник