Як організувати резервне копіювання екзабайт даних: поради інженера Google



В нашому блозі на Хабре ми багато пишемо про розвиток власного сервісу 1cloud (наприклад, реалізації можливості використання різних типів дисків на одній віртуальній машині), а також популярних технології — наприклад, системах зберігання даних.

В ході відбулася в 2013 році конференції Google Tech Talks глава підрозділу по забезпеченню надійної роботи Google Раймонд Блум розповів про те, як у компанії влаштований процес резервного копіювання даних. пишет видання High Scalability, Google не розкриває точний обсяг даних, що зберігаються в дата-центрах компанії, проте за непрямими ознаками на момент виступу Блума можна було судити, якщо не про йоттабайтах, то про багатьох экзабайтах даних. Один тільки Gmail містить экзабайты інформації.

За словами Раймонда Блума, звичні техніки бекапа не підходять для Google, оскільки при їх використанні з збільшенням ємності інфраструктури зростає і кількість зусиль на її підтримку. У масштабах Google підхід при якому збільшення обсягів збережених даних в два рази вимагає в два рази більше зусиль по їх збереженню просто не буде працювати. Необхідно мати можливість масштабувати інфраструктурні потужності швидше, ніж буде зростати потреба в них. Бекап одного екзабайта даних і бекап двох екзабайт — це «дві великі різниці». Блум розповів про те, як компанія з цим справляється, а ми представляємо вашій увазі головні тези цього виступу.

Ось відео виступу інженера Google:



А нижче наведена розшифровка основних озвучених підходів до зберігання даних і тез його розповіді:

  • Ніяких втрат даних, ніколи. Навіть під час масштабного збою Gmail у 2011 році, в кінцевому рахунку ніяких втрат даних не відбулося. Такого результату вдалося досягти не лише завдяки використання технологій копіювання на магнітну стрічку. Дані були зібрані з усіх рівнів стека технологій Google, що вимагало серйозних інженерних зусиль.
  • Бекапи марні. Головне завдання – відновити дані. Бекап – це свого роду податок, який ви платите за розкіш всі відновити в кращому вигляді. Тому-то і потрібно робити резервне копіювання настільки витонченими, щоб сам процес відновлення був простий і зрозумілий навіть дитині.
  • Система не масштабується лінійно. Грубо кажучи, якщо кількість інформації зросла в сотні разів, це не означає, що вам достатньо в 100 разів збільшити кількість людських ресурсів і машин. Тут діють збільшують коефіцієнти. Тільки автоматизація процесів дозволить наростити ефективність і можливості системи.
  • Надмірність у всьому. Збої софта і заліза злучають регулярно. Так помирають клітини в нашому організмі. Google не має ілюзій, що все буде жити вічно, компанія повинна бути готова до того моменту, коли черговий компонент системи відмовить.
  • Диверсифікація процесів. Якщо важлива доступність, краще зберігати не в одному місці. Якщо необхідно враховувати можливі помилки користувачів, слід створювати рівні доступу. Щоб не залежати цілком від однієї системи в разі її збою, слід використовувати різні варіанти софта.
  • Зніміть з людей петлю. Користувачів не хвилює, скільки резервних копій їхніх листів зберігає Gmail. У системі є стандартні установки, які повинні працювати завжди. Є якийсь рівень сервісу, і не треба турбувати користувача, поки не станеться дійсно щось з ряду геть.
  • Потрібні докази. Якщо не пробувати, що нічого не буде працювати. Бекапи і відновлення постійно тестують, щоб упевнитися в їх можливостях.
Далі йдуть нотатки автора матеріалу на сайті High Scalability, який виписав головні думки Блума:

Ніякої втрати даних. Їх доступність повинна бути 100%
  • Теоретично, якщо з файла об'ємом 2ГБ втрачається 200 кілобайт, то тут немає нічого страшного. Але з великою часткою ймовірності тепер весь файл може виявитися марним.
  • Проблеми з даними більш істотні, ніж проблеми з доступом. Збій системи – це ще не кінець світу. Якщо втрачені дані – це вже кінець усьому.
  • Google гарантує користувачам збереження даних наступним чином: захист особистих даних, захист від збоїв в роботі програм, захист від збоїв на рівні сховищ даних.
Надмірність – не те ж саме, що відновлюваність
  • Скільки б копій не існувало, це не гарантує, що втрат не буде.
  • Кілька копій корисні для певного типу збоїв. Якщо, приміром, на дата-центр впаде астероїд, а бекапи зберігаються в іншому місці, то в такому випадку все буде ок.
  • Якщо в стеку технологій для резервного копіювання міститься помилка, то це може поставити хрест на стратегії розподіленого бекапа, оскільки всі копії в різних місцях будуть пошкоджені. Саме помилка конфігурації мережі призвела до того самого збою Gmail стався рідкісний випадок, коли навіть наявність двох дублюючих один одного надлишкових мережевих шляху не допомогли і «впали» одночасно.
  • У всесвіті немає стільки астероїдів, скільки існує багів у коді, користувальницьких помилок, записів з пошкодженого буфера.
  • Надмірність підходить для обмеженого набору посилань. Копіювання працює, якщо ви хочете, щоб всі посилання на дані зберігалися в безпосередній близькості від місця їх використання.
Стійкість системи забезпечується і її масштабом
  • Обладнання Google постійно дає збої і ламається… Клітини в організмі постійно відмирають. Ми не думаємо про безсмертя для всіх речей на планеті. Ми готуємося до цього. Машини відживають своє постійно.
  • Надмірність — найголовніше. Результат буде більш надійним, якщо мова йде про групу машин, а не про одного навіть найкращою. Який би ідеальний сервер не вигадали, його може вирішити один єдиний астероїд. Машини, розведені по 50 різним локаціях, важче вивести з ладу.
Паралельні системи більше схильні до втрати даних
  • Те, що MapReduce працює на 30 тис. машин, здорово. Поки не проявиться баг. Цей же баг може з'явитися скрізь одночасно, що тільки посилить ефект.
Локальні копії не позбавляють від збоїв у самому дата-центрі
  • Якщо серверну кімнату затопило, ніякої RAID не врятує.
  • Запущена кілька років тому файлова система Google (GFS), майже дослівно повторює концепцію RAID. Вона використовує техніки кодування, що дозволяють записувати дані в безліч дата-центрів у різних містах одночасно. Тому для відновлення даних потрібно лише N-1 фрагментів. Навіть якщо три ЦОД відключаться в один і той же час, дані все ще будуть відновити.
Доступність і цілісність як характеристики структури
  • Інженери Google, BigTable, GFS, Colossus розуміють термін служби даних і їх цілісність як першочергове завдання. Безліч систем заточене під перевірку та усунення невідповідностей в цих параметрах.
Вам потрібна диверсифікація в усьому
  • Розподіляйте дані по кільком фізичним локаціях.
  • Створюйте рівні роботи з даними, які дозволять захистити їх від помилок користувачів.
  • Мінімізувати наслідки від збою в якомусь одному програмному продукті допоможе використання різного софту.
Копіювання на магнітну стрічку відмінно працює
  • Воно добре хоча б просто тому, що не дисковий. Як говорить Блум, «якщо б можна було, ми б використовували для цього і перфокарти».
  • Уявіть, що у вас баг драйвера для SATA-дисків. Магнітні стрічки вас врятують. Це підвищує диверсифікацію, отже, безпеку, тому що різні носії передбачають і різні програмні засоби для роботи з ними.
  • Продуктивність магнітних стрічок підкоряється закону Мура, тому інженери Google щасливі використовувати цей носій для бекапів, хоча і постійно шукають альтернативні варіанти.
  • Стрічки зашифровані, значить, зловмисники, які захотіли викрасти їх, витратять багато сил і часу, щоб взяти звідти щось корисне.
Бекапи марні. Потрібно турбуватися про відновлення
  • Про проблему потрібно знати до того, як кому-небудь потрібні дані. У разі необхідності відновлення при збої ситуація вже буде куди більш нервовою.
  • Відновлення має бути постійним. Слід випадковим чином вибирати 5% бекапів і відновлювати їх порівняння даних. Навіщо? Щоб переконатися, що все це працює, поки дані в цілості й схоронності. Такий підхід позбавляє від багатьох проблем у майбутньому.
  • Необхідно здійснювати автоматичне співставлення. Порівняти копію з оригіналом не завжди легко, адже орігнал вже міг змінитися. Так що можна порівнювати лише контрольні суми. Після перевірки потрібно повернути копію на той самий носій, де вона перебувала раніше. Важливо переконатися в тому, що працює весь цикл.
Сигнали тривоги встановлюються в залежності від критичності помилки
  • Якщо щось йде не так, про це слід знати.
  • Слід звертати увагу лише на певні збої. Не варто панікувати, якщо файл не відновлюється з першої спроби.
  • Припустимо, що часто збоїв при відновленні з першої спроби це — N. З другої – Y. Зміни в частоті і буде означати сигнал до неспокою.
Все ламається
  • Диски ламаються весь час. Але якщо організувати постійний моніторинг, то можна швидко дізнаватися про помилки.
  • З стрічкою інша історія – ви не зрозумієте, що вона зіпсована, поки не спробуєте їй скористатися. Термін експлуатації магнітних стрічок величезний, але стрічкові носії потрібно тестувати до того, як дані з них дійсно можуть знадобитися.
Бекапи – ваш податок на розкіш якісного відновлення
  • Бекапи треба вдосконалювати. Процес восстановлениями потрібно робити настільки швидким і автоматичним, наскільки це можливо.
  • Відновлення повинно бути простим і швидким. З ним повинен впоратися навіть дитина.
  • Слід виключити людський фактор з процесу відновлення. Знайти час на роботу з бэкапами серед щоденної «текучки» непросто, але це потрібно робити.
  • Джерела даних можуть мати функцію збереження інформації на певний час, може бути, кілька днів, поки йде процес резервування. Але якщо бекап зроблений, дані повинні бути відновлювальні за короткий час.
  • Оптимізувати процес. Витрачати дві години на зчитування даних зі стрічки не годиться. Краще писати та читати паралельно.
Розмір має значення
  • За наявності екзабайта даних існують цілком логічні обмеження. Якщо потрібно скопіювати 10 екзабайт, знадобиться 10 тижнів для резервування щоденної інформації.
  • Дата-центри є по всьому світу, тому є вибір. Існують можливості для забезпечення необмежених можливостей резервування для кожного ресурсу можна розподіляти бекапи по різних регіонах. Питання лише в пропускній спроможності мережі і вартості трафіку.
  • Необхідно аналізувати ціну можливих рішень і йти на компроміси. Не в кожному випадку є можливості для бекапа. Потрібно зробити потужності збалансованими для всієї мережі, тоді буде віддача від кожного долара. Наприклад, бекапи можуть запускатися в дата-центрі X, тому що в нього достатня пропускна здатність.
Розвиток інфраструктури не лінійно
  • не Можна просто захотіти мати мережу з більшою пропускною здатністю або більше число приводів для магнітних стрічок. Вони мають тенденцію виходити з ладу. Тому, якщо у вас 10 тис. таких приводів, потрібно орієнтуватися на можливість проводити з ними 10 тис. операцій по заміні.
  • свого часу пророкували, що з досягненням визначеної кількості використовуваних телефонів, 30% населення США будуть працювати операторами. Вони не враховували, що поява технології автоматичного з'єднання.
Автоматизуйте процеси
  • Ваші дії повинні бути структуровані й автоматизовані. Ви можете поставити службі сервісу завдання копіювати кожен фрагмент N з сховища і відновлювати його в M. Бекапи повинні бути структуровані, запущені перевірки відновлення і цілісності. Пошкодження стрічки повинні виявлятися автоматично.
  • Самостійно за всіма процесами устежити неможливо. Ви можете один раз поцікавитися, скільки стрічок в середньому виходить з ладу. Система попередження може зависнути, якщо раптом кількість пошкоджень на стрічках збільшиться з сотні до 300 в день. Але до цього моменту не варто думати про те, яка частка шлюбу магнітних стрічок.
Виключити людський фактор із стабільних і довготривалих процесів
  • Змінювати і розпаковувати приводи і носії – все ще людська завдання. Все інше – прерогатива автоматизованих інтерфейсів. У всіх інших випадках втручання повинно бути обмежено ситуаціями, коли щось йде не так.
  • То ж з підтримкою програмного забезпечення. Якщо мова йде про оновлення програмної частини, користувачеві не має сенсу запускати вручну кожну систему і стежити за виконанням. Завантажте оновлення, запустіть його в бібліотеку, нехай система його протестує, і результати будуть точними, наскільки можливо. Потім вивантажите. Людина не повинна брати участь у стандартних операціях.
Ефективність повинна зростати
  • Покращуйте ефективність і утилітарність, наскільки це можливо. Неможливо на сторазове збільшення операцій з даними залучати в сто разів більше людей і машин.
Збій і відновлення Gmail 2011. Історія про те, як Google позбувся даних і повернув їх назад
  • У 10:31 інженер отримав повідомлення, в якому говорилося: «Все пропало, набери xxx-xxx...». Детальніше про розвиток подій можна почитати тут.
  • На той момент Gmail оперує майже экзабайтом даних. Це дуже багато магнітних стрічок
  • 100% відновлення. При відсутності стовідсоткового доступу. На це пішло не один і не два дні. Але, зрештою, проблему вирішили.
  • Вся серія багів і помилок сталася на рівні, де відбувається дублювання інформації. Навіть в декількох дубльованих файлів резервних копій були помилки. Навіть після всіх перевірок системи, окремих її елементів та їх взаємодії багам вдалося в неї проникнути.
  • Відновлення з стрічок було важкою роботою. Це як раз той випадок, коли час на відновлення залежить від обсягів інформації. Повернути гігабайт займе від мілісекунди до пари секунд. 200 тис. поштових скриньок по кілька гігабайт – куди більший період.
  • Блум каже, що довелося розбудити пару колег у Європі, тому що вони були свіжішими. «Переваги поділу праці».
  • Дані були відновлені з величезного числа стрічок і перевірені. Це зайняло дні, не тижні і не місяці, що не могло не радувати компанію. Інші компанії витратили б місяць тільки на те, щоб розписатися у безсиллі повернути дані користувачів. Були вжиті заходи, щоб в наступний раз вкластися швидше.
  • Допомогло грамотне розподіл стрічок по локаціях, читання кожної з яких займає близько двох годин.
  • Стиснення і наявність контрольних сум призвело до того, що не треба було читати всі 200 тис. стрічок.
  • Сама технологія відновлення з того моменту була значно вдосконалена.
Першорядне значення має відновлення
  • Архіви листування можна відновити вже після того, як повернулися дані поштової скриньки і відправлених нещодавно листів.
  • Першими можна відновлювати дані поточних користувачів. Акаунти, на які не заходили протягом минулого місяця, можуть почекати.
Бекап-систему можна розглядати як один глобальний організм
  • Немає сенсу робити бекапи Gmail в одному лише дата-центрі в Нью-Йорку. Якщо його розміри зменшаться або збільшаться, соответсвенным чином будуть змінюватися і розміри резервних копій.
  • Бекап — це розподілений процес. Коли щось скопійовано, воно може бути скопійована за тисячу кілометрів від початкового місця.
  • Відновлення з допомогою стрічок повинно відбуватися в місці їх зберігання. Але самі бекапи на стрічках можна робити де завгодно, в залежності від поточної завантаження системи. Розподіл відбувається автоматично. Клієнтам немає користі знати, в якому саме місці зберігаються резервні копії даних.
  • Ємність системи може перетікати з місця на місце. Якщо доступні потужності є в іншому місці, а мережа впорається з передачею даних, фізичне розташування стрічкових накопичувачів вже не грає настільки важливої ролі.
Чим більше даних, тим вище потреба в їх збереженні
  • Великі речі важливіші за визначенням. Коли-то Google був просто пошукачем. Зараз це Gmail і ще купа сервісів. Зріс обсяг – зросла відповідальність.
Потрібна якісна інфраструктура
  • Непогано мати в своєму розпорядженні багатофункціональний швейцарський армійський ніж. Розробники MapReduce спочатку не могли і припустити, що їх продукт можна використовувати для бекапів. Якщо б цієї моделі не існувало, її треба було б придумати.
Тестування відновлення при катастрофах (Disaster recovery testing — DRT)
  • Кожний n-й місяць трапляється найгірший з можливих сценаріїв. Необхідно змоделювати відповідь на нього на кожному з рівнів організації.
  • Зможе компанія впоратися без будь незамінної речі, яка може раптово зникнути внаслідок непередбаченого збігу обставин? Необхідно опрацьовувати такі сценарії, щоб вміти адаптувати в реальному житті.
  • Потрібно виявляти серйозні прорахунки в інфраструктурі і діри в системі безпеки.
  • Уявіть, що до вашої дата-центру йде одна дорога, по ній мчать хури, навантажені паливом для резервних генераторів. Що станеться, якщо шлях буде відрізано? Потрібен альтернативний шлях, альтернативний джерело палива.
  • Ланок ланцюга повинно бути більше, ніж насправді потрібно в даний момент.
Надмірність у всьому: у використовуваному софті, різних локаціях
  • Не дозволяйте даними просто мігрувати по всьому стеку технологій. Дані повинні залишатися на різних рівнях інфраструктури на певний час. Тоді не страшно щось втратити, оскільки ті ж самі дані будуть доступні і в іншому місці..
  • Візьмемо історію зі збоєм Gmail. Блуму задали запитання із залу про те, як вдалося зберегти дані, якщо були пошкоджені бекапи, але він не хотів вдаватися в подробиці. Тим не менш, ось що можна зрозуміти. Дані безперервно бэкапились. Припустимо, ми маємо дані на 9 вечора. Припустимо, процес пошкодження стартував у 8 годин, але до стрічкових носіїв ще добрався — проблему вдалося зупинити на цьому етапі. Система повернулася в робочий стан. В підсумку є ситуація, при якій дані знаходяться на різних рівнях стека — те, що вже на стрічці, щось скопійовано, що на front-end машинах, що в логах. Ці взаємні перетину даних на різних носіях і дозволили відновити все повністю.
Гігантська організація може працювати тільки, якщо всі один одному довіряють і поділяють міру відповідальності
  • Кожен член команди повинен знати, що йому робити і в якому випадку.
  • Організаційні та програмні інтерфейси повинні бути добре захищені. Слід удосконалювати перевірки надійності між рівнями.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.