Це через те що ІТ відділи не довіряють платформ віртуалізації? Чи вважають вони платформи віртуалізації мало стабільними для підтримки роботи критично важливих додатків?
За останні 10 років VMware довела що віртуалізація це вже реальність, і, фактично, віртуалізовані застосування часто більш стабільні, коли працюють на інфраструктурі під керуванням VMware.
Тоді якщо довіру або стабільність не є проблемою в чому ж причина того що ІТ відділи ще не віртуалізувати залишилися додатки?
Scale out
Scale out або горизонтальне масштабування - додавання нових ресурсів в інфраструктуру, наприклад, серверів в кластер.
Так як ціни продовжують падати, а продуктивність рости то дешеві, commodity (широкого вжитку) сервера є ідеальним рішенням для горизонтального масштабування, і можуть бути зібрані в великі кластера для об'єднання обчислювальних ресурсів.
Протягом останніх семи років архітектори інфраструктур на VMware молилися на горизонтальне масштабування. Хтось може аргументувати за використання саме цього підходу, але він теж має свої нюанси, і все залежить від вимог бізнесу. Плюс горизонтального масштабування в тому, що commodity сервера дешеві, і в разі виходу сервера з ладу це впливає на невелику кількість ВМ. Мінус в більших витратах на ліцензії на vSphere, великі вимоги до площі ЦОД, і зазвичай такі commodity сервера не володіють великими обчислювальними ресурсами.
Scale up
Вертикальне масштабування - додавання обчислювальних ресурсів в якийсь вже використовується сервер. Зазвичай це процесори або оперативна пам'ять.
Зазвичай такі сервера досить потужні - з підтримкою 4 процесорів і 512Гб пам'яті. Крім того зустрічаються системи з 8 процесорами і 1ТБ пам'яті, а декому пощастило побачити навіть 16-ти процесорні сервера з 4ТБ пам'яті. І немає, це не мейнфрейми або щось типу того, це сервера на основі класичної х86 архітектури.
Перехід до другої хвилі віртуалізації, яка забезпечує гнучкість надається даною технологією для бізнес критичних додатків, надає сьогодні величезний тиск на використовувані сьогодні інфраструктури VMware через наступних проблем:
З виходом vSphere 5 кількість ресурсів, доступних однієї ВМ виросло в 4 рази.
А з виходом vSphere 5.1 монструозні ВМ можуть бути ще монструозність.
Для того щоб vSphere 5.1 могла запустити ВМ-монстра планувальником необхідно мати і спланувати запуск потоків на 64 фізичних процесорах. Не так багато серверів, які можуть підтримувати стільки ядер, а серверів з підтримкою 16 сокетов і 160 ядер і того менше.
Всього існує два типи вертикального масштабування серверів: glueless і glued. На російську мову ці слова перекладаються так: без інтегруючих технологій і з інтегруючими технологіями, відповідно.
Glueless архітектура
Дана архітектура була розроблена в Intel, і представлена в Intel Xeon E7.
Для зв'язку між пристроями введення-виведення, мережевими інтерфейсами і процесорам використовується спеціально розроблена шина QPI.
У серверах з 4-ма процесорів все вони з'єднуються між собою безпосередньо через цю шину. Glueless процесор використовує один з каналів для підключення процесора до інтерфейсів вводу-виводу, а інші три для підключення до сусідніх процесорам.
У 8-ми процессорном сервері кожен процесор безпосередньо підключається до трьох сусідніх, і через інший процесор до інших чотирьох.
- Немає необхідності в спеціальній розробці або спеціалізації у виробника серверів
- Будь-який виробник серверів може випускати 8-ми процесорні сервера
- Знижується вартість як 4-ох так і 8-ми процесорного сервера
- Загальна вартість володіння зростає при горизонтальному масштабуванні
- Архітектура обмежена 8-ми процесорними серверами
- Важко підтримувати цілісність кеша при збільшенні сокетов
- Нелінійний зростання продуктивності
- Співвідношення ціни до продуктивності падає
- Неоптимальна ефективність при використанні великих ВМ
- Аж до 65% пропускної здатності шини йде на широкомовні повідомлення балакучого протоколу QPI
Основні програми, продуктивність яких страждає від недоліків протоколу QPI це Java додатки, великі БД, чутливі до затримок програми.
Результатом вертикального масштабування має бути відсутність пляшкового горлечка, інакше дана архітектура стає безглуздою. Таким чином, лінійність збільшення продуктивності повинна відповідати лінійності додавання ресурсів.
Glued архітектура
Для вирішення описаних вище проблем розробники апаратного забезпечення розробили glued архітектуру. Дана архітектура використовує зовнішній контролер нод для організації взаємозв'язку острівців QPI - кластерів процесорів.
Intel QPI пропонує спеціальне масштабується, - eXternal Node-Controllers (або XNC), практична реалізація якого розробляється сторонніми OEM компаніями. Зовнішній контролер нод, який використовується починаючи з Intel Xeon E7-4800, з вбудованим контролером пам'яті, включає в себе також систему Cache Coherent Non-Uniform Memory Access (ccNUMA) завдання якої відстежувати актуальність даних в кожному рядку пам'яті процесорного кешу були актуальні дані.
Затримки між процесором і пам'яттю в ccNUMA залежать від місця розташування цих двох компонентів у відношенні один до одного, в результаті XNC контролери стають критично важливим компонентом сервера, і дуже невелика кількість виробників серверів можуть розробити сервера з можливістю вертикального масштабування.