Как организовать резервное копирование экзабайтов данных: советы инженера Google28.01.2016 11:18

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

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

По словам Раймонда Блума, привычные техники бэкапа не подходят для Google, поскольку при их использовании с увеличением емкости инфраструктуры растет и количество усилий на ее поддержку. В масштабах Google подход при котором увеличение хранимых объёмов данных в два раза требует в два раза больше усилий по их сохранению просто не будет работать. Необходимо иметь возможность масштабировать инфраструктурные мощности быстрее, чем будет расти потребность в них. Бэкап одного экзабайта данных и бэкап двух экзабайтов — это «две большие разницы». Блум рассказал о том, как компания с этим справляется, а мы представляем вашему вниманию главные тезисы этого выступления.

Вот видео выступления инженера Google:

А ниже представлена расшифровка основных озвученных подходов к хранению данных и тезисов его рассказа:

• Никаких потерь данных, никогда. Даже во время масштабного сбоя Gmail в 2011 году, в конечном счете никаких потерь данных не произошло. Такого результата удалось достигнуть не только благодаря использования технологий копирования на магнитную ленту. Данные были собраны со всех уровней стека технологий Google, что потребовало серьезных инженерных усилий.
• Бэкапы бесполезны. Главная задача — восстановить данные. Бэкап — это своего рода налог, который вы платите за роскошь все восстановить в лучшем виде. Поэтому-то и нужно делать резервное копирование настолько изощренными, чтобы сам процесс восстановления был прост и понятен даже младенцу.
• Система не масштабируется линейно. Грубо говоря, если количество информации выросло в сотню раз, это не значит, что вам достаточно в 100 раз увеличить количество человеческих ресурсов и машин. Здесь действуют увеличивающие коэффициенты. Только автоматизация процессов позволит нарастить эффективность и возможности системы.
• Чрезмерность во всем. Сбои софта и железа случают регулярно. Так умирают клетки в нашем организме. Google не питает иллюзий, что все будет жить вечно, компания должна быть готова к тому моменту, когда очередной компонент системы откажет.
• Диверсификация процессов. Если важна доступность, то данные лучше хранить не в одном месте. Если необходимо учитывать возможные ошибки пользователей, следует создавать уровни доступа. Чтобы не зависеть целиком от одной системы в случае ее сбоя, следует использовать разные варианты софта.
• Снимите с людей петлю. Пользователей не волнует, сколько резервных копий их писем хранит Gmail. В системе есть стандартные установки, которые должны работать всегда. Есть некий уровень сервиса, и не надо тревожить пользователя, пока не случится действительно нечто из ряда вон.
• Нужны доказательства. Если не пробовать, ничего не будет работать. Бэкапы и восстановления постоянно тестируют, чтобы удостовериться в их возможностях.

Никакой потери данных. Их доступность должна быть 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 машинах, что-то в логах. Эти взаимные пересечения данных на разных носителях и позволили восстановить все полностью.

• Каждый член команды должен знать, что ему делать и в каком случае.
• Организационные и программные интерфейсы должны быть хорошо защищены. Следует совершенствовать проверки надежности между уровнями.

• ↑

  —

  ↓

• 518

• Добавить в избранное 11