IT Expert: Яким може стати ЦОД майбутнього?

1. Станіслав Синіцин

IT Expert світ технологій Наука і техніка Станіслав Синіцин

| 25.07.2015

Центр обробки даних, ЦОД,? поняття, яке кожен уявляє собі дещо по-своєму. В цілому це складний апаратно-програмний комплекс, що складається з десятків інженерних підсистем, щодо безлюдна середовище проживання ІТ-обладнання та корпоративних додатків, якийсь простір, в якому можна навіть з іншого континенту орендувати для своїх потреб необхідного розміру сегмент з потрібними характеристиками.

Незважаючи на свою дорожнечу, ЦОД швидко перестає задовольняти потреби своїх творців і їх клієнтів. В результаті власники змушені постійно добудовувати нові майданчики і серйозно модернізувати існуючі.

За задумом інвестора життєвий цикл ЦОД повинен складати близько 15 років. Протягом цього часу комплекс повинен розвиватися еволюційно: мається на увазі планова заміна компонентів, нарощування серверного парку і розширення пропускної здатності зовнішніх каналів зв'язку. У реальному житті багато елементів, аж до «кровоносної системи»? мережевої інфраструктури ЦОД? на рівні архітектури застарівають занадто швидко, а їх не так легко замінити, як виробив ресурс сервер, полку дискового масиву або згорілий трансивер.

Проблема криється в потребах замовників - їх бізнес трансформується все зростаючими темпами, при цьому залежність бізнес-процесів від ІТ досягла критичних відміток. Те ж стосується і держсектора, де йдуть масштабні ІТ-проекти по консолідації обчислень, аналізу великих масивів даних, створення електронних архівів і запуску електронних держпослуг.

Власники ЦОД опинилися в непростій ситуації? незважаючи на необхідність модернізації, 70% їх ІТ-бюджетів витрачається на експлуатацію та підтримку, що залишає інновацій всього лише 30% коштів (і це оптимістична оцінка).

вимоги ринку

Бізнесу і держзамовникам потрібно все більше обсягів для зберігання даних (збільшення в 10 разів за 5 років!), Все більш висока швидкість обробки, компактне розміщення і мінімальне споживання енергії? при обмеженому фінансуванні і людському ресурсі. Саме це, в кінцевому рахунку, відбивається на виборі архітектурних підходів, технологій і устаткування.

Розвитку індустрії ІТ йде в бік консолідації обчислень і все більшої автономності функціонування інфраструктури. Звичною стала всюдисуща віртуалізація аж до робочих місць (VDI), широке використання публічних, приватних і гібридних хмарних середовищ. Сервісно-орієнтовані технології IaaS, SaaS популярні настільки, що в ряді країн до 2017 року в їх відношенні прогнозується CAGR (щорічний показник зростання) в 30% -40%.

Почасти це пояснюється тим, що створення ЦОД? справа витратна. Аналітики оцінюють поріг входу мінімум в $ 500.000. Тому поряд з найбільш поширеним раніше варіантом? ��творенням власного корпоративного ЦОД? на ринку з'явилися і бурхливо розвиваються послуги комерційних ЦОД, призначених для оренди інфраструктури зовнішніми замовниками.

Може здатися, що для державних установ, пов'язаних законами щодо захисту конфіденційності даних, це не зовсім прийнятно. Це не так: держсектор для реалізації власних проектів створює ЦОД, орієнтовані на оренду інфраструктури і додатків, і принципи їх використання ідентичні комерційним. Однак тут вимоги до гнучкості, масштабованості і відмовостійкості зростають ще на порядок!

Ключові концепції сучасного ЦОД

Аналізуючи ці зустрічні тенденції? функціонування підприємств з одного боку і розвиток і проникнення в бізнес інформаційних технологій з іншого,? можна оцінити, якими властивостями повинна володіти сучасна архітектура ЦОД, щоб протягом довгого періоду виправдовувати очікування і інвестиції.

1. Модульність. Будівництво величезних майданчиків з однакової архітектурою виявляється неефективним. Поділ ЦОД на логічні і фізичні зони дозволяє експериментувати з новими технологіями і модернізувати частини великий інфраструктури в міру необхідності, не втручаючись у функціонування всієї площадки в цілому.

2. «Multitenant»? підтримка і ізоляція простору орендарів. Кожен клієнт орендує сегмент ЦОД, ізольований від «життєвого простору» сусідів. Втілення може бути різним: оренда стійок і фізичних серверів, хмарної середовища, віртуальних машин, простору в сховищах, контекстів міжмережевих екранів, балансувальник трафіку, і т.д. і т.п., аж до оренди мегагерц, терабайт і гігабіт з погодинною оплатою.

3. Конвергентної. Необхідність будувати для кожної підсистеми (і, в перспективі, модернізувати!) Незалежну кабельну систему, комплекс активного обладнання, мережа управління істотно здорожує рішення і ускладнює умови експлуатації. І навпаки? скорочення кількості компонентів призводить до підвищення загальної надійності. Приклад конвергентної мережі передачі даних: Data Center Bridging (DCB) і передача Fibre Channel трафіку за технологією FCoE.

4. Міцні та безперервність сервісу. Цей найважливіший принцип роботи корпоративних додатків критично важливий для комерційних ЦОД, власники яких заробляють на забезпеченні відмовостійкості і безперервності сервісу.

Як це все реалізувати? Доводиться визнати: класична (ієрархічна Core-Edge) архітектура побудови ІТ-середовища для масштабної консолідації додатків і даних є занадто реактивної і витратною. Модернізація вузлів, розгортання розподілених додатків, реалізація відгуків на вимоги безпеки і оптимізації потоків трафіку? всі ці процеси є занадто складними, відбуваються неприйнятно повільно, вимагають залучення занадто великої кількості фахівців, призводять до простоїв цілих сегментів інфраструктури.

Напрошується висновок: щоб забезпечити довгостроковий еволюційний період експлуатації ЦОД, необхідно використовувати революційні підходи до його проектування.

Do not panic! (© Douglas Adams. The Hitchhiker's Guide to the Galaxy)

Принципи створення ЦОД змінюються. Відзначимо важливі вектори їх розвитку:

· Повна віртуалізація інфраструктури і єдине управління мережею, серверами, сховищами, сервісними платформами, віртуальними ресурсами, також відоме як «оркестрування»;

· Віртуалізація «назовні»: наприклад, технології створення єдиних віртуальних комутаторів для централізованого управління всією мережею передачі даних на тисячі портів як однієї великої платформою;

· Програмно-яке визначається домінування: сьогоднішній вінець розвитку ідеї поділу шини даних і шини управління, один із прикладів? концепція Software Defined Networking (SDN);

· Перехід від звичних апаратних платформ (маршрутизатори, міжмережеві екрани, балансувальник) до віртуальних пристроїв, що дає неперевершені можливості в забезпеченні надійності, масштабування і управлінні продуктивністю.

Ідеологічний сенс полягає в абстрагуванні від понять «заліза» і «софта» і перехід до моделі «сервісів».

Проблема двох підходів

Для бізнес-процесів підприємств важливі програми. Потреба в їх консолідації і привела до появи ЦОД. Термінами взаємодії користувачів і додатків, а також додатків між собою оперують керівники ІТ-служб підприємств. Більш традиційний? «Інженерний»? погляд полягає в тому, що основа архітектури ЦОД? це мережа у всьому своєму різноманітті. Тому, будуючи ЦОД, інженери будують мережі.

Проілюструвати різницю двох підходів можна на прикладі стандартного багаторівневого web-додатки (Малюнок 1).

Малюнок 1. Два підходи до опису логіки роботи програми

Проблема знаходиться на стику? ці два підходи погано пристосовані для взаємодії один з одним.

На малюнку 2 представлена ​​мережева інфраструктура для розгортання корпоративного програми в територіально рознесених ЦОД, досить зрозуміла мережевого фахівця, щоб підготувати проектну документацію для її реалізації.

Малюнок 2. Мережева архітектура для роботи корпоративного програми (джерело: cisco.com)

Наведена архітектура відображає багато перераховані раніше принципи: тут знаходять застосування віртуалізовані комутатори, конвергентні мережі, гарантується безперервність функціонування додатків за рахунок забезпечення катастрофостійкості. Рішення працездатний і відображає Best Practice одного з лідерів галузі. Але його розгортання зажадає внесення змін в конфігурацію десятків пристроїв і установки нових.

При цьому виникають наступні питання:

· Чи достатньо відображена тут логіка роботи бізнес-додатки в межах його життєвого циклу?

· Наскільки масштабні зміни доведеться внести в сервісний шар ЦОД при зміні логіки роботи програми? чи вистачить потужності міжмережевих екранів, чи вдасться оптимізувати трафік між ЦОД на наявних платформах?

· Які зміни потрібно вносити в архітектуру при трансформації принципів взаємодії співробітників, наприклад, в напрямку розширення використання відеоконференцій і систем обміну миттєвими повідомленнями замість електронної пошти?

· І? головне? скільки на це потрібно часу, включаючи час простою майданчиків, і, в кінцевому рахунку, які будуть витрати?

А що якщо будувати ЦОД на базі другого ( «інженерного») підходу, але експлуатувати в термінах першого? взаємодії додатків?

Технологія Cisco ACI

Саме таке рішення під ім'ям Application Centric Infrastructure (ACI) в кінці 2013 р запропонувала компанія Cisco. ACI забезпечує підтримку наскрізний віртуалізації, управління та автоматизації, реалізуючи логіку взаємодії додатків за допомогою настроюються політик. Апаратна складова ACI? комутатори Nexus 9000, об'єднані в топологію Spine-Leaf. Матриця комутаторів формує «ACI-фабрику». Інші елементи ACI ЦОД підключаються до комутаторів "Leaf" і називаються End Point (EP). Для зменшення кількості об'єктів в середовищі ACI End Point об'єднують в групи End Point Group (EPG). В принципі, знати про фізичної топології потрібно тільки те, що комутатори з'єднані між собою надлишковими каналами і трафік між End Point рівномірно балансується по фабриці. Все управління компонентами ACI і самої фабрикою виконується за допомогою програмних контролерів APIC (Application Policy Infrastructure Controller), також підключених до "Leaf" -коммутаторам. За допомогою APIC група адміністрування ЦОД формує ланцюжка додатків і сервісних компонент в термінах End Point і політик їх взаємодії. Подібні взаємини в термінах ACI називаються «контрактами»: одна сторона контракт надає ( "provider"), інша споживає ( "consumer").

Малюнок 3. Архітектура Cisco ACI

Контролери APIC в моделі ACI є розподіленим сховищем-репозиторієм для всіх об'єктів і політик середовища ACI. При цьому сама фабрика, що називається, stateless, без контролера з базою даних вона порожня і готова реалізовувати будь-який логічний дизайн.

Малюнок 4. Формування ланцюжка End Point для опису багаторівневого додатки

Згадуваний вище принцип "multitenant" є невід'ємною частиною архітектури ACI. У середовищі ACI існують «орендарі», в рамках виділеного йому сегмента орендар створює ізольовані «контексти», в які занурює ланцюжка додатків, що складаються з EPG, пов'язаних контрактами (Малюнок 4).

Крім використання графічного інтерфейсу (GUI), управління ACI можна здійснювати програмно, за допомогою Python або Perl, а також будь-якого іншого мови з підтримкою REST API. Крім цього підтримується завантаження готових об'єктів безпосередньо на контролер APIC у вигляді XML.

Ініціативу Cisco ACI підтримують BMC, Computer Associates, Citrix, EMC, Emulex, F5, IBM, Microsoft, NetApp, VMware і багато інших компаній. Їх продукти і технології є органічною частиною моделі ACI і підтримують управління своїм функціоналом через контролери APIC.

висновок

Майбутнє, безсумнівно, за гнучкими, масштабованими архітектурою ЦОД, в яких сервісний шар тісно інтегрований з мережевим і при цьому інфраструктура розрахована на програмне управління, як в ACI. Інтерес до цієї архітектурі значний, при цьому, щоб не ризикувати, для тестування можливості комерційного використання ACI в ЦОД, як правило, створюється окрема ACI-зона, де розміщуються спочатку тестові, а потім і реальні програми. Ефект - кількість кроків, необхідних для розгортання бізнес-додатки, при переході на архітектуру ACI скорочується зі 149 до 7.

Концепція Cisco ACI вже використовується в ЦОД більш ніж 500 найбільших світових ІТ-компаній. Для ознайомлення з технологією Cisco надає можливість скористатися своїм майданчиком інтерактивних демонстрацій dCloud, побудованої на основі ACI.

***

Стаття підготовлена ​​в рамках багаторічного співробітництва компанії Cisco і TEGRUS, російського системного інтегратора повного циклу, що входить в ТОП-50 найбільших ІТ-компаній Росії. TERGUS, крім широкого спектра рішень Cisco, пропонує замовникам повну проектну підтримку, в тому числі інженерну, на всіх етапах - від проектування і будівництва інженерної інфраструктури до пуско-налагодження, аудиту та післяпродажного обслуговування готового рішення.

про авторів

Станіслав Синіцин

Керівник напрямку мережевих рішень і телефонії компанії ТЕГРУС.