Ceph RGW: чому корпоративне S3-сховище деградує
Класичний сценарій: кластер Ceph RGW запущено, S3-сумісне сховище віддає об'єкти, а через кілька тижнів затримки операцій на читання та запис зростають у рази.
Причина майже завжди не в «залізі», а в тому, як розкладені дані та налаштовані пули: частина вузлів завантажена під стелю, частина простоює, а клієнти скаржаться на таймаути під час вивантаження бекапів і логів.
Деградація об'єктного шлюзу рідко приходить раптово — вона накопичується.
Перекіс даних по вузлах виникає через невдале число placement groups і ваги пристроїв, виставлених «на око»; при додаванні нових дисків це тільки погіршується, бо перерозподіл іде повільно й конкурує за дисковий ввід-вивід з робочими запитами.
Окрема історія — відкликання ключів доступу: якщо політики та облікові записи заведені вручну, ротація ключів перетворюється на простій сервісів, які ще ходять зі старими обліковими даними.
Ще одна типова відмова — невірно вибраний режим індексації бакетів і розмірів об'єктів. Дрібні об'єкти б'ють по числу операцій, великі — по пропускній здатності, і без розділення пулів під дані та під індекс шлюз починає «захлинатися» саме на піках. Сюди ж додається відсутність лімітів на бакети: один сервіс з агресивним записом витісняє інших.
Розбираємо, як це закривається: розкладкою placement groups і вагами вузлів, роздільними пулами під дані та індекси, політиками життєвого циклу й керованою ротацією ключів доступу.
Що дає налаштований Ceph RGW: режими та ефект
Налаштований Ceph RGW перестає бути «ще одним S3» і стає керованим шаром зберігання з передбачуваними характеристиками. Нижче — що саме змінюється і в яких числах це видно.
Режими розміщення об'єктів
Вибір між реплікацією та erasure coding визначає і вартість зберігання, і профіль затримок. Репліка з трьома копіями дає відгук на читання в одиниці мілісекунд і миттєвий відкат, але займає втричі більше місця.
Erasure coding з профілем k+m знижує накладні витрати зберігання в рази, однак додає затримку на відновлення фрагментів. На практиці гарячі бакети тримають на репліці, архів — на erasure-пулах.
Політики доступу
Політики на рівні бакета і префікса знімають ручне керування правами. Замість видачі ключів «на всіх» налаштовуються ролі з обмеженням за операціями і термінами життя — частка інцидентів через надлишкові права падає, а ротація ключів стає плановою операцією, а не авралом.
Відмовостійкість і клас відмов
За коректно заданого CRUSH-правила вихід вузла з ладу не призводить до деградації читання: дані перерозподіляються по решті дисків без зупинки сервісу. Це усуває цілий клас відмов — «впав один сервер, ліг storage» — і скорочує час відновлення до фонового ребалансування.
Час відгуку
Кешування метаданих і винесення індексу бакетів на швидкі носії скорочують час відгуку на лістинг і операції з об'єктами в рази за високого паралельного навантаження. Ручні операції — перенесення бакетів, правка політик, чистка — переходять у декларативні конфігурації.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Репліка 3x | Гарячі дані, низька затримка | Високі витрати місця |
| Erasure coding | Архіви, великі обсяги | Затримка на відновлення |
| Гібрид за пулами | Змішане навантаження | Складніше налаштування правил |
Ceph
Як ми впроваджуємо Ceph RGW: етапи інженерної роботи
Впровадження Ceph RGW починається не зі встановлення пакетів, а з аудиту інфраструктури: дивимося на наявні дискові пули, топологію мереж, поточні точки відмови та профіль навантаження — скільки операцій за секунду, який розмір об'єктів, частка дрібних файлів проти великих.
Від цього залежить схема розміщення: кількість вузлів-зберігачів, розкладка журналів, розмір пулів і політика реплікації за зонами доступності. Шлюз налаштовуємо поверх готового кластера, щоб не перебудовувати сховище після введення в експлуатацію.
- Аудит інфраструктури. Збираємо карту серверів, мереж і сховищ, заміряємо поточне навантаження та точки зростання. На виході — розуміння, скільки вузлів потрібно і де вузькі місця.
- Схема розміщення. Проєктуємо топологію кластера та пулів, визначаємо політику реплікації та правила розміщення даних за зонами відмови.
- Підготовка вузлів. Розгортаємо зберігачі, налаштовуємо мережу зберігання окремо від клієнтської, перевіряємо синхронізацію часу та дискові журнали.
- Налаштування шлюзу. Піднімаємо RGW, заводимо користувачів і ключі доступу, налаштовуємо бакети, квоти та політики життєвого циклу об'єктів.
- Перевірка відмовостійкості. Імітуємо відмову вузла та диска, перевіряємо відновлення даних і поведінку шлюзу під навантаженням — балансування, ліміти з'єднань, кеш.
- Підключення клієнтів. Переводимо застосунки на S3-сумісний доступ, звіряємо сумісність із поточними інструментами та переносимо дані.
- Передача документації. Віддаємо схеми, конфігурації, регламенти обслуговування та проводимо навчання команди замовника.
Кожен етап закінчується перевірюваним результатом, а не звітом. Після здачі у команди залишаються робочі конфігурації, схема розміщення та регламент відновлення — обслуговування й розвиток сховища не залежать від нас. Опишіть задачу — повернемося з оцінкою та планом по вашому контуру.
Чим Ceph RGW відрізняється від класичного S3-шлюзу?
Класичний S3-шлюз — це фасад над уже наявним сховищем: він приймає S3-запити й розкладає об'єкти по заздалегідь виділених томах або масиву.
Ceph RGW влаштований інакше: сам сервіс S3 — лише один з інтерфейсів до єдиного розподіленого сховища, де дані, метадані та їхнє розміщення керуються кластером як одним цілим. Звідси й різниця в поведінці під навантаженням.
У централізованій схемі масштабування йде «вгору»: додаєте диски в масив, розширюєте томи, переносите дані. Кожен такий крок — планова зупинка або міграція, а стеля задана контролером і смугою одного вузла.
У розподіленому сховищі ємність і пропускна здатність зростають «вшир»: новий вузол вводиться в кластер, і дані автоматично перерозподіляються по ньому без простою.
Відмова диска або вузла не валить сервіс — репліки та коди надлишковості вже лежать на інших нодах, відновлення йде фоном.
Саме архітектура зберігання визначає вартість володіння. Централізований підхід вимагає дорогих дискових полиць і резерву під пік, який простоює у звичайні дні.
Розподілене сховище збирається зі стандартних серверів, а надлишковість задається політикою: для гарячих даних — кілька реплік, для архівних — коди надлишковості, які дають той самий рівень відмовостійкості при меншому обсязі. Витрати на зберігання перестають зростати лінійно разом з даними.
Для застосунків різниці в протоколі немає: той самий S3 API, ті самі ключі доступу, ті самі політики. Змінюється поведінка під відмовами та ціна зростання.
Централізований шлюз упирається в стелю вузла й вимагає ручного перерозподілу; Ceph RGW масштабується додаванням нод і переживає відмову заліза без ручного втручання.
Тому вибір — це не про «який S3 зручніший», а про те, чи готові ви до стелі масштабування й ручних міграцій чи хочете зростати передбачувано.
Кейс: як ми усунули перекіс даних у Ceph RGW
До нас прийшла команда, у якої кластер Ceph RGW працював, але дані лягали нерівномірно: два вузли з шести тримали майже половину об'єктів, решта простоювали.
Поки навантаження зростало, це не впадало в око — але при відмові навантаженого вузла відновлення розтягувалося на години, а частина запитів до бакетів відвалювалася за часом очікування.
Що показали метрики до
Зняли стан через ceph osd df tree і radosgw-admin bucket stats: розкид заповнення дисків між вузлами сягав 40%, а кількість розміщувальних груп на дисках відрізнялася в рази.
Причина виявилася складеною — пул створили з малою кількістю розміщувальних груп, а ваги дисків у CRUSH-карті залишилися дефолтними, хоча ємність вузлів була різною.
Що змінили
Перезібрали CRUSH-карту з реальними вагами під ємність кожного диска і перерозподілили розміщувальні групи. Для бакетів увімкнули шардування індексу, щоб навантаження на метадані не липло до одного вузла.
Окремо налаштували політику відновлення: обмежили швидкість зворотного заповнення, щоб ребілд не з'їдав весь канал у робочих запитів.
Що стало
| Метрика | До | Після |
|---|---|---|
| Розкид заповнення вузлів | до 40% | у межах 5% |
| Відновлення після відмови вузла | години | десятки хвилин |
| Стабільність відклику під навантаженням | просідання | рівний графік |
Розкид вирівнявся, відмова вузла перестала бути подією на півдня, а відклик перестав «дихати» на піках. Працювали на Ceph — розподіленому сховищі об'єктів, де рівномірність розкладки напряму визначає і швидкість відновлення, і передбачуваність відклику.
Якщо у вас RGW уже в проді і є підозра на перекіс — покажіть вивід ceph osd df tree, обговоримо задачу і повернемося з планом вирівнювання.
Сумніви перед впровадженням Ceph RGW: сумісність і відкат
Сумісність із наявними застосунками закривається на рівні S3 API: клієнти, що працюють із S3, підключаються до RGW без змін коду — достатньо змінити endpoint і ключі доступу.
Для legacy-застосунків, які вміють лише файлові протоколи, піднімаємо шлюз NFS або SMB поверх того самого сховища, а доступи розмежовуємо через політики бакетів і ролі, щоб застосунок бачив рівно свій префікс.
Міграція даних відбувається без зупинки сервісу: вмикаємо реплікацію між старим і новим сховищем, копіюємо об'єкти пакетами, звіряємо контрольні суми і лише після розходження в нуль перемикаємо трафік.
Відкат змін продумуємо заздалегідь — конфігурація RGW і правила маршрутизації зберігаються в системі контролю версій, тому повернення до попереднього стану виконується однією операцією, а старий контур залишається робочим до підтвердження стабільності.
Що буде, якщо після перемикання виявиться проблема з доступом?
Доступи й політики версіонуються разом із конфігурацією, тому відкат повертає і права, і маршрутизацію до попереднього стану. Старе сховище тримаємо в режимі лише для читання, поки не переконаємося, що всі клієнти працюють штатно — це вікно і є страховкою від несподіванок.
Що якщо застосунок використовує нестандартні розширення S3? Прогоняємо його сценарії на тестовому контурі до міграції та фіксуємо список несумісних викликів — зазвичай їх закривають налаштуванням або тонким прошарком.
Як бути з великим обсягом даних? Копіювання відбувається паралельними потоками з обмеженням навантаження на канал, тому міграція не заважає робочому трафіку.
На руки замовник отримує:
- готові конфігурації RGW і шлюзів доступу;
- схему розміщення та реплікації даних;
- політики доступів і ролі для застосунків;
- план міграції з етапами та точками відкату;
- інструкцію з експлуатації та типових операцій;
- документацію з моніторингу та реакції на збої.
Опишіть вашу задачу та поточний контур зберігання — повернемося з оцінкою сумісності та планом переходу.
Терміни впровадження Ceph RGW: етапи та орієнтири
Терміни залежать не від обсягу заліза, а від кількості інтеграцій: чим більше споживачів S3 та зовнішніх контурів, тим довші узгодження та перевірки. Нижче — орієнтири для кластера середнього масштабу, який розгортається з нуля під корпоративне навантаження.
Етапи йдуть із частковим перекриттям: проєктування починається до завершення обстеження, а підготовка міграції — паралельно з налаштуванням RGW. Тому сума рядків таблиці не дорівнює календарному терміну проєкту.
Тривалість найсильніше розтягують міграція та узгодження на стороні споживачів: перемикання застосунків на новий ендпоінт потребує їхньої участі та вікна обслуговування.
Якщо даних мало або сховище будується «з нуля» без перенесення, загальний термін скорочується приблизно вдвічі.
Орієнтири уточнюються після обстеження — за фактичною кількістю споживачів, обсягом даних і вимогами до доступності. Опишіть задачу: повернемося з оцінкою та планом під ваш контур.
Сумісність Ceph RGW з наявною інфраструктурою
Ceph RGW реалізує S3- та Swift-сумісні інтерфейси, тому прикладний шар зазвичай не потребує переписування: застосунки, що працюють з S3 через штатні бібліотеки, підключаються до RGW зміною endpoint і ключів доступу.
Нижче — з чим інтеграція проходить без доопрацювань, а де потрібно закладати обмеження на етапі розгортання.
Інтеграція з поточним сховищем. Якщо в інфраструктурі вже розгорнуто Ceph, RGW піднімається як окремий сервіс поверх наявних пулів — дані та OSD не перебудовуються. Для середовищ без Ceph розгортання починається з кластера, і це окремий етап з плануванням відмовостійкості.
Обмеження при розгортанні. RGW чутливий до затримок між шлюзом і кластером: при розміщенні на різних майданчиках без локального кешу зростає час відгуку. Балансувальник перед шлюзами обов'язковий для розподілу навантаження, а TLS-термінація налаштовується окремо.
Мультисайтова реплікація вимагає узгодженої конфігурації зон і не терпить розбіжностей у налаштуваннях.
Ceph — перевіряємо сумісність на стенді, що повторює ваше середовище, до перенесення робочих даних.
