Вже чимало слів було сказано з цієї теми як у моєму блозі, так і за його межами. Мені здається настав слушний момент для того, щоб перейти від приватного до спільного і спробувати поглянути на цю тему окремо від якоїсь успішної її реалізації.
Почнемо?
Для початку має сенс визначитися з тим, про що ми взагалі говоритимемо. У цьому контексті перед веб-додатком ставляться три основні цілі:
- масштабованість- здатність своєчасно реагувати на безперервне зростання навантаження та непередбачені напливи користувачів;
- доступність- надання доступу до програми навіть у разі надзвичайних обставин;
- продуктивність- навіть найменша затримка завантаження сторінки може залишити негативне враження у користувача.
Основною темою розмови буде, як не важко здогадатися, масштабованість, але й інші цілі не думаю, що залишаться осторонь. Відразу хочеться сказати пару слів про доступність, щоб не повертатися до цього пізніше, маючи на увазі як "звісно ж": будь-який сайт так чи інакше прагне до того, щоб функціонувати максимально стабільно, тобто бути доступним абсолютно всім своїм потенційним відвідувачам в кожен момент часу, але часом трапляються будь-які непередбачені ситуації, які можуть спричинити тимчасову недоступність. Для мінімізації потенційної шкоди доступності програми необхідно уникати наявності компонентів у системі, потенційний збій в яких призвів би до недоступності будь-якої функціональності або даних (або хоча б сайту в цілому). Таким чином, кожен сервер або будь-який інший компонент системи повинен мати хоча б одного дублера (не важливо в якому режимі вони будуть працювати: паралельно або один "підстраховує" інший, перебуваючи при цьому в пасивному режимі), а дані повинні бути репліковані як мінімум у двох примірниках (причому бажано не лише на рівні RAID, але в різних фізичних машинах). Зберігання кількох резервних копій даних десь окремо від основної системи (наприклад на спеціальних сервісах чи окремому кластері) також допоможе уникнути багатьох проблем, якщо щось піде негаразд. Не варто забувати і про фінансову сторону питання: підстрахування на випадок збоїв потребує додаткових суттєвих вкладень в обладнання, які мають сенс намагатися мінімізувати.
Масштабованість прийнято розділяти на два напрями:
Вертикальна масштабованістьЗбільшення продуктивності кожного компонента системи з метою підвищення загальної продуктивності. Горизонтальна масштабованістьРозбиття системи на більш дрібні структурні компоненти та рознесення їх по окремих фізичних машинах (або їх групах) та/або збільшення кількості серверів, що паралельно виконують одну і ту ж функцію.Так чи інакше, при розробці стратегії зростання системи доводиться шукати компроміс між ціною, часом розробки, підсумковою продуктивністю, стабільністю та ще масою інших критеріїв. З фінансової точки зору вертикальна масштабованість є далеко не найпривабливішим рішенням, адже ціни на сервери з великою кількістю процесорів завжди зростають практично експонентно щодо кількості процесорів. Саме тому найбільш цікавий горизонтальний підхід, оскільки саме він використовується в більшості випадків. Але й вертикальна масштабованість часом має право на існування, особливо в ситуаціях, коли основну роль відіграє час і швидкість вирішення задачі, а не фінансове питання: адже купити ВЕЛИКИЙ сервер суттєво швидше, ніж практично заново розробляти програми, адаптуючи його до роботи на великій кількості паралельно працюючих серверів.
Закінчивши із загальними словами, давайте перейдемо до огляду потенційних проблем і варіантів їх вирішення при горизонтальному масштабуванні. Прохання особливо не критикувати - на абсолютну правильність і достовірність не претендую, просто "думки вголос", та й навіть згадати всі моменти цієї теми у мене виразно не вийде.
Сервери програм
У процесі масштабування самих додатків рідко виникають проблеми, якщо при розробці завжди мати на увазі, що кожен екземпляр програми повинен бути безпосередньо ніяк не пов'язаний зі своїми "колегами" і повинен мати можливість обробити будь-який запит користувача незалежно від того, де оброблялися попередні запити даного користувача. і що він хоче від додатку загалом у поточний момень.
Далі, забезпечивши незалежність кожної окремої запущеної програми, можна обробляти дедалі більшу кількість запитів за одиницю часу просто збільшуючи кількість паралельно функціонуючих серверів додатків, що у системі. Все досить просто (щодо).
Балансування навантаження
Наступне завдання – рівномірно розподілити запити між доступними серверами додатків. Існує маса підходів до вирішення цього завдання та ще більше продуктів, що пропонують їх конкретну реалізацію.
УстаткуванняМережеве обладнання, що дозволяє розподіляти навантаження між декількома серверами, зазвичай коштує досить значні суми, але серед інших варіантів зазвичай саме цей підхід пропонує найвищу продуктивність і стабільність (в основному завдяки якості плюс таке обладнання іноді поставляється парами, що працюють за принципом). У цій індустрії досить багато серйозних брендів, що пропонують свої рішення – є з чого вибрати: Cisco, Foundry, NetScalarі багато інших. Програмне забезпеченняУ цій галузі ще більша різноманітність можливих варіантів. Отримати програмно продуктивність порівнянну з апаратними рішеннями не так просто, та й HeartBeat доведеться забезпечувати програмно, зате обладнання для функціонування такого рішення є звичайним сервером (можливо не один). Таких програмних продуктів досить багато, зазвичай вони є просто HTTP-серверами, що перенаправляють запити своїм колегам на інших серверах замість відправки безпосередньо на обробку інтерпретатору мови програмування. Наприклад можна згадати, скажімо, з mod_proxy . Крім цього, мають місце більш екзотичні варіанти, засновані на DNS, тобто в процесі визначення клієнтом IP-адреси сервера з необхідним йому інтернет-ресурсів адреса видається з урахуванням навантаження на доступні сервери, а також деяких географічних міркувань.Кожен варіант має свій асортимент позитивних і негативних сторін, саме тому однозначного вирішення цього завдання не існує - кожен варіант хороший у своїй конкретній ситуації. Не варто забувати, що ніхто не обмежує Вас у використанні лише одного з них, при необхідності може бути реалізована і практично довільна комбінація з них.
Ресурсомісткі обчислення
У багатьох додатках використовуються якісь складні механізми, це може бути конвертування відео, зображень, звуку або просто виконання будь-яких ресурсомістких обчислень. Такі завдання вимагає окремої уваги якщо ми говоримо про Мережі, тому що користувач інтернет-ресурсу навряд чи буде щасливий спостерігати за сторінкою, що завантажується кілька хвилин в очікуванні лише для того, щоб побачити повідомлення на кшталт: "Операція завершена успішно!".
Щоб уникнути подібних ситуацій, варто постаратися мінімізувати виконання ресурсомістких операцій синхронно з генерацією інтернет-сторінок. Якщо якась конкретна операція не впливає на нову сторінку, яку користувач надсилає, то можна просто організувати чергазавдань, які потрібно виконати. У такому випадку в момент, коли користувач здійснив всі дії, необхідні для початку операції, сервер додатків просто додає нове завдання в чергу і відразу починає генерувати наступну сторінку, не чекаючи результатів. Якщо завдання насправді дуже трудомістке, то така черга і обробники завдань можуть розташовуватися на окремому сервері або кластері.
Якщо результат виконання операції задіяний у наступній сторінці, що надсилається користувачеві, то при асинхронному її виконанні доведеться дещо схитрувати і якось відволікти користувача на час її виконання. Наприклад, якщо йдеться про конвертування відео в flv, то наприклад можна швидко згенерувати скріншот з першим кадром у процесі складання сторінки і підставити його на місце відео, а можливість перегляду динамічно додати на сторінку вже після завершення конвертування.
Ще один непоганий метод обробки таких ситуацій полягає просто в тому, щоб попросити користувача "зайти пізніше". Наприклад, якщо сервіс генерує скріншоти веб-сайтів з різних браузерів з метою продемонструвати правильність їхнього відображення власникам або тим, хто просто цікавиться, то генерація сторінки з ними може займати навіть не секунди, а хвилини. Найбільш зручною для користувача в такій ситуації буде пропозиція відвідати сторінку за вказаною адресою за кілька хвилин, а не чекати у моря погоди невизначений термін.
Сесії
Практично всі веб-застосунки якимось чином взаємодіють зі своїми відвідувачами і в переважній більшості випадків у них є необхідність відстежувати переміщення користувачів по сторінках сайту. Для вирішення цього завдання зазвичай використовується механізм сесій, який полягає у присвоєнні кожному відвідувачу унікального ідентифікаційного номера, який йому передається для зберігання в cookies або, у разі їх відсутності, для постійного "тягання" за собою через GET. Отримавши від користувача певний ID разом з черговим HTTP-запитом, сервер може подивитися в список вже виданих номерів і однозначно визначити, хто його відправив. З кожним ID може асоціюватися якийсь набір даних, який веб-додаток може використовувати на свій розсуд, ці дані зазвичай за замовчуванням зберігаються у файлі в часовій директорії на сервері.
Здавалося б все просто, але... але запити відвідувачів одного і того ж сайту можуть обробляти відразу кілька серверів, як тоді визначити чи не було видано отриманий ID на іншому сервері і де взагалі зберігаються його дані?
Найбільш поширеними рішеннями є централізація чи децентралізація сесійних даних. Дещо абсурдна фраза, але, сподіваюся, пара прикладів зможе прояснити ситуацію:
Централізоване зберігання сесійІдея проста: створити для всіх серверів загальну "скарбничку", куди вони зможуть складати видані ними сесії та дізнаватися про сесії відвідувачів інших серверів. У ролі такої "скарбнички" теоретично може виступати і просто примонтована по мережі файлова система, але з деяких причин більш перспективним виглядає використання будь-якої СУБД, так як це позбавляє маси проблем, пов'язаних із зберіганням сесійних даних у файлах. Але у варіанті із загальною базою даних не варто забувати, що навантаження на нього неухильно зростатиме зі зростанням кількості відвідувачів, а також варто заздалегідь передбачити варіанти виходу із проблематичних ситуацій, пов'язаних з потенційними збоями в роботі сервера з цією СУБД. Децентралізоване зберігання сесійНаочний приклад - зберігання сесій в , спочатку розрахована на розподілене зберігання даних в оперативній пам'яті система дозволить отримувати всім серверам швидкий доступ до будь-яких сесійних даних, але при цьому (на відміну від попереднього способу) будь-який єдиний центр зберігання буде відсутній. Це дозволить уникнути вузьких місць з погляду продуктивності та стабільності у періоди підвищених навантажень.В якості альтернативи сесіям іноді використовують схожі за призначенням механізми, побудовані на cookies, тобто всі необхідні додатку дані про користувача зберігаються на стороні клієнта (ймовірно в зашифрованому вигляді) і запитуються при необхідності. Але крім очевидних переваг, пов'язаних із відсутністю необхідності зберігати зайві дані на сервері, виникає низка проблем із безпекою. Дані, що зберігаються на стороні клієнта навіть у зашифрованому вигляді, являють собою потенційну загрозу для функціонування багатьох додатків, оскільки будь-який бажаючий може спробувати модифікувати їх у своїх інтересах або з метою нашкодити додатку. Такий підхід хороший тільки якщо є впевненість, що абсолютно будь-які маніпуляції з даними, що зберігаються у даних, безпечні. Але чи можна бути впевненим на 100%?
Статичний контент
Поки обсяги статичних даних невеликі - ніхто не заважає зберігати їх у локальній файловій системі та надавати доступ до них просто через окремий легковажний веб-сервер на кшталт (я маю на увазі в основному різні форми медіа-даних), але рано чи пізно ліміт сервера по дисковому простору або файлової системи за кількістю файлів в одній директорії буде досягнуто, і доведеться думати про перерозподіл контенту. Тимчасовим рішенням може стати розподіл даних за їх типом на різні сервери або, можливо, використання ієрархічної структури каталогів.
Якщо статичний контент грає одну з основних ролей у роботі програми, то варто задуматися про застосування розподіленої файлової системи для зберігання. Це, мабуть, один з небагатьох способів горизонтально масштабувати обсяг дискового простору шляхом додавання додаткових серверів без будь-яких кардинальних змін у роботі програми. На якій саме кластерній файловій системі зупинити свій вибір нічого зараз радити не хочу, я вже опублікував далеко не один огляд конкретних реалізацій – спробуйте прочитати їх усе і порівняти, якщо цього мало – вся решта мережі у вашому розпорядженні.
Можливо, такий варіант з якихось причин буде нереалізований, тоді доведеться "винаходити велосипед" для реалізації на рівні докладання принципів схожих із сегментуванням даних щодо СУБД, про які я ще згадаю далі. Цей варіант також цілком ефективний, але потребує модифікації логіки додатка, а отже, і виконання додаткової роботи розробниками.
Альтернативою цим підходам є використання так званих Content Delievery Network- зовнішніх сервісів, які забезпечують доступність Вашого контенту користувачам за певну матеріальну винагороду сервісу. Перевага очевидна - немає потреби організовувати власну інфраструктуру для вирішення цього завдання, зате з'являється інша додаткова стаття витрат. Список таких сервісів наводити не буду, якщо комусь знадобиться – знайти буде не важко.
Кешування
Кешування має сенс проводити всіх етапах обробки даних, але у різних типах додатків найефективнішими є лише деякі методи кешування.
СУБДМайже всі сучасні СУБД надають вбудовані механізми для кешування результатів певних запитів. Цей метод досить ефективний, якщо Ваша система регулярно робить одні й ті ж вибірки даних, але також має ряд недоліків, основними з яких є інвалідування кешу всієї таблиці при найменшій її зміні, а також локальне розташування кешу, що неефективно за наявності кількох серверів у системі зберігання даних. додатокНа рівні програм зазвичай проводиться кешування об'єктів будь-якої мови програмування. Цей метод дозволяє уникнути істотної частини запитів до СУБД, сильно знижуючи навантаження на неї. Як і самі додатки такий кеш має бути незалежним від конкретного запиту та сервера, на якому він виконується, тобто бути доступним усім серверам додатків одночасно, а ще краще – бути розподіленим по кількох машинах для більш ефективної утилізації оперативної пам'яті. Лідером у цьому аспекті кешування по праву можна назвати, про яке я свого часу вже встиг. HTTP-серверБагато веб-серверів мають модулі для кешування як статичного контенту, так і результатів роботи скриптів. Якщо сторінка рідко оновлюється, то використання цього методу дозволяє без будь-яких видимих для користувача змін уникати генерації сторінки у відповідь на більшу частину запитів. Reverse proxyПоставивши між користувачем та веб-сервером прозорий проксі-сервер, можна видавати користувачеві дані з кешу проксі (який може бути як в оперативній пам'яті, так і дисковим), не доводячи запити навіть до серверів HTTP. У більшості випадків цей підхід є актуальним лише для статичного контенту, в основному різних форм медіа-даних: зображень, відео тощо. Це дозволяє веб-серверам зосередитися лише на роботі із самими сторінками.Кешування за своєю суттю практично не вимагає додаткових витрат на обладнання, особливо якщо уважно спостерігати за використанням оперативної пам'яті іншими компонентами серверами та утилізувати всі доступні "надлишки" під форми кешу, що найбільш підходять конкретному додатку.
Інвалідація кешу в деяких випадках може стати нетривіальним завданням, але так чи інакше універсального вирішення всіх можливих проблем з нею пов'язаних написати неможливо (принаймні особисто мені), так що залишимо це питання до кращих часів. У загальному випадку вирішення цього завдання лягає на сам веб-додаток, який зазвичай реалізує певний механізм інвалідності засобами видалення об'єкта кешу через певний період часупісля його створення або останнього використання, або "вручну" у разі виникнення певних подійз боку користувача чи інших компонентів системи.
Бази даних
На закуску я залишив найцікавіше, адже цей невід'ємний компонент будь-якої веб-програми викликає більше проблем при зростанні навантажень, ніж решта разом узятих. Часом навіть може здатися, що варто взагалі відмовитися від горизонтального масштабування системи зберігання даних на користь вертикального - просто купити цей ВЕЛИКИЙ сервер за шести-або семизначну суму не-рублів і не забивати собі голову зайвими проблемами.
Але для багатьох проектів таке кардинальне рішення (і те, за великим рахунком, тимчасове) не підходить, а отже, перед ними залишилася лише одна дорога - горизонтальне масштабування. Про неї і поговоримо.
Шлях практично будь-якого веб-проекту з погляду баз даних починався з одного простого сервера, на якому працював весь проект цілком. Потім одного разу настає необхідність винести СУБД на окремий сервер, але і він з часом починає не впоратися з навантаженням. Детально зупинятися цих двох етапах сенсу особливого немає - усе відносно тривіально.
Наступним кроком зазвичай буває master-slaveз асинхронною реплікацією даних, як працює ця схема вже неодноразово згадувалося в блозі, але, мабуть, повторюся: при такому підході всі операції запису виконуються лише на одному сервері (master), а решта серверів (slave) отримують дані безпосередньо від "майстра", обробляючи у своїй лише запити читання даних. Як відомо, операції читання та запису будь-якого веб-проекту завжди зростають пропорційно до зростання навантаження, при цьому зберігається майже фіксованим співвідношення між обома типами запитів: на кожен запит на оновлення даних зазвичай припадає в середньому близько десятка запитів на читання. З часом навантаження зростає, а значить зростає і кількість операцій запису в одиницю часу, а сервер обробляє їх всього один, а потім він ще й забезпечує створення деякої кількості копій на інших серверах. Рано чи пізно витрати операцій реплікації даних будуть настільки високі, що цей процес займатиме дуже велику частину процесорного часу кожного сервера, а кожен slave зможе обробляти лише порівняно невелику кількість операцій читання, і, як наслідок, кожен додатковий slave-сервер почне збільшувати сумарну продуктивність лише незначно, теж займаючись здебільшого лише підтримкою своїх даних відповідно до "майстра".
Тимчасовим вирішенням цієї проблеми, можливо, може стати заміна master-сервера на продуктивніший, але так чи інакше не вийде нескінченно відкладати перехід на наступний "рівень" розвитку системи зберігання даних: "sharding", якому зовсім недавно присвятив . Так що дозволю собі зупинитися на ньому лише коротко: ідея полягає в тому, щоб розділити всі дані на частини за якоюсь ознакою та зберігати кожну частину на окремому сервері або кластері, таку частину даних у сукупності із системою зберігання даних, в якій вона знаходиться , і називають сегментом або shardТому. Такий підхід дозволяє уникнути витрат, пов'язаних з реплікуванням даних (або скоротити їх у багато разів), а отже суттєвозбільшити загальну продуктивність системи зберігання даних. Але, на жаль, перехід до цієї схеми організації даних вимагає безліч витрат іншого роду. Так як готового рішення для її реалізації не існує, доводиться модифікувати логіку програми або додавати додаткову "прошарку" між додатком та СУБД, причому все це найчастіше реалізується силами розробників проекту. Готові продукти здатні лише полегшити їхню роботу, надавши якийсь каркас для побудови основної архітектури системи зберігання даних та її взаємодії з іншими компонентами програми.
На цьому етапі ланцюжок зазвичай закінчується, оскільки сегментовані бази даних можуть горизонтально масштабуватися для того, щоб повною мірою задовольнити потреби навіть найнавантаженіших інтернет-ресурсів. Доречно було б сказати пару слів і про власне саму структуру даних у рамках баз даних та організації доступу до них, але будь-які рішення сильно залежать від конкретного додатку та реалізації, так що дозволю собі лише дати пару загальних рекомендацій:
ДенормалізаціяЗапити, що комбінують дані з декількох таблиць, зазвичай при інших рівних вимагають більшого процесорного часу для виконання, ніж запит, що стосується лише однієї таблиці. А продуктивність, як згадувалося на початку розповіді, надзвичайно важлива на просторах Мережі. Логічне розбиття данихЯкщо якась частина даних завжди використовується окремо від основної маси, іноді має сенс виділити її в окрему незалежну систему зберігання даних. Низькорівнева оптимізація запитівВедучи та аналізуючи логи запитів, можна визначити найповільніші з них. Заміна знайдених запитів більш ефективні з тією ж функціональністю може допомогти раціональніше використовувати обчислювальні потужності.У цьому розділі варто згадати ще один, більш специфічний тип інтернет-проектів. Такі проекти оперують даними, які мають чітко формалізовану структуру, у таких ситуаціях використання реляційних СУБД як сховища даних, м'яко кажучи, недоцільно. У цих випадках зазвичай використовують менш суворі бази даних, з більш примітивною функціональністю в плані обробки даних, зате вони здатні обробляти величезні обсяги інформації, не чіпляючись до його якості та відповідності формату. В якості основи для такого сховища даних може служити кластерна файлова система, а для аналізу даних у такому випадку використовується механізм під назвою , принцип його роботи я розповім лише коротко, так як в повному своєму масштабі він дещо виходить за рамки даної розповіді.
Отже, ми маємо на вході деякі довільні дані в не факт що правильно дотриманому форматі. У результаті потрібно отримати певне підсумкове значення чи інформацію. Згідно з цим механізмом практично будь-який аналіз даних можна провести в наступні два етапи:
MapОсновною метою даного етапу є уявлення довільних вхідних даних у вигляді проміжних пар ключ-значення, що мають певний зміст і формально оформлених. Результати піддаються сортуванню та групуванню за ключом, а після чого передаються на наступний етап. ReduceОтримані після mapЗначення використовуються для фінального обчислення необхідних підсумкових даних.Кожен етап кожного конкретного обчислення реалізується у вигляді незалежного міні-додатку. Такий підхід дозволяє практично необмежено розпаралелювати обчислення на величезній кількості машин, що дозволяє миттєво обробляти обсяги практично довільних даних. Для цього достатньо лише запустити ці програми на кожному доступному сервері одночасно, а потім зібрати докупи всі результати.
Прикладом готового каркасу для реалізації роботи з даними за таким принципом є Opensource проект Apache Foundation під назвою , Про який я вже неодноразово розповідав раніше, та й написав свого часу.
Замість ув'язнення
Якщо чесно, мені важко віриться, що я зміг написати настільки всеосяжний пост і сил на підбиття підсумків вже практично не залишилося. Хочеться лише сказати, що у розробці великих проектів важлива кожна деталь, а неврахована дрібниця може спричинити провал. Саме тому в цій справі вчитися варто не на своїх помилках, а на чужих.
Хоча може бути цей текст і виглядає як якесь узагальнення всіх постів із серії, але навряд чи він стане фінальною точкою, сподіваюся мені знайдеться що сказати з цієї теми і в майбутньому, можливо одного разу це буде засноване і на особистому досвіді, а не просто буде результатом переробки маси отриманої інформації. Хто знає?...
Масштабованість - така властивість обчислювальної системи, яка забезпечує передбачуване зростання системних характеристик, наприклад, числа користувачів, що підтримуються, швидкості реакції, загальної продуктивності тощо, при додаванні до неї обчислювальних ресурсів. У разі сервера СУБД можна розглядати два способи масштабування – вертикальний та горизонтальний (рис. 2).
При горизонтальному масштабуванні збільшується кількість серверів СУБД, які, можливо, взаємодіють один з одним у прозорому режимі, розділяючи таким чином загальне завантаження системи. Таке рішення, мабуть, буде дедалі популярнішим із зростанням підтримки слабозв'язаних архітектур та розподілених баз даних, проте зазвичай воно характеризується складним адмініструванням.
Вертикальне масштабування передбачає збільшення потужності окремого сервера СУБД і досягається заміною апаратного забезпечення (процесора, дисків) більш швидкодіючим або додаванням додаткових вузлів. Хорошим прикладом може бути збільшення кількості процесорів у симетричних багатопроцесорних (SMP) платформах. У цьому програмне забезпечення сервера має змінюватися (зокрема, не можна вимагати закупівлі додаткових модулів), оскільки це збільшило б складність адміністрування і погіршило передбачуваність поведінки системи. Незалежно від того, який спосіб масштабування використаний, виграш визначається тим, наскільки повно програми сервера використовують доступні обчислювальні ресурси. У подальших оцінках ми розглядатимемо вертикальне масштабування, яке зазнає, на думку аналітиків, найбільше зростання на сучасному комп'ютерному ринку.
Властивість масштабованості актуальна з двох основних причин. Насамперед, умови сучасного бізнесу змінюються настільки швидко, що унеможливлюють довгострокове планування, що вимагає всебічного та тривалого аналізу вже застарілих даних, навіть для тих організацій, які здатні це собі дозволити. Натомість приходить стратегія поступового, крок за кроком, нарощування потужності інформаційних систем. З іншого боку, зміни в технології призводять до появи нових рішень і зниження цін на апаратне забезпечення, що потенційно робить архітектуру інформаційних систем більш гнучкою. Одночасно розширюється міжоперабельність, відкритість програмних та апаратних продуктів різних виробників, хоча поки що їх зусилля, спрямовані на відповідність стандартам, узгоджені лише у вузьких секторах ринку. Без урахування цих факторів споживач не зможе скористатися перевагами нових технологій, не заморожуючи коштів, вкладених у недостатньо відкриті або безперспективні технології. В області зберігання та обробки даних це вимагає, щоб і СУБД, і сервер були масштабовані. Сьогодні ключовими параметрами масштабованості є:
- підтримка багатопроцесорної обробки;
- гнучкість архітектури.
Багатопроцесорні системи
Для вертикального масштабування дедалі частіше використовуються симетричні багатопроцесорні системи (SMP), оскільки у разі не потрібно зміни платформи, тобто. операційної системи, апаратного забезпечення, а також навичок адміністрування. З цією метою можливе застосування систем з масовим паралелізмом (MPP), але поки їх використання обмежується спеціальними завданнями, наприклад, розрахунковими. Оцінюючи сервера СУБД із паралельною архітектурою доцільно звернути увагу до дві основні характеристики розширюваності архітектури: адекватності і прозорості.
Властивість адекватності вимагає, щоб архітектура сервера підтримувала один або десять процесорів без переустановки або істотних змін у конфігурації, а також додаткових програмних модулів. Така архітектура буде однаково корисна і ефективна і в однопроцесорній системі, і, у міру зростання складності розв'язуваних задач, на кількох або навіть на множині (MPP) процесорів. У загальному випадку споживач не повинен додатково купувати та освоювати нові опції програмного забезпечення.
Забезпечення прозорості архітектури сервера, своєю чергою, дозволяє приховати зміни конфігурації апаратного забезпечення від додатків, тобто. гарантує перенесення прикладних програмних систем. Зокрема, в сильно пов'язаних багатопроцесорних архітектурах додаток може взаємодіяти з сервером через сегмент пам'яті, що розділяється, тоді як при використанні слабопов'язаних багатосерверних систем (кластерів) для цієї мети може бути застосований механізм повідомлень. Додаток має враховувати можливості реалізації апаратної архітектури - методи маніпулювання даними і програмний інтерфейс доступу до базі даних мають залишатися однаковими й однаково ефективними.
Якісна підтримка багатопроцесорної обробки вимагає від сервера баз даних здатності самостійно планувати виконання безлічі запитів, що обслуговуються, що забезпечило б найбільш повний поділ доступних обчислювальних ресурсів між завданнями сервера. Запити можуть оброблятися послідовно декількома завданнями чи поділятися на підзавдання, які, своєю чергою, може бути виконані паралельно (рис. 3). Останнє є більш оптимальним, оскільки правильна реалізація цього механізму забезпечує вигоди, незалежні від типів запитів та додатків. На ефективність обробки величезний вплив робить рівень гранулярності аналізованих завданням-планувальником операцій. При грубій гранулярності, наприклад, на рівні окремих SQL-запитів, поділ ресурсів обчислювальної системи (процесорів, пам'яті, дисків) не буде оптимальним - завдання буде простоювати, чекаючи на закінчення необхідних для завершення SQL-запиту операцій вводу/виводу, хоча б у черзі до на ній стояли інші запити, що вимагали значної обчислювальної роботи. При більш тонкій гранулярності поділ ресурсів відбувається навіть усередині одного SQL-запиту, що наочніше проявляється при паралельній обробці кількох запитів. Застосування планувальника забезпечує залучення великих ресурсів системи до вирішення власне завдань обслуговування бази даних та мінімізує простої.
Гнучкість архітектури
Незалежно від ступеня мобільності, підтримки стандартів, паралелізму та інших корисних якостей, продуктивність СУБД, що має відчутні вбудовані архітектурні обмеження, не може нарощуватись вільно. Наявність документованих або практичних обмежень на кількість і розміри об'єктів бази даних і буферів пам'яті, кількість одночасних підключень, на глибину рекурсії виклику процедур і підлеглих запитів (subqueries) або спрацювання тригерів бази даних є таким же обмеженням застосування СУБД як, наприклад, неможливість перенесення на кілька обчислювальних платформ. Параметри, що обмежують складність запитів до бази даних, особливо розміри динамічних буферів та стека для рекурсивних викликів, повинні налаштовуватись у динаміці та не вимагати зупинки системи для реконфігурації. Немає сенсу купувати новий потужний сервер, якщо очікування не можуть бути задоволені через внутрішні обмеження СУБД.
Зазвичай вузьким місцем є неможливість динамічного підстроювання параметрів програм сервера баз даних. Здатність на ходу визначати такі параметри, як обсяг споживаної пам'яті, кількість зайнятих процесорів, кількість паралельних потоків виконання завдань (чи справжні потоки (threads), процеси операційної системи або віртуальні процесори) і кількість фрагментів таблиць і індексів баз даних, а також їх розподіл по фізичних дисках БЕЗ зупинки та перезапуску системи є вимогою, що випливає із суті сучасних додатків. В ідеальному варіанті кожен із цих параметрів можна було б змінити динамічно в заданих для конкретного користувача межах.
Зі зростанням популярності web-програми його підтримка неминуче починає вимагати все більших і більших ресурсів. Спочатку з навантаженням можна (і, безсумнівно, потрібно) боротися шляхом оптимізації алгоритмів та/або архітектури самого додатка. Однак що робити, якщо все, що можна було оптимізувати, вже оптимізовано, а додаток все одно не справляється з навантаженням?
Оптимізація
Насамперед варто сісти та подумати, а чи все вам уже вдалося оптимізувати:- чи оптимальні запити до БД (аналіз EXPLAIN, використання індексів)?
- чи правильно зберігаються дані (SQL vs NoSQL)?
- чи використовується кешування?
- чи немає зайвих запитів до ФС чи БД?
- Чи оптимальні алгоритми обробки даних?
- Чи оптимальні налаштування оточення: Apache/Nginx, MySQL/PostgreSQL, PHP/Python?
Масштабування
І так, припустимо, що оптимізація вже проведена, але програма все одно не справляється з навантаженням. У такому разі вирішенням проблеми, очевидно, може послужити рознесення його по кількох хостах, з метою збільшення загальної продуктивності програми рахунок збільшення доступних ресурсів. Такий підхід має офіційну назву - "масштабування" (scale) програми. Точніше кажучи, під «масштабуемістю» (scalability) називається можливість системи збільшувати свою продуктивність зі збільшенням кількості ресурсів, що виділяються їй. Розрізняють два способи масштабування: вертикальне та горизонтальне. Вертикальне масштабування передбачає збільшення продуктивності програми при додаванні ресурсів (процесора, пам'яті, диска) у межах одного вузла (хоста). p align="justify"> Горизонтальне масштабування характерно для розподілених додатків і передбачає зростання продуктивності програми при додаванні ще одного вузла (хоста).Зрозуміло, що найпростішим способом буде просте оновлення заліза (процесора, пам'яті, диска) – тобто вертикальне масштабування. Крім того, цей підхід не вимагає жодних доопрацювань програми. Однак, вертикальне масштабування дуже швидко досягає своєї межі, після чого розробнику та адміністратору нічого не залишається, крім як перейти до горизонтального масштабування програми.
Архітектура програми
Більшість web-додатків апріорі є розподіленими, тому що в їх архітектурі можна виділити щонайменше три шари: web-сервер, бізнес-логіка (додаток), дані (БД, статика).Кожен з цих шарів може бути масштабований. Тому якщо у вашій системі додаток та БД живуть на одному хості – першим кроком, безперечно, має стати рознесення їх по різних хостах.
Вузьке місце
Приступаючи до масштабування системи, насамперед варто визначити, який із шарів є «вузьким місцем» - тобто працює повільніше за решту системи. Для початку можна скористатися банальними утилітами типу top (htop) для оцінки споживання процесора/пам'яті та df, iostat для оцінки споживання диска. Однак, бажано виділити окремий хост, з емуляцією бойового навантаження (з допомогою або JMeter), на якому можна буде профільувати роботу програми за допомогою таких утиліт як xdebug і так далі. Для виявлення вузьких запитів до БД можна скористатися утилітами типу pgFouine (зрозуміло, що робити краще на основі логів з бойового сервера).Зазвичай усе залежить від архітектури додатку, але найімовірнішими кандидатами на «вузьке місце» у випадку є БД і код. Якщо ваша програма працює з великим обсягом даних, то «вузьким місцем», відповідно, швидше за все буде зберігання статики.
Масштабування БД
Як уже говорилося вище, найчастіше вузьким місцем у сучасних додатках є БД. Проблеми з нею діляться, як правило, на два класи: продуктивність та необхідність зберігання великої кількості даних.Знизити навантаження на БД можна рознісши її на кілька хостів. При цьому гостро постає проблема синхронізації між ними, вирішити яку можна шляхом реалізації схеми master/slave із синхронною або асинхронною реплікацією. У разі PostgreSQL реалізувати синхронну реплікацію можна з допомогою Slony-I , асинхронну – PgPool-II чи WAL (9.0). Вирішити проблему розділення запитів читання та запису, а також балансування навантаження між наявними slave'ами, можна за допомогою налаштування спеціального шару доступу до БД (PgPool-II).
Проблему зберігання великого обсягу даних у разі використання реляційних СУБД можна вирішити за допомогою механізму партицирования (“partitioning” у PostgreSQL), або розгортаючи БД на розподілених ФС типу Hadoop DFS.
Однак, для зберігання великих обсягів даних найкращим рішенням буде "шардинг" (sharding) даних, який є вбудованою перевагою більшості NoSQL БД (наприклад, MongoDB).
Крім того, NoSQL БД загалом працюють швидше за своїх SQL-братів за рахунок відсутності overhead'а на розбір/оптимізацію запиту, перевірки цілісності структури даних тощо. Тема порівняння реляційних і NoSQL БД так само досить велика і заслуговує.
Окремо варто відзначити досвід Facebook, який використовують MySQL без JOIN-вибірок. Така стратегія дозволяє їм значно легше масштабувати БД, переносячи при цьому навантаження з БД на код, який, як буде описано нижче, простіше масштабується БД.
Масштабування коду
Складнощі з масштабуванням коду залежать від того, скільки ресурсів, що розділяються, необхідно хостам для роботи вашої програми. Чи будуть це тільки сесії, чи знадобиться спільний кеш та файли? У будь-якому випадку насамперед потрібно запустити копії програми на кількох хостах з однаковим оточенням.Далі необхідно налаштувати балансування навантаження/запитів між цими хостами. Зробити це можна на рівні TCP (haproxy), і на HTTP (nginx) чи DNS .
Наступним кроком потрібно зробити так, щоб файли статики, cache і сесії web-програми були доступні на кожному хості. Для сесій можна використовувати сервер, що працює по мережі (наприклад, memcached). Як сервер кеша цілком розумно використовувати той же memcached, але, природно, на іншому хості.
Файли статики можна змонтувати з загального файлового сховища по NFS /CIFS або використовувати розподілену ФС (HDFS , GlusterFS , Ceph).
Також можна зберігати файли в БД (наприклад, Mongo GridFS), вирішуючи цим проблеми доступності і масштабованості (з урахуванням того, що для NoSQL БД проблема масштабованості вирішена за рахунок шардингу).
Окремо варто відзначити проблему деплойменту на кілька хостів. Як зробити так, щоб користувач, натискаючи «Оновити», не бачив різні версії програми? Найпростішим рішенням, на мій погляд, буде виключення з конфіга балансувальника навантаження (web-сервера) не оновлених хостів, і їх послідовного включення в міру оновлення. Також можна прив'язати користувачів до конкретних хостів по cookie або IP. Якщо ж оновлення вимагає значних змін у БД, найпростіше взагалі тимчасово закрити проект.
Масштабування ФС
При необхідності зберігання великого обсягу статики можна виділити дві проблеми: нестача місця та швидкість доступу до даних. Як було написано вище, проблему з нестачею місця можна вирішити як мінімум трьома шляхами: розподілена ФС, зберігання даних у БД з підтримкою шардингу та організація шардингу «вручну» на рівні коду.При цьому варто розуміти, що роздача статики теж не найпростіше завдання, коли йдеться про високі навантаження. Тому цілком резонно мати безліч серверів призначених для роздачі статики. При цьому, якщо ми маємо загальне сховище даних (розподілена ФС або БД), при збереженні файлу ми можемо зберігати його ім'я без урахування хоста, а ім'я хоста підставляти випадково при формуванні сторінки (випадково балансую навантаження між web-серверами, що роздають статику) . У випадку, коли шардинг реалізується вручну (тобто, за вибір хоста, на який будуть залиті дані, відповідає логіка в коді), інформація про хост заливки повинна обчислюватися на основі самого файлу, або генеруватися на підставі третіх даних (інформація про користувача, кількості місця на дисках-сховищах) та зберігатися разом з ім'ям файлу в БД.
Моніторинг
Зрозуміло, що велика та складна система потребує постійного моніторингу. Рішення, на мій погляд, тут стандартне – zabbix, котрий стежить за навантаженням/роботою вузлів системи та monit для демонів для підстрахування.Висновок
Вище коротко розглянуто безліч варіантів вирішення проблем масштабування web-додатку. Кожен з них має свої переваги та недоліки. Не існує деякого рецепту, як зробити все добре і відразу – для кожного завдання знайдеться безліч рішень зі своїми плюсами та мінусами. Який із них вибрати – вирішувати вам.І т. п., якщо їм потрібна можливість працювати під великим навантаженням. Система називається масштабованоїякщо вона здатна збільшувати продуктивність пропорційно додатковим ресурсам. Масштабованість можна оцінити через відношення приросту продуктивності системи до приросту ресурсів, що використовуються. Чим ближче це ставлення до одиниці, тим краще. Також під масштабованістю розуміється можливість нарощування додаткових ресурсів без структурних змін центрального вузла системи.
У системі з поганою масштабованістю додавання ресурсів призводить лише до незначного підвищення продуктивності, а з деякого «порогового» моменту додавання ресурсів не дає корисного ефекту.
Вертикальне масштабування
Збільшення продуктивності кожного компонента системи з метою підвищення загальної продуктивності.
Горизонтальне масштабування
Розбиття системи на більш дрібні структурні компоненти та рознесення їх по окремих фізичних машинах (або їх групах) та/або збільшення кількості серверів, що паралельно виконують одну і ту ж функцію.
Примітки
Див. також
Посилання
Wikimedia Foundation. 2010 .
Дивитись що таке "Масштабованість" в інших словниках:
масштабованість- Розширюваність Характеристика програми, яка виконується на різних платформах і варіюється в розмірах (наприклад, PC під Windows і робочої станції Sun під Unix). Для апаратних засобів передбачуване зростання системних характеристик при…
масштабованість- 3.1.43 масштабованість (scalability): Здатність забезпечувати функціональні можливості вгору і вниз по впорядкованому ряду прикладних платформ, що відрізняються за швидкодією та ресурсами. Джерело … Словник-довідник термінів нормативно-технічної документації
Здатність програмного забезпечення коректно працювати на малих і великих системах з продуктивністю, яка збільшується пропорційно обчислювальної потужності системи. Англійською мовою: Scalability Див. також: Відкриті системи Програмне … Фінансовий словник
масштабованість системи (в SCADA)- масштабованість системи [Інтент] Масштабованість системи. Це означає, що розроблений проект можна випробувати на одному комп'ютері або маленькій мережі, а потім розширювати систему (відповідно до програми розвитку, бюджету тощо) без… … Довідник технічного перекладача
масштабованість (в інформаційних технологіях)- Здатність ІТ послуги, процесу, конфігураційної одиниці тощо, виконувати свою раніше узгоджену функцію, у разі зміни робочого навантаження чи охоплення. [Словник термінів ITIL версія 1.0, 29 липня 2011 р.] EN scalability The ability of an IT… … Довідник технічного перекладача
масштабованість (додатки)- масштабованість розширюваність Характеристика програми, яка виконується на різних платформах і варіюється в розмірах (наприклад, PC під Windows і робочої станції Sun під Unix). Для апаратних засобів передбачуване зростання системних систем. Довідник технічного перекладача
масштабованість (мережі та системи зв'язку)- Критерій економічно ефективної системи автоматизації підстанції, що враховує різні функціональні характеристики, різні інтелектуальні електронні пристрої, розмір підстанції та діапазони напруги підстанції. [ГОСТ Р 54325 2011… … Довідник технічного перекладача
масштабованість у широких межах- - [Л.Г.Суменко. Англо-російський словник з інформаційних технологій. М.: ДП ЦНДІС, 2003.] Тематики інформаційні технології загалом EN terabyte scalability … Довідник технічного перекладача
горизонтальна масштабованість- Нарощування потужності системи додаванням вузлів у кластер. Тематики інформаційні технології загалом EN horizontal scalability … Довідник технічного перекладача
SCALABILITY - масштабованість- один з основних принципів побудови відкритих систем, що гарантує збереження інвестицій в інформацію та ПЗ при переході на більш потужну апаратну платформу … Словник електронного бізнесу
Книги
- Microsoft SharePoint 2010. Повний посібник , А. Моргунова , Колін Спенс , Майкл Ноел , Я. Волкова , У книзі розглядаються нові можливості SharePoint - від нових компонентів соціальних мереж до вдосконаленого пошуку - які допомагають максимально задіяти як SharePoint… Категорія: Комп'ютерні технології Видавець: Вільямс,
- Ядро Oracle. Внутрішній пристрій для адміністраторів та розробників даних , Льюїс Джонатан , У даній книзі автор наводить тільки найнеобхіднішу інформацію про внутрішній пристрій СУБД Oracle, яку повинен знати кожен адміністратор баз даних, щоб успішно боротися з…
Можливість масштабування інформаційної системи – як горизонтальне, і вертикальне – одна із найважливіших чинників, куди варто звертати під час виборів засоби автоматизації діяльності будь-якої організації. Якщо обране рішення неможливо буде масштабувати, або кожна стадія зростання бізнесу призводитиме до складнощів із супроводом та розвитком такого програмного продукту, то не слід навіть починати його використовувати. Ми розробляли СЕД ЛЕТОГРАФ з урахуванням високих вимог до масштабування.
Необхідність у горизонтальному чи вертикальному масштабуванні виникає у зв'язку зі створенням корпоративних високонавантажених ІТ-систем, у яких працюють тисячі чи навіть десятки тисяч користувачів. Однак підтримувати одночасну роботу великої кількості користувачів можуть далеко не всі СЕД. Тільки якщо в СЕД на рівні архітектури закладено можливості нарощування кількості користувачів без втрати продуктивності – тільки в цьому випадку масштабування буде успішним. Створена нами система ЛЕТОГРАФ була розроблена таким чином, щоб ідеально масштабувати як горизонтально, так і вертикально. Це досягається як за рахунок архітектури самої системи і прикладного коду, який ми розробили, так і за рахунок функціоналу СУБД InterSystems Caché, на якій наша СЕД побудована.
СУБД Caché – це сучасна система управління базами даних та середовище для швидкої розробки програм. В основі цієї СУБД лежить технологія, яка забезпечує швидкодію та високу продуктивність, масштабованість та надійність. У цьому апаратні вимоги системи залишаються досить скромними.
СУБД Caché зберігає високу продуктивність навіть під час роботи з величезними масивами даних і великою кількістю серверів у розподілених системах. При цьому доступ до даних здійснюється через об'єкти, високопродуктивні SQL-запити та шляхом прямої обробки багатовимірних структур даних.
Вертикальне масштабування
Вертикальне масштабування передбачає нарощування потужності сервера та його можливостей, що з дискової підсистемою. ЛЕТОГРАФ підтримує сучасну процесорну архітектуру, що дозволяє обробляти великі обсяги даних у кілька потоків. При цьому дані в СЕД організовані таким чином, щоб їх можна було легко розносити по СХД на різні диски. Такий підхід дозволяє рівномірно розподілити навантаження на сховища даних та мінімізувати її при читанні даних безпосередньо з бази, а значить і падіння продуктивності системи вдасться уникнути навіть за одночасної роботи великої кількості користувачів.
Ще на етапі розробки платформи ми розуміли, що вертикальне масштабування – одна з ключових можливостей системи, потреба в якій з часом лише збільшуватиметься. Ми розробили систему таким чином, щоб роботи кожного користувача були виділені в окремі системні процеси, які між собою не перетинаються завдяки тому, що бази даних ефективно ділять доступ до інформації. При цьому кількість блокувань даних в СЕД ЛЕТОГРАФ мінімізована і немає вузького горла ні при читанні даних, ні при їх запису.
Архітектура СЕД ЛЕТОГРАФ дозволяє розподіляти дані на кілька фізичних чи віртуальних серверів. Завдяки такому розподілу кожен із користувачів працює в ізольованому процесі, а необхідні дані ефективно кешуються з використанням технологій СУБД Caché. Час блокування даних мінімізований: всі транзакції вибудовані таким чином, щоб переводити дані в ексклюзивний режим доступу лише на дуже короткий час. При цьому навіть такі високонавантажені з точки зору кількості звернень до диска дані, як журнали, індекси, дані об'єктів, потоки, логи дій користувачів, розподілені таким чином, що середнє навантаження на підсистему залишається рівномірним і не призводить до затримок. Такий підхід дозволяє ефективно вертикально масштабувати систему, розподіляючи навантаження між серверами чи віртуальними дисками.
Горизонтальне масштабування
Горизонтальне масштабування – це розподіл сесій користувачів по різних серверах (рівномірне завантаження серверів додатків та можливість підключати додаткові сервери додатків), а також розподіл даних по різних серверах БД, що забезпечує високу продуктивність системи, при цьому не зумовлюючи зниження відмовостійкості. Для горизонтального масштабування в системі ЛЕТОГРАФ передбачено низку можливостей.
Насамперед це масштабування навантаження завдяки Enterprise Cache Protocol (ECP, протокол розподіленого кешу), протоколу, що використовується в СУБД InterSystems Caché. Перевага ECP полягає в інноваційному підході до кешування даних. В рамках даного протоколу процеси користувача, які працюють на серверах додатків (або ECP-клієнтах) СУБД і обслуговують запити, отримують доступ до локального кешу нещодавно використаних даних. І тільки якщо цих даних недостатньо, ECP-клієнт звертається до бази даних. За допомогою протоколу ECP виконується автоматичне керування кешем: дані, що найчастіше використовуються, зберігаються в кеші, часто оновлювані дані періодично реплікуються, забезпечуючи постійну цілісність і коректність даних на всіх ECP-клієнтах. При цьому внутрішній алгоритм InterSystems Caché передбачає, що бази даних синхронізуються між ECP-клієнтом та ECP-сервером.
Фактично використання технологій СУБД Caché дозволяє легко та швидко масштабувати навантаження по серверах додатків, забезпечивши таким чином підключення великої кількості користувачів до одного серверу бази даних завдяки використанню ECP-протоколу.
Оскільки інформація, яку зажадав той чи інший користувач, може бути задіяна на кількох ECP-клієнтах, необхідно блокувати дані на короткий період часу, швидко виконувати транзакції, не виконуючи внутрішніх обчислень. І ми успішно це реалізували. Дана технологія дозволяє нам ефективно масштабувати систему в ситуації, коли використовуються один сервер бази даних і кілька серверів, на яких працюють процеси користувача. Технологічна особливість СУБД Caché полягає в тому, що вона підтримує коректність транзакцій в рамках одного сервера ECP незалежно від кількості ECP-клієнтів, які до неї підключені. Якщо у нас один ECP-сервер і безліч ECP-клієнтів, це завдання чудово вирішується, тому що всі транзакції йдуть на одному сервері бази даних.
Досвід показує, що у високонавантажених системах завжди вдається чітко розділити дані між серверами БД виходячи з певних ознак. Наприклад, якщо кілька організацій об'єднані в холдинг, то користувачами з однієї структурної одиниці навряд чи колись будуть потрібні дані, що стосуються іншого підрозділу. Це дозволяє лише на рівні алгоритмів розділяти і зберігати такі дані різних серверах БД, підвищуючи в такий спосіб можливості горизонтального масштабування.
У СЕД ЛЕТОГРАФ реалізований механізм шардингу, завдяки якому ми на рівні налаштувань системи (без застосування програмування), даємо можливість описати правила та принципи рознесення самих даних на різні сервери БД. Незважаючи на те, що з точки зору структури баз даних інформація, що зберігається на кожному сервері однакова, сама інформація відрізняється принципово залежно від організації або будь-яких інших ознак, які є значущими для конкретної задачі. Використовуючи технологію шардингу можна домогтися, що в 95-99% випадків користувачі працюватимуть лише зі своєю «порцією даних», і не потрібно в рамках сесії звертатися до різних серверів БД.
На можливості масштабування СЕД ЛЕТОГРАФ впливає і те, що дані можуть по-різному оброблятися. Наприклад, у документи (навіть створені кілька років тому) можуть вноситись зміни, а в журнал дій користувачів записи тільки додаються (жоден запис не може бути видалений, ні змінений). Механізми, що використовуються в СЕД ЛЕТОГРАФ, дозволяють додатково підвищити продуктивність системи та покращити масштабування за рахунок ведення таких журналів на окремих серверах БД – причому, як у разі односерверної, так і багатосерверної конфігурації. Такий підхід орієнтований зниження навантаження на основні сервера БД.
Аналогічна ситуація і контентом (“інформаційним змістом” СЕД). Оскільки система ЛЕТОГРАФ працює з великим обсягом контенту – це терабайти даних, мільйони файлів та документів – розумно припустити, що контент, який потрапляє до системи, за жодних умов не повинен постраждати. Тому ми також виносимо зберігання файлів на окремі сервери баз даних та забезпечуємо таким чином додатково горизонтальне масштабування.
Програмне забезпечення фронт-енду
Як фронт-енд в СЕД ЛЕТОГРАФ використовуються Apache і HAProxy. HAProxy відповідає за балансування навантаження між веб-серверами Apache. HAProxy, як показав досвід роботи системи, зарекомендував себе як найбільш ефективне рішення, здатне забезпечити підтримку роботи великої кількості користувачів та необхідний контроль за стійкістю до відмови.
Коли користувач відкриває браузер і підключається до системи, HAProxy розподіляє його на один із серверів додатків. Далі всі запити, які надходять від цього користувача, будуть надсилатися на той же сервер додатків у той самий процес.
Ми пробували різні системи, і тестування показало, що HAProxy – найефективніший балансувальник навантаження, що забезпечує рівномірний розподіл користувачів по вільним слотам серверів додатків. У HAProxy є всі необхідні механізми, щоб відстежувати стан кожного сервера додатків і не розподіляти новий трафік на сервер додатків, що вийшов з ладу з яких-небудь причин. Крім того, HAProxy додатково надає цілу низку можливостей з погляду кешування статичних (незмінюваних у процесі роботи користувача) даних - наприклад, стилів, іконок і так далі - того, що дозволяє організувати інтерфейс.
Приклад реалізації проекту
Архітектура ЛЕТОГРАФ дозволяє досягти істотних результатів у скороченні часу відгуку та підвищенні продуктивності системи. В рамках одного з наших проектів у СЕД зберігається 23,5 Тбайт даних. З них 14,7 Тбайт (63%) припадає на потоки (“прикріплені до карток файли”), 3,5 Тбайт (15%) – на звітні форми, такі як таблиці звітів, що формуються в асинхронному режимі, можуть запускатися як за розкладом, і на вимогу користувача і є зведену таблицю, будь-які дані у якій можна деталізувати до об'єкта. Ще 1,6 Тбайт (7%) - це протокол користувальницьких операцій, а все інше (16%) - дані карток та індекси.
У цій системі працює понад 11 тис. користувачів, 2 тис. з них працюють одночасно, а в дні пікового навантаження кількість співробітників, що одночасно працюють у ВЕД, перевищує 3 тис. Кількість записів у журналі вже перевищила 5,5 млрд, а облікових карток – майже досягло півмільярда.
Як сервер бази даних у даному проекті встановлено відмовостійкий кластер з двох фізичних серверів з трьома інсталяціями СУБД, а також резервний сервер. Десять серверів додатків (і один резервний) обробляють сесії користувача і забезпечують формування асинхронних звітів. 2 сервери HAProxy виконують функції балансувальників. У разі проблем із одним із серверів, виконується автоматична передача його IP-адреси на інший сервер. Також передбачено сервер індексації файлів та сервер розпізнавання (що забезпечує розпізнавання тексту відсканованих паперових документів при розміщенні електронних образів у систему).
Резюме
У СЕД ЛЕТОГРАФ передбачено велику кількість різноманітних механізмів масштабування. Ми пропонуємо своєрідний пиріг, основу якого лежить сервер (фізичний чи віртуальний), який встановлюється операційна система. Поверх неї стоїть СУБД InterSystems Caché, всередині якої розміщується код платформи. А над ним – налаштування системи ЛЕТОГРАФ, завдяки яким СЕД повністю конфігурується. І такий пиріг розміщено на кожному сервері. Сервера між собою пов'язані певним чином за рахунок вибраних конфігурацій. І останній шар - це HAProxy, що розподіляє між серверами запити користувачів. Така архітектура дозволяє нам підтримувати масштабування та забезпечувати всі необхідні механізми моніторингу. В результаті кінцеві користувачі отримують СЕД, що швидко працює, а ІТ-фахівці – просту в управлінні та обслуговуванні, уніфіковану систему, без величезної кількості складових, які у разі високонавантажених додатків доводиться постійно контролювати і адмініструвати. Крім того, залежно від зміни потреб організації СЕД ЛЕТОГРАФ легко переконфігурувати, додавши нові сервери чи дискові можливості.
Цей матеріал є приватним записом члена спільноти Club.CNews.
Редакція CNews не несе відповідальності за зміст.
