Джерела і складові частини продуктивності вводу-виводу серверів. Вид зовні

Сервер недоречного наповнення зводить нанівець можливості прикладного ПО. І навпаки, врахування особливостей трафіку даних при виборі компонентів піднімає результативність і дозволяє уникнути зайвих витрат. Інфраструктура обчислень і зберігання набирається зі стандартних апаратних «цеглинок» - про це було в першій частині "Джерела і складові частини продуктивності вводу-виводу серверів. Вид зсередини". Ось кілька прикладів доведення типових платформ під специфічні потреби додатків.

Сервери баз даних

У гонитві за продуктивністю зазвичай починають з перенесення файлів баз даних (database, DB) на SSD. Профіль навантажень баз даних - звернення випадкового доступу c великою часткою операцій записи і відносно невисокими в середньому, але значними піковими навантаженнями в IOPS. Розміщення DB на SSD дозволяє згладжувати ці піки і записувати дані з мінімальними затримками, недосяжними механічним дискам.

При запуску MS SQL сервера створюється tempDB - системна база тимчасових, часто перезаписуваних об'єктів (таблиць, змінних, процедур). Запити до них просаджують загальну продуктивність систем з великою кількістю розрахункових і порівняльних операцій: у виробничому плануванні, логістичних завданнях облікових систем, обміні даними з іншими базами. Активною записи в тимчасові таблиці зазвичай супроводжує активне читання з основної бази даних, і навпаки, тому намагаються винести tempDB на окремі від DB фізичні носії (а то і в оперативну пам'ять, із зазначенням резервного шляху на постійний носій).

У кожної бази SQL сервера є журнал транзакцій log, в якому фіксуються всі зміни даних. Це важлива складова бази даних, що дозволяє при збої повернути її в узгоджене стан. Транзакція не закінчена, поки не зроблений запис в журнал. Протоколювання, щільний потік коротких лінійних операцій, критично до затримок записи. Заради продуктивності, а також з міркувань збереження даних, файли журналу і основної бази зберігають на різних фізичних носіях. При цьому tempDB і log можуть поєднуватися на одному томі SSD.

Який би не був розмір основної бази даних, допоміжні області: файли індексів, тимчасових таблиць, журналів - порівняно невеликі. Під них має сенс відводити найшвидкісніші носії - NVMe SSD. Поява Intel Optane SSD на пам'яті 3D XPoint додає можливостей управління продуктивністю. Хоча 3D XPoint SSD дорожче NAND SSD, для розміщення на них tempDB і SQL log вже дуже приваблива висока продуктивність Optane на коротких чергах запитів.

Приклад дискової підсистеми cервера SQL:

Сервери - вузли Storage Spaces Direct

Storage Spaces Direct (S2D) - технологія розподіленого зберігання даних в складі Windows Server 2016 Datacenter Edition. Сервер з локальними дисками об'єднуються в відмовостійкий масштабований кластер, захищений від виходу з ладу як окремих дисків, так і серверів цілком. Програмно-яке визначається рішення без єдиної точки відмови дозволяє обійтися без традиційних масивів SAN або NAS. Висока продуктивність операцій введення-виведення досягається локалізацією дискових звернень, використанням кешування, багаторівневого зберігання, оптимального поєднання накопичувачів NVMe / SAS / SATA, мережеве протоколу RDMA.

S2D працює з трьома типами дисків: NVMe, SSD, HDD, в різних комбінаціях:

Для S2D під навантаженими VM (в тому числі, з SQL OLTP) важливо забезпечити передбачувано низькі (менше мілісекунди) затримки між випадковими операціями читання / запису будь-яких даних і багато IOPS. Для цього використовуються флеш-накопичувачі, зазвичай зв'язка NVMe SSD for Cache + SATA SSD for Capacity.

NVMe приймають на себе інтенсивні операції записи журналу і даних, переносячи їх на SATA SSD тільки при необхідності або за розкладом - для зменшення зносу шару Capacity. Запис «на швидкості NVMe» - відмінна риса S2D. Читання обслуговується безпосередньо з SATA SSD, досить швидких для цього.

Погіршує дискову навантаження «блендер віртуалізації», який перемелює сукупні запити вводу-виводу VM (включаючи лінійні) в потік звернень випадкового доступу з малим розміром блоку. У гранулятів велика частка операцій записи (до 50-70%) - що накладається на без того високі вимоги SQL до швидкого обслуговування файлів баз даних, журналів і тимчасових таблиць. При таких умовах роль кешуючого шару NVMe неоціненна.

Приклад дискової підсистеми вузла S2D:

Сервери - вузли VSAN

Virtual SAN (VSAN) - конвергентная архітектура VMware, платформа зберігання даних корпоративного рівня. Розподілена інфраструктуру обчислень і зберігання будується з блоків - серверів. VSAN збирає з локальних дисків серверів віртуальне «зовнішнє» сховище, доступне всім обчислювальним вузлам кластера віртуалізації. Дворівневе зберігання включає кешуючий шар (Cache) і постійний шар (Capacity). Підтримується All-flash (AF) і гібридна (SSD / HDD) архітектура. На кожному серверному вузлі може бути від 1 до 5 дискових груп, як мінімум один кешуючий накопичувач і до семи дисків постійного зберігання в кожній.

У VSAN AF обидва рівня зберігання реалізовані на SSD. Cache - це буфер, через яких проганяється вся запис, тому накопичувачі під нього ставлять Write-intensive, High endurance. Шар Capacity набирають з менш дорогих, Read-intensive SSD. Співвідношення обсягів Cache / Capacity не повинно бути нижче 1:10.

Хоча VSAN і дає певну свободу у виборі «заліза», має сенс залишатися в рамках списку гарантовано сумісного з VMware VSAN обладнання. Поява SSD на пам'яті 3D XPoint, а потім включення Intel Optane P4800X в список підтримуваного обладнання VSAN AF, викликало великий інтерес в співтоваристві VMware. З шаром кешування на Optane очікуваний приріст продуктивності в задачах з інтенсивної записом становить 2.5 рази проти перш еталонної серії Intel P3700 NVMe SSD.

Можлива структура дискової групи вузла VSAN AF (1 NVMe + 3 SSD):

Таких дискових груп в 1U можна організувати дві.

Cервери VOD

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

Медійної індустрії і її супутникам CDN потрібні надійні, передбачувані, масштабовані рішення зберігання і роздачі контенту. Послуга перегляду відео (Video on Demand, VOD) не затребувана, якщо безперервної доставці даних в реальному часі буде заважати низька швидкість з'єднання, непередбачуваність якості через буферизації, залежність від навантаженості джерела.

Цифрове відео програється з високим бітрейтом. Збірки відео хорошої якості з'їдають десятки і сотні терабайт дискового простору HDD на стороні постачальника. На практиці, сервери VoD обслуговують кілька потоків читання одночасно. Навіть якщо мова йде про множинних запитах до одного і того ж файлу з популярним відео, одночасне звернення до різних частин цього файлу рівносильно читання випадкового доступу (Random Read). В результаті, багатопоточний читання відео з високим бітрейтом вимагає від дискової підсистеми серверів VOD великої віддачі по ширині потоку і здатності до швидкого переключення між областями контенту.

Механічні диски різко втрачають пропускну здатність зі збільшенням числа конкурентних потоків читання, тоді як SSD зберігають її на високому рівні при сотнях потоків. Поява флеш-пам'яті в роздавальник відео закономірно, але висока швидкість читання випадкового доступу - не єдина критична метрика. Взаємодія між об'ємними бібліотеками контенту на HDD і фронтальними пристроями видачі на SSD має враховувати особливість попиту, профіль якого постійно змінюється, навіть протягом доби. Наприклад, вранці дивляться новини і кулінарні шоу, вдень - серіали, ввечері - розважальні програми, спортивні трансляції та ситкоми. Відповідно, «гаряче» ядро ​​відеоданих постійно перебудовується, а кешуючий флеш-носії повинні швидко підкачувати файли з основного шару зберігання на HDD.

Найкращими кандидатами на роль Edge storage в завданні VOD будуть ємні NVMe SSD, c їх низькими затримками звернення, високими показниками читання випадкового доступу і лінійної запису. Наприклад, такі:

Сервери-мутанти

Наведені приклади показують, як можна адаптувати типові серверні платформи 1U під специфічні завдання. Всі описані додатки досить вимогливі до ресурсів процесорів і пам'яті. Проте, особа серверів визначає облаштування введення-виведення: дискової і мережевий підсистем. Необхідний мережевий адаптер ставиться як карта розширення в стандартний слот PCIe або як мезонін OCP. Простір варіацій по дискам великий - благо платформи підтримують поєднання U.2 / SAS / SATA накопичувачів, в загальному кошику, з гарячою заміною.

Здавалося б, яке діло кінцевому користувачеві до того, стандартна його платформа чи ні - аби виконувала свою роль і містилася в бюджет. В тому-то й справа, що типові платформи обходяться дешевше специфічних і простіше в обслуговуванні - все вузли стандартні. А ще їх можна навчити новим трюкам. Сервери живуть довше, ніж тримається мода. Хто знає, чи не знадобиться через два-три роки дати друге життя старим речам.