Перенос физической ИТ-инфраструктуры в виртуальную среду (в облако), миграция данных

Любой бизнес ориентируется на оптимизацию затрат, в том числе на ИТ. Одним из способов оптимизации является переход в облако. Но при переносе сервисов в виртуальную среду надо учесть ряд особенностей

Миграция ADDS и MSSQL без остановки сервисов

Зачастую бизнес предъявляет повышенные требования к до­ступности ряда сервисов в ходе миграции. Миграция воз­можна даже без остановки сервиса, к тому же такой способ часто является рекомендуемым и самым надежным. К по­добной ситуации можно отнести отмеченные ранее особен­ности миграции наиболее популярных служб ОС Microsoft, таких как Active Directory Domain Services (ADDS или чаще просто AD) и Microsoft SQL (MSSQL). Главной целью особого подхода к миграции в этих случаях является минимизация простоя сервиса.n

Наша компания предоставляет услуги по миграции сервисов в облако установленных на Windows/Linux, подробности [email protected]

Для миграции Active Directory без остановки службы при­меняет следующий алгоритм:n

• >   Организуется сетевая связность между физическим оборудованием и облаком. Обычно это site-to-site VPN, позволяющий организовать логическую сеть поверх другой сети (например, интернет). Трафик в такой сети может быть дополнительно защищен шифрованием с использованием протоколов IPsec.
• >   В виртуальной среде разворачивается необходимое количество новых виртуальных машин из шаблона, в которых настраиваются контроллеры домена AD с до­бавлением их в имеющийся лес.
• >   База данных Active Directory реплицируется по сети че­рез VPN с уже работающих контроллеров на стороне физического оборудования в облачные.
• >   После завершения репликации данных переназнача­ются мастера ролей операций на облачные контролле­ры и убираются роли контроллеров домена с физиче­ских серверов.
• >   После проверки исправной работы сервисов отключа­ются учетные записи старых контроллеров и само фи­зическое оборудование.

Миграция — это не так сложно, главное — взвешенно подойти к вопросу выбора сервис-провайдера

Для миграции MSSQL с минимизацией времени оста­новки службы применяется более сложный алгоритм, так как MSSQL, как правило, используется в многоуровне­вом сервисе в качестве бэкенда. В отличие от AD, где кли­енты в подавляющем числе случаев находят доступные контроллеры AD автоматически, используя DNS, в прило­жениях, использующих базы данных (в клиентах MSSQL), приходится указывать новое расположение базы данных вручную. Поэтому полностью исключить простой нельзя, но его можно минимизировать. Если разбираться глубже, конечно, существуют механизмы безостановочной мигра­ции MSSQL, такие как Mirroring и AlwaysOn, но применение этих механизмов не всегда оправдано. AlwaysOn доступен только в дорогих Enterprise-редакциях, а Mirroring должен поддерживаться клиентами MSSQL. К тому же в случае при­менения механизмов Mirroring нужно провести дополнитель­ную настройку всех клиентов MSSQL.nnТакие ситуации редки, поэтому рассмотрим наиболее ча­стый вариант миграции MSSQL в облако:n

• >   Организуется сетевая связность между физическим оборудованием и облаком.
• >   Необходимо убедиться, что модель восстановления базы MSSQL полная, в таком случае можно сделать и перенести полную резервную копию, а затем синхро­низировать две базы данных посредством переноса резервных копий транзакционных логов.
• >   В виртуальной среде разворачивается новая виртуаль­ная машина из шаблона, в которой устанавливается и настраивается новый MSSQL-сервер.
• >   Создается полная резервная копия базы данных MSSQL-сервера, работающего на физическом обору­довании, и далее она восстанавливается в облачном, при этом способ переноса файла резервной копии за­висит от ее размеров и пропускной способности сети, настроенной между площадками (физическое переме­щение на носителе либо копирование по сети).
• >   После переноса и восстановления базы данных в об­лаке делается резервная копия транзакционных логов, и они аналогично восстанавливаются в облаке, эту операцию можно повторить, постепенно минимизируя рассинхронизацию баз данных.
• >   На заключительном этапе переноса, во время «окна миграции», останавливается работающий на физиче­ском оборудовании MSSQL-сервер, создается и вос­станавливается последняя (уже минимальная по раз­меру) резервная копия транзакционных логов в облаке, запускается MSSQL-сервер в облаке, и клиенты пере­ключаются на новое месторасположение базы.
• >   После проверки исправной работы сервисов, физиче­ское оборудование можно отключать.

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

Чем больше сервисных услуг потребляет компания, тем она эффективнее и успешнее

Преимущества использования облака

В чем же в целом причины и целесообразность таких ин­фраструктурных изменений в компании, как миграция в об­лака?nnОдна из причин — это проблема, связанная с недостаточ­ным объемом вычислительных ресурсов имеющейся инфра­структуры и их неоптимальное использование для решения постоянно растущих бизнес-задач компании. За исходную точку возьмем наиболее популярную на сегодня ситуацию, когда ИТ-инфраструктура размещена в коммерческом да­та-центре и часть информационных сервисов работает на пределе возможностей обслуживающих их физических серверов. Рассмотрим нюансы масштабирования каждого типа сервиса по отдельности.nnОдна из частых ситуаций, когда не хватает производи­тельности вычислительной подсистемы для одного сервиса. Классическим решением этой проблемы является замена физического сервера на более производительный. Такая замена довольно накладна с финансовой точки зрения: кроме стоимости самого сервера, требуется немало согла­сованных действий — начиная от инсталляции и настройки сервера до миграции информационных сервисов со старо­го оборудования на новое.nnРешение, конечно, не новаторское, но проверенное вре­менем и имеет место быть. Разумным в такой ситуации бу­дет выбор оборудования с учетом последующего развития компании в течение двух-трех лет — по опыту, за этот период потребности в информационных ресурсах возрастут мини­мум в два раза, а значит, придется выбирать оборудование из наиболее производительных сегодня систем, чтобы обе­спечить приемлемый уровень сервиса в будущем.nnПлюс такого решения, безусловно, в том, что, решив проблему в текущий момент, вы забываете о ней минимум на год-два.nnНо минусов этого решения гораздо больше. Во-первых, вы тратите значительный объем финансов не на основное направление бизнеса, а на обслуживание ИТ-систем.nnВо-вторых, компания переплатит сегодня за «светлое будущее» и получит избыточную систему сегодня с точки зрения производительности, но при этом недостаточную через полтора-два года (хоть и планировали на три). По­сле того как вы продержитесь на этом решении до конца гарантийного срока (обычно три года), вам потребуется продление поддержки, что равно внушительным затратам, анализируя которые, можно легко прийти к выводу, что по­купка нового оборудования в трехлетней перспективе вы­глядит интереснее. Таким образом, можем повторить путь покупки избыточного оборудования.nnПриведу немного цифр из жизни: компания «К» решила не проводить обновление ИТ-инфраструктуры и вместо это­го заключила контракт с сервисной компанией «С», которая поддерживает работоспособность серверов, но при этом любая поломка исправляется за счет компании «К» «рука­ми» компании «С».nnСервисная компания тут выступает в роли внешнего ин­женера и администратора, следит за сохранением баз дан­ных, резервных копий серверов и в случае выхода из строя оборудования предлагает на подмену свое (но уже за до­полнительную плату) с восстановлением резервных копий, физически заменяет вышедшее из строя оборудование на новое, закупленное компанией «К».nnСроки восстановления работоспособности сервиса в рассматриваемом случае, как правило, не более суток. Собственный штат в таком варианте обычно сокращается на 1-2 человек.nnА теперь посмотрим на цифры: поддержка сто­ит 50 000 руб. в месяц (не так уж и много на первый взгляд), день простоя для компании обходится в 1,2 млн руб. Име­ющееся оборудование выходит из строя 2-3 раза в год, таким образом, компания теряет 2,4-3,6 млн руб. только на простое сервисов из-за устаревания ИТ-инфраструк­туры, 600 000 руб. в год компания «К» платит сервисной компании за инженерную поддержку, это не учитывая скры­тые затраты (например, срыв сделки с ключевым клиентом в день «простоя»).nnЭтой суммы вполне достаточно, чтоб оплатить качествен­ный IaaS: в рассматриваемом примере среднерыночная цена за виртуальную инфраструктуру для работы всех сер­висов была бы на 22-27% меньше с учетом резервного ко­пирования.nnПри этом в расчетах не учтены стоимость предоставле­ния оборудования компанией «С» на время замены вышед­шего из строя оборудования, стоимость нового оборудова­ния для замены, стоимость рисков, связанных с длительной остановкой бизнеса, и все равно наблюдаем очевидное преимущество от использования современных сервисных решений.nnПодведя промежуточный итог, выделим основные причи­ны, побуждающие к переходу в облако:n

• >   эффективное финансовое планирование и преобразо­вание ИТ-затрат из капитальных в операционные,
• >   возможность расширения текущих ИТ-ресурсов,
• >   сокращение непрофильного штата персонала,
• >   бизнес-ориентация ИТ-подразделения.

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

Как выбрать надежное облако

Взвесив все «за» и «против», руководство компании при­нимает решение о переходе в облако и сразу сталкивается с новыми вопросами.nnПоявилось 1001 определение облака. Это может быть файловое хранилище, яркими представителями которого являются DropBox, Яндекс.Диск, облако®!^!.!^, Google Drive, OneDrive и др., облаком могут назвать услугу по раз­мещению сайта (хостинг) или услугу по предоставлению виртуального сервера (VPS — virtual private server), в послед­нее время мы стали слышать об облачных приложениях (иначе их часто называют веб-сервисы) — самым популяр­ным типом облачного сервиса является почта, также вы ча­сто можете слышать о популярных пакетах облачных про­дуктов — Office 365 и Google Apps.nnНе хотелось бы сильнее запутывать, делая 1002-е опре­деление, но все же можно выделить одну общую черту всех определений: облако — это услуга, создаваемая в удален­ном от точки ее потребления месте. Чтобы пояснить глу­бину такого обобщающего определения, облаком будет и домашний NAS (сетевое хранилище), предоставляющий услуги хранения файлов своим домочадцам, и инфраструк­тура Facebook, объединяющая около 200 тысяч(!) серверов и предоставляющая сервис социальной сети. И, конечно, облако неразрывно связано с виртуализацией.nnИтак, выбран путь от закупок оборудования к потре­блению услуг. При выборе поставщика облачных услуг появляется ряд вопросов. Наверняка ключевым факто­ром будет надежность решения. Показателем надежности многие считают значение SLA, прописанное в договоре. Но это не так. SLA — это заявленный уровень доступности сервиса, опустившись ниже которого, сервис-провайдер будет нести финансовую ответственность (которая также отражена в договоре). Тут важно понимать, что поставщик ИТ-услуг не является страховой компанией и не примет на себя риски, связанные с ухудшением качества оказания услуг. В лучшем случае, размер ответственности будет со­поставим со стоимостью потребляемых услуг. Поэтому важ­но убедиться, чем именно обусловлено качество сервиса.nnЭто прежде всего сам дата-центр, в котором размещена облачная инфраструктура. Вы можете не быть экспертами в области построения дата-центров. Чтоб лично оценить его качество, достаточно посмотреть на размер дата-цен­тра, историю за несколько лет и наличие сертификатов. Наличие сертификатов является безусловным плюсом, но опыт работы будет более показателен.nnСледующим кирпичиком, определяющим надежность ре­шения, будет оборудование. Тут есть два варианта.nnПервый — это использование унифицированного обору­дования с минимальной стоимостью (например, использова­ние недорогих серверов компании Supermicro или Huawei). В этом варианте выполнение SLA будет определяться в большей степени программным решением и в меньшей -объемом оборудования.nnТакое решение применимо, если сервисы хорошо мас­штабируются горизонтально, когда выход одного физиче­ского сервера из строя не приведет к остановке сервиса. Но на сегодня большинство сервисов являются вертикаль­но масштабируемыми и в рассматриваемой ситуации оста­новятся. Можно применять различные технологи, так, на­пример, у популярной СУБД MS SQL есть такие решения повышения доступности сервиса, как Mirroring и AlwaysOn. На самом деле у большинства производителей бизнес-кри­тичных программных продуктов есть свои проприетарные решения повышения доступности. Как правило, использо­вание подобных функций требует одновременного запуска нескольких экземпляров ПО на разных серверах, что при­водит к дополнительным затратам. Для критичных сервисов такое решение оправдано, но для сервисов, допускающих временную остановку, оно будет избыточно.nnВторой вариант: использование надежных промышлен­ных решений. Такое оборудование является высоконадеж­ным и редко выходит из строя. Производители такого обо­рудования широко известны — это компании Hewlett-Packard Enterprise (HPE), Dell, IBM, NetApp, EMC, Juniper, Cisco и др. Выбор данного варианта обусловлен прежде всего требо­ванием бизнеса к непрерывности сервисов и в то же вре­мя к оптимальному потреблению ИТ-ресурсов (финансовой обоснованности). В этом варианте любой сервис имеет высокую доступность и стоит ровно столько, сколько ему необходимо для работы, а в случае выхода из строя физи­ческого сервера автоматически запускается на исправном (но это уже технологии виртуализации, о которых поговорим далее). Применяя данный подход, сервис-провайдер мини­мизирует затраты клиентов на единицу ИТ-ресурса и в то же время гарантирует фактический высокий SLA.nnАналогичный подход должен быть применен и к сетевой инфраструктуре — высокопроизводительные промышлен­ные решения, построенные по принципу отсутствия единой точки отказа. В этом решении выход из строя единицы сете­вого оборудования не приведет к остановке сервиса. Если требуется подключение к сети Интернет, то такое подключе­ние также резервируется.nnСледующим критерием надежности является уровень виртуализации. Он обеспечивается различными про­граммными решениями. На рынке широко представле­ны как коммерческие, так и свободно распространяемые решения с открытым кодом. Наиболее популярные Open Source-продукты — это OpenStack, CloudStack, Proxmox VE, OpenNebula и другие OpenX-проекты.nnПреимущества очевидны: прежде всего они бесплат­ны; обладают неплохим функционалом; разрабатываются международным сообществом разработчиков. Зачастую одни и те же разработчики участвуют в нескольких проек­тах, в том числе и в коммерческих, в чем можно убедиться, посмотрев на сайте http://stackalytics.com список участвующих в разработке наиболее популярного Open Source-проекта — OpenStack (см. рис.1).nnnnМинусы такого решения также очевидны. Для внедрения и обслуживания этого решения компания должна содержать не только штат специалистов по администрированию сис­темы, но и штат программистов (или привлекать сервисную компанию), но тогда продукт перестает быть бесплатным.nnДля бизнеса основным минусом открытых платформ бу­дут их низкая стабильность и отсутствие функционала, име­ющегося в коммерческих продуктах. Дело в том, что все от­крытые платформы динамично развиваются, и сообщество просто не успевает протестировать все нововведения, да и далеко не все новые функции документированы. Без­условно, есть и стабильные «доработанные» сборки про­дуктов, но опять же здесь либо свой штат разработчиков, либо, что разумнее, платная поддержка от производителя такой сборки.nnПродукты OpenX обладают большим потенциалом, но на сегодня их трудно назвать готовыми решениями. Выби­рая надежное облако, правильно было бы выбрать надежно­го поставщика решений и в области виртуализации, поэто­му стоит рассматривать только лидеров рынка, их не много.nnНесмотря на то что на рынке представлены такие ре­шения по виртуализации, как HPE Helion, Oracle VM, Citrix XenServer, лидируют только два: VMware vSphere и Microsoft Hyper-V. Безусловно, оба решения высоконадежны.nnМожно убедиться, что миграция — это не так сложно, глав­ное — взвешенно подойти к вопросу выбора сервис-провай­дера. При выборе сервис-провайдера стоит оценить ЦОД, инфраструктуру, используемое решение виртуализации и, конечно, историю. Плюсами так же будут дополнительные услуги, такие как возможность защиты от DDоS-атак, воз­можность размещения в территориально удаленных ЦОДах, индивидуальное обслуживание и другие важные для вас до­полнения, как, например, физическое размещение инфор­мационных ресурсов на территории РФ для выполнения за­конодательства.nnНадеюсь, многие, увидев свою ситуацию в этой статье, с твердой уверенностью откроют «окна миграции» и устре­мятся в облака!nnИсточник: Системный администратор №6 2016