Будь-який бізнес орієнтується на оптимізацію витрат, в тому числі на ІТ. Одним із способів оптимізації є перехід в хмару. Але при перенесенні сервісів у віртуальне середовище треба врахувати ряд особливостей
Найчастіше бізнес висуває підвищені вимоги до доступності ряду сервісів в ході міграції. Міграція можлива навіть без зупинки сервісу, до того ж такий спосіб часто є рекомендованим і найнадійнішим. До подібної ситуації можна віднести зазначені раніше особливості міграції найбільш популярних служб ОС Microsoft, таких як Active Directory Domain Services (ADDS або частіше просто AD) і Microsoft SQL (MSSQL). Головною метою особливого підходу до міграції в цих випадках є мінімізація простою сервісу.
Наша компанія надає послуги з міграції сервісів в хмару встановлених на Windows / Linux, подробиці [Email protected]
Для міграції Active Directory без зупинки служби застосовує наступний алгоритм:
- > Організовується мережева зв'язність між фізичним обладнанням і хмарою. Зазвичай це site-to-site VPN, що дозволяє організувати логічну мережу поверх іншої мережі (наприклад, інтернет). Трафік в такій мережі може бути додатково захищений шифруванням з використанням протоколів IPsec.
- > У віртуальному середовищі розгортається необхідну кількість нових віртуальних машин з шаблону, в яких настроюються контролери домену AD з додаванням їх в наявний ліс.
- > База даних Active Directory реплицируется по мережі через VPN з уже працюючих контролерів на стороні фізичного обладнання в хмарні.
- > Після завершення реплікації даних перепризначувалися майстра ролей операцій на хмарні контролери і прибираються ролі контролерів домену з фізичних серверів.
- > Після перевірки справної роботи сервісів відключаються облікові записи старих контролерів і саме фізичне обладнання.
Міграція - це не так складно, головне - виважено підійти до питання вибору сервіс-провайдера
Для міграції MSSQL з мінімізацією часу зупинки служби застосовується більш складний алгоритм, так як MSSQL, як правило, використовується в багаторівневому сервісі в якості бекенд. На відміну від AD, де клієнти в переважній кількості випадків знаходять доступні контролери AD автоматично, використовуючи DNS, в додатках, що використовують бази даних (в клієнтах MSSQL), доводиться вказувати нове розташування бази даних вручну. Тому повністю виключити простої не можна, але його можна мінімізувати. Якщо розбиратися глибше, звичайно, існують механізми безупинної міграції MSSQL, такі як Mirroring і AlwaysOn, але застосування цих механізмів не завжди виправдано. AlwaysOn доступний тільки в дорогих Enterprise-редакціях, а Mirroring повинен підтримуватися клієнтами MSSQL. До того ж у разі застосування механізмів Mirroring потрібно провести додаткову настройку всіх клієнтів MSSQL.
Такі ситуації рідкісні, тому розглянемо найбільш частий варіант міграції MSSQL в хмару:
- > Організовується мережева зв'язність між фізичним обладнанням і хмарою.
- > Необхідно переконатися, що модель відновлення бази MSSQL повна, в такому випадку можна зробити і перенести повну резервну копію, а потім синхронізувати дві бази даних за допомогою перенесення резервних копій транзакційних логів.
- > У віртуальному середовищі розгортається нова віртуальна машина з шаблону, в якій встановлюється і налаштовується новий MSSQL-сервер.
- > Створюється повна резервна копія бази даних MSSQL-сервера, що працює на фізичному обладнанні, і далі вона відновлюється в хмарному, при цьому спосіб перенесення файлу резервної копії залежить від її розмірів і пропускної здатності мережі, налаштованої між майданчиками (фізичне переміщення на носії або копіювання по мережі).
- > Після перенесення і відновлення бази даних у хмарі робиться резервна копія транзакційних логів, і вони аналогічно відновлюються в хмарі, цю операцію можна повторити, поступово мінімізуючи розсинхронізація баз даних.
- > На заключному етапі перенесення, під час «вікна міграції», зупиняється працює на фізичному обладнанні MSSQL-сервер, створюється і відновлюється остання (вже мінімальна за розміром) резервна копія транзакційних логів в хмарі, запускається MSSQL-сервер в хмарі, і клієнти переходять на нове місце розташування бази.
- > Після перевірки справної роботи сервісів, фізичне обладнання можна відключати.
Було розглянуто перенесення найбільш популярних служб, але для кожної служби і сервісу існує безліч способів міграції, що залежать від зовнішніх умов. Незважаючи на те що міграція - досить цікавий технічний процес, можуть виникати різні труднощі, уникнути яких може допомогти сервіс-провайдер. Сервіс-провайдер здатний вирішити набагато більшу кількість запитань, пов'язаних з міграцією, надати професійну допомогу і проводити подальші консультації, пов'язані з роботою в віртуальному середовищі.
Чим більше сервісних послуг споживає компанія, тим вона ефективніше і успішніше
Переваги використання хмари
У чому ж в цілому причини та доцільність таких інфраструктурних змін в компанії, як міграція в хмари?
Одна з причин - це проблема, пов'язана з недостатнім обсягом обчислювальних ресурсів наявної інфраструктури і їх неоптимальний використання для вирішення постійно зростаючих бізнес-завдань компанії. За вихідну точку візьмемо найбільш популярну на сьогодні ситуацію, коли ІТ-інфраструктура розміщена в комерційному дата-центрі і частина інформаційних сервісів працює на межі можливостей обслуговуючих їх фізичних серверів. Розглянемо нюанси масштабування кожного типу сервісу окремо.
Одна з частих ситуацій, коли не вистачає продуктивності обчислювальної підсистеми для одного сервісу. Класичним вирішенням цієї проблеми є заміна фізичного сервера на більш продуктивний. Така заміна досить накладна з фінансової точки зору: крім вартості самого сервера, потрібно чимало узгоджених дій - починаючи від інсталяції та налаштування сервера до міграції інформаційних сервісів зі старого обладнання на нове.
Рішення, звичайно, не новаторське, але перевірене часом і має місце бути. Розумним в такій ситуації буде вибір обладнання з урахуванням подальшого розвитку компанії протягом двох-трьох років - по досвіду, за цей період потреби в інформаційних ресурсах зростуть мінімум в два рази, а значить, доведеться вибирати обладнання з найбільш продуктивних сьогодні систем, щоб забезпечити прийнятний рівень сервісу в майбутньому.
Плюс такого рішення, безумовно, в тому, що, вирішивши проблему в поточний момент, ви забуваєте про неї мінімум на рік-два.
Але мінусів цього рішення набагато більше. По-перше, ви витрачаєте значний обсяг фінансів не на основний напрямок бізнесу, а на обслуговування ІТ-систем.
По-друге, компанія переплатить сьогодні за «світле майбутнє» і отримає надлишкову систему сьогодні з точки зору продуктивності, але при цьому недостатню через півтора-два роки (хоч і планували на три). Після того як ви протримається на цьому рішенні до кінця гарантійного терміну (зазвичай три роки), вам буде потрібно продовження підтримки, що дорівнює значним витратам, аналізуючи які, можна легко прийти до висновку, що покупка нового устаткування в трирічній перспективі виглядає цікавіше. Таким чином, можемо повторити шлях купівлі надлишкової обладнання.
Наведу трохи цифр з життя: компанія «К» вирішила не проводити оновлення ІТ-інфраструктури і замість цього уклала контракт з сервісною компанією «С», яка підтримує працездатність серверів, але при цьому будь-яка поломка виправляється за рахунок компанії «К» «руками» компанії «С».
Сервісна компанія тут виступає в ролі зовнішнього інженера і адміністратора, стежить за збереженням баз даних, резервних копій серверів і в разі виходу з ладу обладнання пропонує на підміну своє (але вже за додаткову плату) з відновленням резервних копій, фізично замінює вийшло з ладу обладнання на нове, закуплене компанією «К».
Терміни відновлення працездатності сервісу в даному випадку, як правило, не більше доби. Власний штат в такому варіанті зазвичай скорочується на 1-2 чоловік.
А тепер подивимося на цифри: підтримка коштує 50 000 руб. в місяць (не так вже й багато на перший погляд), день простою для компанії обходиться в 1,2 млн руб. Наявне обладнання виходить з ладу 2-3 рази на рік, таким чином, компанія втрачає 2,4-3,6 млн руб. тільки на просте сервісів через старіння ІТ-інфраструктури, 600 000 руб. в рік компанія «К» платить сервісної компанії за інженерну підтримку, це не враховуючи приховані витрати (наприклад, зрив угоди з ключовим клієнтом в день «простою»).
Цієї суми цілком достатньо, щоб оплатити якісний IaaS: в розглянутому прикладі середня ринкова ціна за віртуальну інфраструктуру для роботи всіх сервісів була б на 22-27% менше з урахуванням резервного копіювання.
При цьому в розрахунках не враховано вартість надання обладнання компанією «С» на час заміни вийшов з ладу обладнання, вартість нового обладнання для заміни, вартість ризиків, пов'язаних з тривалою зупинкою бізнесу, і все одно спостерігаємо очевидну перевагу від використання сучасних сервісних рішень.
Підвівши проміжний підсумок, виділимо основні причини, які спонукають до переходу в хмару:
- > Ефективне фінансове планування і перетворення ІТ-витрат з капітальних в операційні,
- > Можливість розширення поточних ІТ-ресурсів,
- > Скорочення непрофільного штату персоналу,
- > Бізнес-орієнтація ІТ-підрозділу.
Компанія не повинна створювати всередині себе сервісну ІТ-компанію, так як ефективність такого підходу можлива тільки на великому обсязі, хоча життя часто демонструє протилежне - чим більше корпорація, тим більше вона споживає послуг від сервісних компаній. Можна навіть стверджувати, що чим більше сервісних послуг споживає компанія, тим вона ефективніше і успішніше.
Як вибрати надійне хмара
Зваживши всі «за» і «проти», керівництво компанії приймає рішення про перехід в хмару і одразу стикається з новими питаннями.
З'явилося 1001 визначення хмари. Це може бути файлове сховище, яскравими представниками якого є DropBox, Яндекс.Діск, облако®! ^!.! ^, Google Drive, OneDrive і ін., Хмарою можуть назвати послугу з розміщення сайту (хостинг) або послугу з надання віртуального сервера ( VPS - virtual private server), останнім часом ми стали чути про хмарних додатках (інакше їх часто називають веб-сервіси) - найпопулярнішим типом хмарного сервісу є пошта, також ви часто можете чути про популярних пакетах хмарних продуктів - Office 365 і Google Apps .
Не хотілося б сильніше заплутувати, роблячи 1002-е визначення, але все ж можна виділити одну спільну рису всіх визначень: хмара - це послуга, створювана в віддаленому від точки її споживання місці. Щоб пояснити глибину такого узагальнюючого визначення, хмарою буде і домашній NAS (мережеве сховище), що надає послуги зберігання файлів своїм домочадцям, і інфраструктура Facebook, яка об'єднує близько 200 тисяч (!) Серверів і надає сервіс соціальної мережі. І, звичайно, хмара нерозривно пов'язане з виртуализацией.
Отже, обраний шлях від закупівель обладнання до споживання послуг. При виборі постачальника хмарних послуг з'являється ряд питань. Напевно ключовим фактором буде надійність рішення. Показником надійності багато хто вважає значення SLA, прописане в договорі. Але це не так. SLA - це заявлений рівень доступності сервісу, опустившись нижче якого, сервіс-провайдер буде нести фінансову відповідальність (яка також відображена в договорі). Тут важливо розуміти, що постачальник ІТ-послуг не є страховою компанією і не прийме на себе ризики, пов'язані з погіршенням якості надання послуг. У кращому випадку, розмір відповідальності буде порівнянний з вартістю спожитих послуг. Тому важливо переконатися, що саме обумовлено якість сервісу.
Це перш за все сам дата-центр, в якому розміщена хмарна інфраструктура. Ви можете не бути експертами в області побудови дата-центрів. Щоб особисто оцінити його якість, досить подивитися на розмір дата-центру, історію за кілька років і наявність сертифікатів. Наявність сертифікатів є безумовним плюсом, але досвід роботи буде більш показовий.
Наступним цеглинкою, що визначає надійність рішення, буде обладнання. Тут є два варіанти.
Перший - це використання уніфікованого обладнання з мінімальною вартістю (наприклад, використання недорогих серверів компанії Supermicro або Huawei). У цьому варіанті виконання SLA буде визначатися в більшій мірі програмним рішенням і в меншій -об'емом обладнання.
Таке рішення може бути застосовано, якщо сервіси добре масштабуються горизонтально, коли вихід одного фізичного сервера з ладу не призведе до зупинки сервісу. Але на сьогодні більшість сервісів є вертикально масштабованими і в ситуації, що розглядається зупиняться. Можна застосовувати різні технологи, так, наприклад, у популярній СУБД MS SQL є такі рішення підвищення доступності сервісу, як Mirroring і AlwaysOn. Насправді у більшості виробників бізнес-критичних програмних продуктів є свої пропрієтарні рішення підвищення доступності. Як правило, використання подібних функцій вимагає одночасного запуску декількох екземплярів ПЗ на різних серверах, що призводить до додаткових витрат. Для критичних сервісів таке рішення виправдане, але для сервісів, що допускають тимчасову зупинку, воно буде надмірно.
Другий варіант: використання надійних промислових рішень. Таке обладнання є високонадійним і рідко виходить з ладу. Виробники такого обладнання широко відомі - це компанії Hewlett-Packard Enterprise (HPE), Dell, IBM, NetApp, EMC, Juniper, Cisco і ін. Вибір даного варіанту обумовлений перш за все вимогою бізнесу до безперервності сервісів і в той же час до оптимального споживання ІТ -ресурсів (фінансової обгрунтованості). У цьому варіанті будь-який сервіс має високу доступність і коштує рівно стільки, скільки йому необхідно для роботи, а в разі виходу з ладу фізичного сервера автоматично запускається на справному (але це вже технології віртуалізації, про які поговоримо далі). Застосовуючи даний підхід, сервіс-провайдер мінімізує витрати клієнтів на одиницю ІТ-ресурсу і в той же час гарантує фактичний високий SLA.
Аналогічний підхід повинен бути застосований і до мережевої інфраструктури - високопродуктивні промислові рішення, побудовані за принципом відсутності єдиної точки відмови. У цьому рішенні вихід з ладу одиниці мережевого обладнання не призведе до зупинки сервісу. Якщо потрібне підключення до мережі Інтернет, то таке підключення також резервується.
Наступним критерієм надійності є рівень віртуалізації. Він забезпечується різними програмними рішеннями. На ринку широко представлені як комерційні, так і вільно поширювані рішення з відкритим кодом. Найбільш популярні Open Source-продукти - це OpenStack, CloudStack, Proxmox VE, OpenNebula і інші OpenX-проекти.
Переваги очевидні: перш за все вони безкоштовні; мають непоганий функціоналом; розробляються міжнародною спільнотою розробників. Часто одні і ті ж розробники беруть участь в декількох проектах, в тому числі і в комерційних, у чому можна переконатися, подивившись на сайті http://stackalytics.com список що беруть участь в розробці найбільш популярного Open Source-проекту - OpenStack (див. Рис. 1).
Мінуси такого рішення також очевидні. Для впровадження і обслуговування цього рішення компанія повинна містити не тільки штат фахівців з адміністрування системи, а й штат програмістів (або залучати сервісну компанію), але тоді продукт перестає бути безкоштовним.
Для бізнесу основним мінусом відкритих платформ будуть їх низька стабільність і відсутність функціоналу, наявного в комерційних продуктах. Справа в тому, що всі відкриті платформи динамічно розвиваються, і співтовариство просто не встигає протестувати всі нововведення, та й далеко не всі нові функції задокументовані. Безумовно, є і стабільні «допрацьовані» збірки продуктів, але знову ж таки тут або свій штат розробників, або, що розумніше, платна підтримка від виробника такої збірки.
Продукти OpenX мають великий потенціал, але на сьогодні їх важко назвати готовими рішеннями. Вибираючи надійне хмара, правильно було б вибрати надійного постачальника рішень і в області віртуалізації, тому варто розглядати тільки лідерів ринку, їх не багато.
Незважаючи на те що на ринку представлені такі рішення по віртуалізації, як HPE Helion, Oracle VM, Citrix XenServer, лідирують тільки два: VMware vSphere і Microsoft Hyper-V. Безумовно, обидва рішення високо надійні.
Можна переконатіся, что міграція - це не так складно, головне - віважено підійті до питання Вибори сервіс-провайдера. При виборі сервіс-провайдера варто оцінити ЦОД, інфраструктуру, що використовується рішення віртуалізації і, звичайно, історію. Плюсами так само будуть додаткові послуги, такі як можливість захисту від DDоS-атак, можливість розміщення в територіально віддалених ЦОДах, індивідуальне обслуговування та інші важливі для вас доповнення, як, наприклад, фізичне розміщення інформаційних ресурсів на території РФ для виконання законодавства.
Сподіваюся, багато хто, побачивши свою ситуацію в цій статті, з твердою впевненістю відкриють «вікна міграції» і кинуться в хмари!
Джерело: Системний адміністратор №6 2016
