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

А нічого. У хорошому розумінні нічого. Бітрікс перестав валяти дурня і "винаходити велосипед" - мабуть таки потрапив у команду розумний технолог, тому замість "велосипедів" вони взяли і зробили все так, як прийнято робити у нормальних людей. У цьому пості я розповім простими словами– що саме вони зробили і як вам повторити те саме у своєму проекті.

Розглянемо основні частини кластера:

0. Cloud – хмара, набір серверів, на якому все це крутитиметься.
1. Load balancer – балансувальник вхідного навантаження.
2. MySQL replication – найпопулярніший вид кластеризації баз даних.
3. Network file system– розподілене файлове сховище.

Як було сказано вище, кластер – це набір із довільної кількості веб-серверів. Вони можуть виконувати те саме завдання, або різні в залежності від цілей. Почнемо із серверів: тут їм пропонується використовувати віртуальні машини aws.amazon.com. Я не сказав би, що це розумне рішення: віртуалки апріорі повільні, але тут ключовий момент- Простота їх створення. Натиснув на кнопку – утворилася. Причому не дефолтна машина, а налаштована безпосередньо під ваші потреби. Можна створювати за розкладом або загалом динамічно при зростанні навантаження. Потрапив ваш сайт під потужний потіквідвідувачів – воно р-р-р-аз та створило кілька нових машин. Закінчилося навантаження - машини відключилися. Краса.

Зрозуміло, як сервери кластера можуть виступати будь-які сервери в інтернеті: хоч віртуальні, хоч залізні. Для довідки: свій особистий “амазонівський” кластер безкоштовно може зробити собі будь-яка людина, яка не полінується запустити встановлення свіжого дистрибутива Ubuntu Server.

Балансувальник потрібен для того, щоб розподіляти запити відвідувачів сайту між серверами кластера. Як його пропонується використовувати nginx, гуглить "nginx load balance" і отримуєте купу посилань на готові приклади.

Реплікація баз даних потрібна у тому, щоб записувати дані одному сервері (він називається master – майстер), а читати їх із усіх інших (відповідно slave – слейв). Так як зазвичай операцій запису мало, а операцій читання багато, то шляхом простого збільшення кількості слейв можна необмежено нарощувати "потужність" проекту. Дані з майстра на слейви перетікають у фоновому режимічисто засобами MySQL, причому слейви можна додавати і прибирати будь-якої миті. Гугліть “mysql replication” та отримуєте інструкції.

Розподілене файлове сховище потрібно для того, щоб усі сервери мали один і той же набір файлів. Якщо користувач завантажив картинку "кудись" на один із серверів, то вона повинна з'явитися скрізь. Чому? Тому що іншим користувачам інформація може бути надана з іншого сервера. Для реалізації товариші з Бітрікса рекомендують “csync2” – воно працює у фоновому режимі та тупо синхронізує файли між серверами, щоб всюди все було однаково.

Всі. Ось ви й зробили кластер. А тепер – файн-тюнінг:

Перший камінь спотикання, на який ви натрапите при перекладі свого проекту (я маю на увазі проект на інший CMS або самописний) на таку модель - буде в операціях з базою даних. Суть у тому, що додаток повинен вміти відрізняти запити, що “пишуть” від “читаючих”. Іншими словами, INSERT, UPDATE, DELETE, а також CREATE, ALTER і DROP потрібно виконувати тільки на майстрі. Запити SELECTу принципі можна виконувати скрізь. Щоб перевчити ваш двигун на такий спосіб мислення, знадобиться дуже відчутний час.

Крім того, бітріксоїди придумали цікаву штуку: оскільки дані з майстра на слейви витікають з деякою затримкою, вони привчили систему розпізнавати "критичні" запити. Після такого запиту всі дані до самого кінця виконання php-скриптів беруться (SELECT) тільки з майстра, щоб уникнути помилок через ту саму затримку.

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

Третя думка – кластеризація memcached. Бітрікс виніс його на початок своєї презентації, але ви можете запустити його і пізніше. Його перевага в тому, що він безпосередньо в'яжеться з nginx (пам'ятаєте перший пункт?) і дозволяє віддавати закешовані сторінки (або блоки) фактично безпосередньо з оперативної пам'яті. Ваше завдання – точніше завдання ваших скриптів – поміщати кешований контент у memcached.

Як розробляти проект на кластері? Часте питаннядля представників веб-студій. Так точно так, як на звичайному сервері. Кластер для вас буде лише одним великим комп'ютером, на який ви так само заходите по ssh і працюєте.

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

Для яких завдань потрібний веб-кластер?

Кластер необхідний для гнучкого вирішення завдань збільшення навантаження та підвищення стабільності сервісу. Так, зі збільшенням відвідуваності можна швидко додати до кластера нові сервери. А у разі виходу з ладу одного із серверів кластера система продовжує безперервно обслуговувати відвідувачів/клієнтів. Не менше важливе завдання– це балансування навантаження, трафіку, даних між кількома серверами. При цьому система дозволяє знімати резервні копіїіз спеціально виділених вузлів кластера, не впливаючи на роботу сайту, не вимикаючи машини та не гальмуючи їх. Окремо стоять завдання георозподілу. Коли ви запускаєте географічний веб-кластер, це дозволяє піднімати цілі групи серверів. У кожній із цих груп працює свій майстер – у незалежних один від одного датацентрах. Таким чином, ваші сайти, ваш бізнес повністю захищені від недоступності самих датацентрів та каналів зв'язку.

Як працює веб-кластер 1С Бітрікс?

Розглянемо які технології використовує веб-кластер 1С Бітрікс:

• Для БД – це вертикальний шардинг(Винесення модулів на окремі сервери MySQL)
• Реплікація MySQLі балансування навантаженняміж серверами
• Розподілений кеш даних(memcached)
• Безперервність сесійміж веб-серверами (зберігання сесій у базі даних)

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

Секрети високих навантажень на 1С Бітрікс із веб-кластером

1. MySQL Sharding (шардинг)

Поділ однієї бази даних веб-додатка на дві і більше баз даних за рахунок виділення окремих модулів, без зміни логіки роботи веб-додатка.

У окремі основи можна винести такі модулі товару: , .

2. Реплікація MySQL

Схема « master slave» реалізується засобами MySQL/MariaDB. Цей стек технології досить добре описаний і широко використовується.

3. Балансувальник для вирівнювання навантаження між серверами

Зупинимося на балансувальнику докладніше. Платформа «1С-Бітрікс: Управління сайтом» у функціоналі Веб-кластер дозволяє гнучко балансувати навантаження між серверами, що беруть участь у реплікації.

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

4. Розподілений кеш даних (під керуванням: memcached)

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

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

5. Безперервність сесій

Для організації безперервності сесій між веб-серверами необхідно увімкнути зберігання сесій у базі даних, а самі бази даних у нас реплікуються, як було зазначено вище.

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

Вітаю, шановні спільники!

Ця стаття - про те, як ми реалізували веб-кластер для порталу новин(з піком відвідувань у 130 тисяч унікальних відвідувачівна день - це 7Тб трафіку за 3 дні - вибори та 2 наступні. Зараз у середньому кластер роздає 35-40 Тб трафіку на місяць), про те, як по-різному розуміють однакові завдання програмісти та журналісти, про те, як можна досягти однієї і тієї ж мети, йдучи різними шляхами.

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

Я більше ніж впевнений, що маркетологи, які штовхають убер-рішення свіжовипущених продуктів, що мають у своїй назві слова "масштабований веб-кластер" або "horizontal infinite scalable web cluster", мене зненавидять.

Я більше, ніж впевнений, що конкуренти наших клієнтів будуть здивовані простотою рішення, яке ми використовували.

Я не наводитиму банальних конфігів, які можна знайти в будь-якому тоторіалі по налаштування PHP, Nginx і Firebird (у останнього, строго кажучи, і налаштовувати-то нічого - все працює з пів-стусан «з коробки») і взагалі розповідатиму про сутність рішення, а не про те, яка з версій PHPкраще.

Досвідченим проектувальникам навряд чи буде цікаво - вони і так все знають, а ось тим, хто тільки починає шлях на нелегкій ниві проектування систем складніше, ніж Hello, World! напевно буде що підкреслити - рішення в бойовому режимі вже скоро як 2 роки, при цьому жодних архітектурних проблем не виникало (хоча вихід з ладу одразу двох) жорстких дисківна двох із трьох вузлів був, але ніхто нічого не помітив - сайти трохи повільніше відкривалися, ніж зазвичай).

Отже, кілька слів, з чого все починалося. Жив-був сайтик групи незалежних журналістів, які дуже мріяли стати справжнім телебаченням (забігаючи наперед, скажу, що у них це вийшло – вони створили своє, цілком успішне телебачення з «блэкджеком і шл...» – далі за текстом). Країна у нас маленька, нічого страшного не відбувається (і ми цьому раді), але раз на 4 роки у нас традиційно відбуваються вибори до Парламенту. Що вже традиційно ніяк не обирає Президента. (Не бійтеся, політики тут не буде, це просто для загального розуміннямоменту).

Зрозуміло, у період перед виборами і трохи після все інтернет ЗМІ дуже ковбасить. Деякі сайти не просто лежать, вони валяються, деякі періодично намагаються видати хоча б рядок тексту, але проблема загальна та відома - сайти не справляються з напливом відвідувачів. Я про звичайні текстові сайти. У наших клієнтів сайт був незвичайний. Справа в тому, що у них було і відео - сюжети новин, вони виробляли 10 гігабайт на місяць - в той час, зараз вони створюють таку кількість відео в день. До всього іншого (це остання згадка політики, слово честі) ці журналісти не відрізнялися особливою лояльністю до влади. Говорили та писали що хотіли. Зовсім нахабніли, так? Ми завжди позиціонуємо себе як найманців - клієнт пропонує завдання, ми пропонуємо її рішення. Решта нас не цікавить, ми дотримуємося нейтралітету.

Перед нами було поставлене завдання - запропонувати рішення для сайтів новин, яке дозволить не просто вистояти при напливі 50-100 тис відвідувачів, але ще було б і географічно розкидане по світу і керувалося з мобільного бункера будь-якої точки Всесвіту планети. Зрозуміло, географічний розкид вузлів кластера залишався за нами. В результаті ми запропонували наступну схему (художник з мене ніякий, ви мене вибачите):

(Це спрощена схемана листопад, надалі майже всі сервери перенесли до Hetzner-у, тому що у Netdirekt-a тоді постійно ковбасило канал. Зараз у них із мережею ситуація набагато краща).
Звичайні відвідувачі бачать один з 3-х серверів, при цьому ми зробили так, що «легкий» контент у вигляді тексту і картинок всі відвідувачі з Молдови тягнули з одного з 3-х, а «важкий» контент (відео) - тягнули з сервера, що розташований у місцевого провайдера. Зовнішні відвідувачі просто не бачили молдавське дзеркало, і весь контент тягли з одного з німецьких серверів.

Ось що у нас вийшло з відвідувачами в результаті (кожна частина порталу має свій лічильник):

Ця схема дозволяє змінити керуючий сервер у будь-який момент, сама перевіряє доступність вузлів кластера, легко масштабується - як резервний розглядався і Amazon EC - більше того, Amazon EC навіть використовувався деякий час для відеостримінгу (близько 4-х місяців), але через дорожнечі трафіку вирішено було все-таки стрімінг-ноди перенести до німецького Hetzner-у.
Безпосередньо за 2 тижні до «Х» ми взяли резервні сервериі тримали їх напоготові (але користувачі їх не бачили, тому що тримати активним сервер дещо дешевше, ніж використовувати його в бойовому режимі – тільки через трафік).

Як це все працює? Дуже просто - мовчки та цілодобово;).

На керуючому сервері (як я вже згадував, у порталу 2 великих «розділу»: новини у вигляді тексту з картинками та новини у вигляді текстового дайджесту та відео-де-факто використовується 2 сервери, але для простоти я зобразив один) є те, що Традиційно називається системою управління контентом.

Основне завдання цього сервера – дозволяти журналістам додавати новини. Раз на визначений час(3-5 хвилин) стартує скрипт, який створює offline-копію сайту. Зрозуміло, генеруються тільки сторінки, які були змінені або які потребують перебудови через кросилки та залежності.

Це дуже просто реалізується за допомогою генераторів (sequense) і каскадних тригерів Firebird - процедурі потрібно внести зміни тільки в основну сторінку сайту, а каскадні тригери оновлять всі залежності, помітивши кожну сторінку, яка потребує оновлення. Позначка виставляється над вигляді прапора 1/0, а вигляді унікального номера, одержуваного на основі генератора Скрипт створення офлайнової версії при старті дізнається нове значення генератора, зчитує значення цього генератора від попереднього запуску і перетворює всі сторінки в отриманому діапазоні. У цьому, оскільки ми використовуємо транзакційний механізм Firebird – скрипту глибоко наплювати, які відбуваються під час виконання - тобто. у нас завжди створюється цілісна та несуперечлива версія сайту, щоб при цьому не робили репортери.

Таким чином, у нас створюється майстер-копія порталу (ну або двох порталів, якщо завгодно – текстового та відео). Скрипт (як і сама адмінка) написаний на PHP і для роботи з Firebird використовує ADODB - так що його досить просто можна перебудовувати за бажанням замовника *.

(* Але ми збираємося позбутися ADODB незабаром у всіх наших майбутніх проектах - його універсальність тільки шкодить, тому що нормального механізму роботи з БД, що дозволяє використовувати всі особливості Firebird SQL сервера(втім, як і інших) там не реалізовано - наприклад, неможливо перехоплювати винятки під час вибірки із селективних процедур, немає гнучкого управліннятранзакціями і взагалі, у цих класів занадто багато ІІ - я волію самостійно вирішувати, коли хочу відкотити тразакцію, а коли - підтвердити.)

Єдине, що довелося змінювати в налаштуваннях Firebird - це значення розміру кешу сторінок БД - так як кількість підключень до БД дуже невелика (рідко коли більше 50-60 одночасних підключень), то і кількість сторінок експериментальним шляхом було збільшено до 2048 (ми використовуємо Classic варіант, для архітектури Super це значення спокійно можна збільшити в 10 разів, тому що там загальний кеш сторінок. У майбутній версії Firebird 3.0 розробники обіцяють одну SMP-friendly архітектуру з спільним кешем, Так що для неї цілком можна буде використовувати великі значення для налаштувань сторінкового кешу).

Потім, за допомогою звичайного rsync-а різниця змін розкидається по дзеркалах, які являють собою звичайні вузлидля роздачі статики з урахуванням Nginx. Я думаю, не потрібно розповідати, на що здатний 4-хядерний сервер з 12 гігабайтами оперативної пам'яті при роздачі однієї лише статики? ;-)

При цьому, 10% каналу кожної ноди (це якраз 10 або 100 мегабіт, залежно від конкретного підключення) зарезервовано для синхронізації. Синхронізація відбувається у 2 етапи – спочатку синхронізується «важкий» контент – картинки та відео, потім – текст (html/xml/js).

Іноді (при завантажених каналах від керуючого сервера до дзеркал) відвідувач може побачити маленькі невідповідності у вигляді картинок і/або відеороликів, що не навантажуються - так як використовується round-robin DNS, то текст сторінки користувач може отримати з одного дзеркала, а посилання на відео - з іншого . Це не заважає порталу працювати - текст є завжди, а картинка чи відео рано чи пізно з'являться.

Так як на сайтах є динамічні форми - наприклад, підписка на розсилку новин - то ці форми обробляються окремо виділеним сервером (він не зображений на схемі, але суті це не змінює). Навіть якщо припустити, що всі відвідувачі одночасно ламатимуться підписуватися на новини і цей сервер «ляже» – нічого страшного не станеться – форми підвантажуються в iframe і на доступності новин відсутність цих формочок ніяк не відбивається.

Додавання нового вузла відбувається просто - спочатку синхронізується нове дзеркало з основною копією (це відбувається паралельно зі звичайним режимом роботи синхронізатора), потім запис додається до DNS і ніхто нічого не помічає.

Видалення ноди відбувається простіше - просто забирається запис із DNS. Додавання та видалення цілком піддаються автоматизації (саме так ми вчинили з частиною, яка відповідала за веб-стрімінг близько 1000 мегабітних потоків на Amazom EC), але якщо ви раптом наважитеся повторювати подібне – раджу спочатку порахувати, скільки займає первинна синхронізація даних (у нас це 2 Гігабайти для « легкої версіїпорталу» і приблизно 1 Терабайт для відео, зберігається лише кілька останніх місяців).

Саме тому динамічне додавання/видалення нід з пулу запасних ми прибрали через деякий час роботи проекту - надто багато займає контент і надто вже параноїдальним вийшов скрипт - прибирав ноди при кожній проблемі зв'язку з ними.

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

Програмісти чудово розуміють, що дізнатися, скільки людей у теперішній моментчитають статтю просто неможливо, можна лише порахувати кількість запитів статті із сервера, для журналістів це однакові поняття. :)

Для підрахунку переглядів ми зв'язалися з Кирилом Коринським (також відомим як catap), який люб'язно погодився додати фічу підрахунку переглядів URL у свою гілку Nginx-а. Ну а далі вже все просто - всі вузли періодично опитуються і лічильники сторінок враховуються у властивостях самої сторінки. Оскільки лічильники (тобто самі значення) зберігаються в окремих файлах(зараз це по одному файлу на новину, незабаром ми плануємо зробити групу лічильників в одному файлі, щоб зменшити кількість самих файлів) - при синхронізації передається не сторінки сайту повністю, а тільки файл-лічильник. При великій кількості файлів це створює додаткове навантаження на дискову підсистему - тому, при використанні такого ж підходу відразу продумуйте про те, як розбити лічильники по групах - ми зупинилися на розбитті лічильників за типами новин та датою - файли відносно маленькі і згодом вони перестають змінюватися , оскільки старі новини нікого мало цікавлять.

Ось коротко, плюси використаного нами рішення:

1. Використання статичних сайтів як вузли веб-кластера дозволяє звести адміністрування всього кластера до кількох. рутинним завданням- Оновлення операційної системивузлів та оплаті трафіку. Цей пункт дозволяє розкидати географічно вузли кластера, що разом із GEO-DNS може розглядатися взагалі як деякий аналог мережі доставки контенту (CDN) - насправді це і є.
2. Використання транзакційного механізму БД та перенесення логіки в саму БД дозволяє завжди мати цілісну та логічно несуперечливу версію сайту – втім, я б дуже здивувався, якби «зріз» даних із сервера був би логічно нецілісним.
3. Якщо очікується наплив відвідувачів, то простим збільшеннямвузлів кластера можна легко з ним упоратися. У нашому випадку, повне введеннянового вузла в строй займав трохи більше години для текстової частини порталу і близько доби (не можна впхнути невпихуемое) для відео. Якщо змиритися з частковою синхронізацією сайтів та інше «доливати» у фоні – то введення нового вузла для відео також можна скоротити до години.
4. Адміністративний сервер можна зробити з будь-якого з вузлів (за потреби) - досить просто розгорнути бекап бази(У стислому вигляді близько сотні мегабайт). Весь решта контенту вже є.

Ну і парочка мінусів, щоб не все здавалося таким безхмарним:

1. Рішення не підходить для випадків, коли є частини сайту, які по-різному мають бачити різні користувачі, тобто. коли за умовою завдання сторінки генеруються персонально кожному за користувача. У нашому випадку цього виявилось і непотрібно.
2. Лічильники відвідувань оновлюються з відставанням приблизно о півгодини-годину. Терпимо, але вам доведеться в цьому довго переконувати клієнта.
3. Найбільше проблем завдає синхронізація з місцевим дзеркалом - наші провайдери ще не продають трафік за ціною 7 євро за Терабайт і якщо і надають 100 чесних мегабітів у світ - то за дуже неадекватними цінами.
4. Проектуйте менш параноїдальну систему стеження за вузлами кластера - наша виявилася надто чутливою, довелося переводити додавання та видалення вузлів у ручний режим.

І буквально маленька щіпка досвіду, яка дозволить урізноманітнити прісну кашу буднів.

Для зберігання офлайн-копії сайту ми використовуємо файлову систему JFS. Вона себе дуже добре зарекомендувала і при роботі з безліччю дрібних файлів і при роботі з великими файлами(На мій досвід ще тільки XFS може практично моментально видалити файл розміром в 200-300Гб).

Так ось - за умовчанням файлова системамонтувалася з параметрами за промовчанням. Але так як у нас з часом стало дуже багато файлів, дискові операціїстали трохи підгальмовувати. Оскільки час останнього доступудо файлу нам не потрібно, я додав опцію "noatime" до параметрів монтування ФС. Ось що вийшло - момент додавання, гадаю, ви визначите самі:

Коротко повторюся - для стабільної роботив звичайному режимівикористовується:

• 3 сервери для роздачі контенту
• 2 сервери для «адмінки»
• 2 сервери для DNS та системи стеження за іншими серверами.

Вузли кластера розкидані географічно та знаходяться у різних провайдерів.
У разі очікуваних подій, що залучають велика кількістьвідвідувачів - підключаються додаткові серверидля роздачі вмісту.

На місяць споживається близько 40Тб трафіку, загальний об'ємконтенту – трохи більше 1 Терабайту, відеоконтент зберігається близько 3-х місяців.

Я із задоволенням відповім на питання хабраспівтовариства.

1С-Бітрікс: Веб-кластер Основні завдання, які необхідно вирішити: 1. Забезпечення високої доступності сервісу (так звані HA – High Availability або Failover кластери) 2. Масштабування веб-проекту в умовах зростаючого навантаження (HP – High Performance кластери) 3. Балансування навантаження, трафіку даних між кількома серверами. 4. Створення цілісної резервної копії даних MySQL.

1С-Бітрікс: Веб-кластер «Веб-кластер» забезпечує безперервність бізнесу, стійкість до відмов, масштабування, розподіл навантаження. Будь-який новий або працюючий проект на 1С-Бітрікс: Управління сайтом 10.0 може бути представлене як веб-кластер взаємозамінних серверів. 1.При збільшенні відвідуваності можна швидко додати до кластера нові сервери. 2.У разі виходу з ладу одного із серверів кластера система продовжує безперервно обслуговувати Клієнтів. 3.Балансування навантаження, трафіку, даних між кількома серверами. 4.Система дозволяє знімати резервні копії із спеціально виділених вузлів кластера, не впливаючи на роботу сайту.

Історія продуктивності платформи До 2005 року питанням продуктивності системно не займалися рік – продуктивність стала суттєвим завданням для розробки рік – поява інструментів налагодження SQL-запитів. Системна робота над продуктивністю продукту рік – перше тестування навантаженняз QSOFT (1.5 млн. хітів на добу на редакції «Бізнес», 6 млн. – на редакції «Старт») роки – розгорнуто 4 конфігурації Oracle RAC з 4 серверами рік – «монітор продуктивності» у всіх редакціях продукту роки – випущено «1С -Бітрікс: Віртуальна машина» та «1С-Бітрікс: Веб-оточення» – сертифікація хостинг-провайдерів рік – зростання продуктивності – на 430%! Нові тести навантаження: 8.5 млн. хітів – «Бізнес», 12.4 млн. – «Старт», 85 млн. – «HTML кеш».

Варіанти масштабування до розділення на два сервери: веб-сервер + база даних. 2.Збільшення потужності обладнання (чим потужніше – тим дорожче; зростання вартості не пропорційне). 3.Виділення кешу на один зовнішній серверчерез memcached. 4. Перехід на Oracle (мінімальна ліцензія +5000 $ за процесор). 5. Створення Oracle RAC (Real Application Cluster). Проект - близько $ (обладнання + ліцензія + "загальна полиця"). Дуже мало спеціалістів. Для більшості клієнтів продуктивності достатньо, але не вирішено проблеми відмовостійкості, резервування, доступу до мережі.

1С-Бітрікс: Веб-кластер «1С-Бітрікс: Веб-кластер» - це комбінація технологій: Вертикальний шардинг (винесення модулів на окремі сервери MySQL) Реплікація MySQL (Oracle і MS SQL надалі) та балансування навантаження між серверами Розподілений кеш даних (memcached) Безперервність сесій між веб-серверами (зберігання сесій у базі даних) Кластеризація веб-сервера: – Синхронізація файлів – Балансування навантаження між серверами

Розділення однієї бази даних веб-додатка на дві і більше баз даних за рахунок виділення окремих модулів, без зміни логіки роботи веб-додатка: Веб-аналітика Пошук 1.Ефективний розподіл навантаження. 2.Масштабування. 3.Поділ великих обсягівданих. Вертикальний шардинг

Веб-сервер База даних MySQLВеб-додаток Високе навантаження: ~10^3 writes/sec ~10^4 reads/sec Висока відвідуваність 1) Запити обробляються лише одним сервером СУБД 2) CPU та дискова підсистемаСУБД – перевантажені Масштабування при зростанні навантаження MySQL

Висока ефективність – за рахунок централізованого використання кешу веб-додаткомНадійність - за рахунок стійкості підсистеми кеширування до виходу з ладу окремих компонентів Необмежена масштабованість - за рахунок додавання нових memcached-серверів. memcached 1 memcached 2 memcached 3 Веб-кластер «1С-Бітрікс» 40%30% Веб-сервер Розподілений кеш даних (memcached)

Безперервність сесій між веб-серверами Користувальницька сесія має бути "прозорою" для всіх серверів веб-кластера. 1.Після авторизації на одному із серверів користувач повинен вважатися авторизованим і для всіх інших серверів. 2.І навпаки - закінчення сесії будь-якому сервері має означати її закінчення всіх серверах відразу.

80% Висока відвідуваність 1) Навантаження обробляється лише одним веб-сервером 2) CPU перевантажено обробкою PHP, прекомпілятор включений, спостерігаються segmentation faults Завдання: масшта" title="Веб-сервер База даних MySQL Веб-додаток Високе навантаження на CPU >80% Висока відвідуваність 1) Навантаження обробляється тільки одним веб-сервером 2) CPU перевантажений обробкою PHP, прекомпілятор включений, спостерігаються segmentation faults" class="link_thumb"> 22 !}Веб-сервер База даних MySQL Веб-додаток Високе навантаження на CPU >80% Висока відвідуваність 1) Навантаження обробляється тільки одним веб-сервером 2) CPU перевантажений обробкою PHP, прекомпілятор включений, спостерігаються segmentation faults Завдання: масштабування при зростанні навантаження 80% Висока відвідуваність 1) Навантаження обробляється тільки одним веб-сервером 2) CPU перевантажений обробкою PHP, прекомпілятор включений, спостерігаються segmentation faults Завдання: масшта"> 80% Висока відвідуваність 1) Навантаження обробляється тільки одним веб-сервером 2) CPU перевантажений , прекомпілятор включений, спостерігаються segmentation faults Завдання: масштабування при зростанні навантаження"> 80% Висока відвідуваність 1) Навантаження обробляється тільки одним веб-сервером 2) CPU перевантажений обробкою PHP, прекомпілятор включений, спостерігаються segmentation faults Завдання: масшта" title="(! LANG:Веб-сервер База даних MySQL Веб-додаток Високе навантаження на CPU >80% Висока відвідуваність 1) Навантаження обробляється тільки одним веб-сервером 2) CPU перевантажений обробкою PHP, прекомпілятор включений, спостерігаються segmentation faults Завдання: масшта"> title="Веб-сервер База даних MySQL Веб-додаток Високе навантаження на CPU >80% Висока відвідуваність 1) Навантаження обробляється тільки одним веб-сервером 2) CPU перевантажений обробкою PHP, прекомпілятор включений, спостерігаються segmentation faults Завдання: масшта"> !}

Чому ми вибрали csync2? Швидкий доступдо файлів програми за рахунок використання локальних сховищ. Висока швидкістьроботи. Низьке споживання ресурсів (CPU, дискові операції). Два цих фактори дозволяють запускати процес синхронізації максимально часто, тому дані на серверах стають ідентичними практично в реальному часі. Простота налаштування для обміну даними між будь-якою кількістю серверів. Можливість синхронізації видалення файлів. Захищений обмін даними між хостами (SSL).

Веб-сервер База даних MySQL MASTER «1С-Бітрікс: Веб-кластер» База даних MySQL SLAVE 1 База даних MySQL SLAVE N Он-лайн бекап данихДиск Цілісний логічний/фізичний бекап MySQL без уповільнення роботи основної системи База даних MySQL MASTER candidate DRBD – он-лайн бекап дисказ базою даних Організація резервного копіювання- MySQL

Веб-сервер «1С-Бітрікс: Веб-кластер» /var/www LVM /var/www – снепшот 1 /var/www – снепшот 2 /var/www – снепшот 3 Швидкий, цілісний бекап на рівні LinuxШвидкий, цілісний, інкрементальний, автоматично консолідований бекап інструментами хостера Організація резервного копіювання - файли

«1С-Бітрікс: Веб-кластер», ДЦ у Москві БД Веб-нода «1С-Бітрікс: Веб-кластер», ДЦ у Нью-Йорку «1С-Бітрікс: Веб-кластер», ДЦ у Новосибірську круговий, асинхронний, master -master реплікацією для забезпечення роботи географічно розподілених веб-кластерів 1С-Бітрікс Кеш БД Веб-нода Кеш БД Веб-нода Кеш Ми працюємо над…

«1С-Бітрікс: Веб-кластер», ДЦ у Москві БД Веб-нода «1С-Бітрікс: Веб-кластер», ДЦ у Нью-Йорку «1С-Бітрікс: Веб-кластер», ДЦ у Новосибірську круговий, асинхронний, master -master реплікацією для забезпечення роботи географічно розподілених веб-кластерів 1С-Бітрікс Кеш БД Веб-нода Кеш БД Веб-нода Кеш БД Веб-нода Кеш БД Веб-нода Кеш БД Веб-нода Кеш БД Веб-нода Кеш БД Веб-нода Кеш Ми працюємо над…

Стійкість системи при вимкненні вузлів веб-кластера При відключенні вузлів кластера система не перериває обслуговування клієнтів. Збільшується черга (зростає час віддачі сторінок клієнтам), проте загалом система збалансована за навантаженням. Зворотне додавання сайту веб-кластера пропорційно збільшує продуктивність системи. Навантажувальний тест- відключення одного з вузлів кластера