Книга «Базы данных. Инжиниринг надежности»
Привет, Хаброжители! В сфере IT произошла настоящая революция — с инфраструктурой стали работать как с кодом. Этот процесс создает не только новые проблемы, но и возможности для обеспечения безотказной работы баз данных. Авторы подготовили это практическое руководство для всех, кто желает влиться в сообщество современных инженеров по обеспечению надежности баз данных (database reliability engineers, DBRE).
В этой книге: • требования к сервисам хранения данных и управление рисками. • создание и развитие архитектуры, обеспечивающей прозрачную поддержку базы данных. • оптимизация процесса управления релизами. • хранение, индексирование и репликация данных. • определение характеристик хранилища данных и подбор оптимальных вариантов его использования. • исследование компонентов архитектуры и создание архитектур, ориентированных на обработку больших данных.
Мы предполагаем, что у вас уже есть некоторые технические знания в области администрирования операционных систем Linux/Unix, а также веб-систем и/или облачных архитектур. Предполагается также, что вы хорошо разбираетесь в одной из дисциплин — системном администрировании или разработке программного обеспечения — и заинтересованы в расширении своего технического кругозора и включении в него новой дисциплины — разработки БД. Либо, в другом варианте, вы начинаете карьеру в качестве специалиста по проектированию БД и стремитесь углубить технические знания.
Если же вы руководитель проекта, то книга поможет вам понять, что требуется для создания хранилищ данных, которые будут лежать в основе ваших сервисов. Мы твердо убеждены в том, что руководителям необходимо понимать принципы работы и организации БД, чтобы их команды и проекты были более успешными.
Да, возможно, у вас нет специального технического образования. Может быть, вы были бизнес-аналитиком и стали администратором БД неожиданно, сменив специализацию и научившись управлять базами данных. Есть много специалистов по базам данных, пришедших в эту область через Excel, а не через разработку или системное администрирование.
Есть веская причина тому, что мы уделяем столь пристальное внимание эксплуатации: вы не станете хорошим инженером по обеспечению надежности БД (DBRE), не будучи хорошим инженером по надежности вообще (RE). А им вы не станете, не будучи просто хорошим инженером. Современный DBR-инженер не только хорошо разбирается в основах системного проектирования, но и понимает проблемы данных, связанные с конкретной предметной областью.
Однако дело в том, что запускать сервисы данных может любой инженер. Сейчас мы говорим на одном языке. Мы используем одни и те же репозитории, одни и те же процессы проверки кода. Забота о БД — это расширение инженерной деятельности, взбитые сливки из специальных знаний и умений на вершине торта из функционирующих систем различного масштаба. Точно так же, для того чтобы стать сугубо сетевым инженером, нужно сначала выучиться на инженера, а затем получить дополнительные знания о том, как обрабатывать трафик, чего следует опасаться, каковы современные передовые методики, как оценивать топологию сети и т. д.
Вот краткий перечень того, что вас ожидает.
Глава 1 представляет собой введение в концепцию обеспечения надежности БД. Мы начнем с основополагающих принципов, перейдем к работе по сопровождению и эксплуатации — тому центру, вокруг которого вращается DBRE, — и, наконец, соорудим каркас для возведения концепции DBRE с опорой на пирамиду потребностей Маслоу.
Главу 2 начнем с требований уровня обслуживания сервисов. Они так же важны, как и требования к характеристикам продукта. В этой главе мы обсудим, что такое требования уровня обслуживания и как их определить, — что на самом деле легче сказать, чем сделать. Затем поговорим, как измерить соответствующие параметры и как работать с ними в динамике.
В главе 3 мы познакомимся с оценкой рисков и управлением ими. После обсуждения основ и рисков вообще перейдем к практическим процессам включения оценки рисков в разработку систем и БД. Рассмотрим также подводные камни и различные сложности.
В главе 4 поговорим об оперативном контроле. Обсудим показатели и события. Вы узнаете, как составить план того, что нужно начать измерять и что повторять регулярно. Подробно рассмотрим компоненты систем мониторинга и клиентские приложения, которые взаимодействуют с ними.
В главах 5 и 6 мы углубимся в проектирование инфраструктуры и управление ею. Обсудим принципы построения хостов для хранилищ данных. Мы погрузимся в виртуализацию и контейнеризацию, управление конфигурацией, автоматизацию и оркестрацию, чтобы помочь вам разобраться во всех составных частях, необходимых для построения систем, которые обеспечивают хранение данных и доступ к ним.
Глава 7 посвящена резервному копированию и восстановлению данных. Это, пожалуй, самое важное для освоения DBE. Потерял данные — все, игра окончена. Исходя из требований к уровню качества сервиса, мы выбираем подходящие методы резервного копирования и восстановления данных, а также способы масштабирования и проверки этого важного, но часто пропускаемого шага.
В главе 8 мы обсудим управление версиями. Как тестировать, подготавливать и развертывать изменения в хранилищах данных? Как быть с изменениями в коде доступа к данным и SQL? Основные темы — развертывание, интеграция и распространение.
Глава 9 посвящена безопасности. Безопасность данных имеет решающее значение для работоспособности компании. В этой главе описаны стратегии планирования безопасности постоянно развивающихся инфраструктур данных и управления ею.
В главе 10 поговорим о хранении, индексации и репликации данных. Мы обсудим, как хранятся реляционные данные, а затем сравним их с отсортированными строками и структурированными объединениями деревьев. Рассмотрев разные варианты индексации, изучим топологии репликации данных.
Глава 11 представляет собой путеводитель в области хранения данных. Здесь мы рассмотрим множество различных факторов, которые вам предстоит находить и учитывать для тех хранилищ данных, что вы будете оценивать или сопровождать. Сюда входят как концептуальные особенности, имеющие огромное значение для разработчиков и архитекторов приложений, так и внутренние характеристики, связанные с физической реализацией хранилищ.
В главе 12 мы рассмотрим некоторые из наиболее распространенных типовых решений (паттернов), применяемых при проектировании архитектур распределенных БД, и конвейеры, с которыми они связаны. Начнем с архитектурных компонентов, из которых обычно состоит «среда обитания» (экосистема) базы данных, и познакомимся с обеспечиваемыми ими преимуществами, со связанными с ними сложностями и с основными принципами их использования. Затем исследуем архитектуры и конвейеры — хотя бы на нескольких примерах.
Наконец, в главе 13 мы обсудим создание культуры обеспечения надежности БД в организации. Исследуем различные способы, с помощью которых в современной организации можно превратить специалиста по обеспечению надежности баз данных из администратора в инженера.
Резервное копирование и восстановление
В главах 5 и 6 мы сосредоточились на проектировании инфраструктуры и управлении ею. Это означает, что вы хорошо представляете, как создавать и развертывать распределенные инфраструктуры, в которых работают базы данных, а также управлять ими. Мы рассмотрели методы быстрого добавления новых узлов для увеличения емкости или замены неисправного узла. Теперь пришло время обсудить самое главное — резервное копирование и восстановление данных.
Посмотрим правде в глаза: все считают резервное копирование и восстановление скучными и утомительными занятиями. Для большинства эти процедуры — воплощение рутины. Команде не нравится взаимодействовать с младшими инженерами и внешними подрядчиками и работать со сторонними инструментами. Прежде нам приходилось иметь дело с просто ужасным программным обеспечением для резервного копирования. Мы вам сочувствуем, честно.
Тем не менее это один из самых значимых процессов в вашей работе. Перемещение важных данных между узлами, центрами обработки данных и их перенос в долгосрочные архивы — это постоянное движение самого ценного актива вашего бизнеса — информации. Мы настоятельно рекомендуем вам не считать восстановление и резервирование операциями второго сорта, а относиться к ним как к VIP-операциям. Каждый должен не только понимать цели восстановления данных, но и быть хорошо знакомым с принципами этой работы и мониторингом процессов. В философии DevOps предполагается, что каждый должен иметь возможность писать код и внедрять его в реально работающей системе. Мы предлагаем каждому инженеру хотя бы один раз принять участие в процессах восстановления критически важных данных.
Мы создаем и храним копии данных — резервные копии и архивы — как средство удовлетворения конкретной потребности. Они нужны для восстановления. Иногда восстановление оказывается приятным и неспешным делом, например при создании среды для аудиторов или настройке альтернативной среды. Но чаще всего оно требуется для быстрой замены неисправных узлов или увеличения емкости существующих кластеров.
Сегодня в распределенных средах мы сталкиваемся с новыми проблемами в области резервного копирования и восстановления данных. Как и раньше, большинство локальных наборов данных распределяются в разумных пределах, максимум на несколько терабайт. Различие состоит в том, что эти локальные наборы данных — лишь часть большого распределенного набора. Восстановление узла является относительно управляемым процессом, но сохранение состояния в кластере — более сложная задача.
Основные принципы
Начнем с обсуждения основных принципов резервного копирования и восстановления данных. Опытному специалисту по базам данных или системному инженеру некоторые из них могут показаться элементарными. Если это так, можете спокойно пролистать несколько страниц.
Физическое или логическое?
При физическом резервном копировании базы данных создаются резервные копии реальных файлов, в которых хранятся данные. Это означает, что поддерживаются свойственные базе данных форматы файлов, и обычно в базе есть набор метаданных, которые определяют, какие есть файлы и какие структуры БД в них находятся. Если, создавая резервные копии файлов, вы ожидаете, что другой экземпляр базы данных сможет их использовать, то вам потребуется сделать резервную копию и сохранить связанные с ней метаданные, на которые опирается эта база данных, чтобы резервная копия была переносимой.
При создании логической резервной копии данные экспортируются из базы в формат, который теоретически можно перенести в любую систему. Обычно метаданные тоже сохраняются, но, скорее всего, они будут актуальны для того момента, когда выполнялось резервное копирование. Примером является экспорт всех операторов вставки, необходимых для заполнения пустой базы данных при ее обновлении. Другой пример — строка в формате JSON. В итоге логическое резервное копирование, как правило, занимает очень много времени, потому что это не физическая операция копирования и записи, а построчное извлечение данных. Аналогично восстановление сопровождается всеми обычными издержками базы данных, такими как блокировки и создание журнальных записей повторов и отмены.
Отличный пример такого разделения — различие между репликацией на основе строк и репликацией на базе операторов. Во многих реляционных базах данных репликация на основе операторов означает, что после записи в систему контроля версий к ним добавляется журнал операторов языка манипулирования данными (DML, или вставка, обновление, замена, удаление). Эти операторы передаются в реплики, в которых воспроизводятся. Другой подход к репликации основан на строках или захвате данных изменений (Change Data Capture, CDC).
Автономное или оперативное?
Автономное (или холодное) резервное копирование — такое копирование, при котором экземпляр базы данных, использующий файлы, отключен. Благодаря этому можно быстро скопировать файлы, не беспокоясь о сохранении состояния на текущий момент, пока другие процессы читают и записывают данные. Это идеальное, но очень редко встречающееся состояние.
При оперативном (или горячем) резервном копировании вы все равно копируете все файлы, но есть дополнительная сложность, связанная с необходимостью получить согласованный моментальный снимок данных, который должен существовать то время, в течение которого выполняется резервное копирование. Кроме того, если текущий трафик обращается к базе данных во время резервного копирования, необходимо быть осторожными и следить за тем, чтобы не превысить пропускную способность подсистемы ввода-вывода на уровне хранилища. Даже ограничивая нагрузку, вы можете обнаружить, что механизмы, используемые для поддержания согласованности, вносят необоснованные задержки в работу приложения.
Полное, инкрементное и дифференциальное
Наличие полной резервной копии, независимо от того, каким методом она создана, означает, что локальный набор данных полностью зарезервирован. Для небольших наборов данных это довольно обычное дело. Для 10 Тбайт это может занять невероятное количество времени.
Дифференциальное резервное копирование позволяет создавать резервные копии только данных, измененных с момента последнего полного резервного копирования. Но на практике обычно резервируется больше данных, чем только измененные, потому что данные организованы в виде структур определенного размера — страниц. Размер страниц составляет, например, 16 или 64 Кбайт, и страница содержит много строк данных. При дифференциальном резервном копировании создается резервная копия всех страниц, на которых были изменены данные. Таким образом, при больших размерах страниц получаются резервные копии значительно большего размера, чем если бы там хранились только измененные данные.
Инкрементное резервное копирование аналогично дифференциальному, за исключением того, что в качестве момента времени, к которому относятся измененные данные, будет использоваться дата последней резервной копии, инкрементной или полной. Таким образом, при восстановлении из инкрементной резервной копии может потребоваться восстановить последнюю полную резервную копию, а также одну или несколько инкрементных резервных копий, чтобы добраться до текущего момента.
Зная это, обсудим несколько моментов, которые следует учитывать при выборе эффективной стратегии резервного копирования и восстановления данных.
Соображения по восстановлению данных
Впервые выбирая эффективную стратегию, следует снова рассмотреть свои целевые показатели качества обслуживания (SLO), которые обсуждались в главе 2. В частности, необходимо учесть показатели доступности и надежности. Какую бы стратегию вы в итоге ни выбрали, она все равно должна предусматривать возможность восстанавливать данные в рамках заранее определенных ограничений по времени безотказной работы. И вам придется выполнять резервное копирование быстро, чтобы гарантировать соответствие заданным характеристикам надежности.
Если проводить резервное копирование каждый день, а журналы транзакций между резервными копиями держать в хранилище на уровне узла, можно легко потерять эти транзакции до следующего резервного копирования.
Кроме того, необходимо учесть, как набор данных функционирует в рамках целостной экосистемы. Например, ваши заказы могут храниться в реляционной базе, где все зафиксировано в виде транзакций и, следовательно, легко восстанавливается по отношению к остальным данным, хранящимся в этой БД. Однако, после того как заказ сформирован, рабочий процесс может запускаться событием, сохраненным в системе очередей или хранилище типа «ключ — значение». Эти системы могут обеспечивать целостность данных лишь эпизодически или даже кратковременно (быть эфемерными), ссылаясь при необходимости на реляционную базу или используя ее для восстановления. Как учесть эти рабочие процессы при восстановлении?
Если вы имеете дело со средой, где ведется быстрая разработка, то может оказаться, что данные, сохраненные в резервной копии, были записаны и использованы одной версией приложения, а после восстановления выполняется другая. Как приложение будет взаимодействовать с устаревшими данными? Хорошо, если данные версионированы — тогда это можно учесть, но вы должны знать о такой возможности и быть готовыми к подобным случаям. Иначе приложение может логически повредить эти данные, что приведет к еще большим проблемам в будущем.
Все эти и многие другие нюансы, которые невозможно предсказать, необходимо учитывать при планировании восстановления данных. Как говорилось в главе 3, невозможно подготовиться к любой ситуации. Но очень важно постараться это сделать. Восстановление данных — одна из главнейших обязанностей инженера по обеспечению надежности БД. Таким образом, ваш план восстановления данных должен быть максимально широким и учитывать как можно больше потенциальных проблем.
Сценарии восстановления
Приняв все сказанное во внимание, обсудим типы происшествий и операций, которые могут потребовать восстановления данных, чтобы можно было спланировать удовлетворение всех потребностей. Сначала можно разделить все сценарии на плановые и незапланированные. Рассматривая восстановление данных лишь как инструмент для разрешения чрезвычайных ситуаций, вы ограничите инструментарий своей команды только средствами неотложной помощи и имитации аварий. И наоборот, если включить восстановление данных в повседневную деятельность, то можно ожидать более высокой степени осведомленности и успешного разрешения чрезвычайных ситуаций. Кроме того, у нас появится больше данных, позволяющих определить, поддерживает ли стратегия восстановления наши SLO. При нескольких ежедневных прогонах сценария будет проще получить набор образцов, который включает в себя предельные значения и который можно довольно уверенно использовать для планирования.
Сценарии планового восстановления
В какие повседневные задачи можно внедрить процессы восстановления? Вот список, который чаще всего встречался нам на разных сайтах:
- создание новых узлов и кластеров в среде промышленной эксплуатации;
- создание различных сред;
- выполнение извлечения, преобразования и загрузки (Extract, Transform and Load, ETL) и стадий технологического процесса обработки данных для последовательно размещенных хранилищ;
- проведение эксплуатационных тестов.
При выполнении этих операций обязательно включите процесс восстановления в стек оперативного контроля. Учитывайте следующие показатели.
- Время. Сколько времени занимает выполнение каждого компонента и всего процесса? Распаковка? Копирование? Выполнение журнала? Тестирование?
- Размер. Сколько места занимает резервная копия, сжатая и несжатая?
- Пропускная способность. Какая нагрузка на оборудование создается?
Эта информация поможет вам избежать проблем с пропускной способностью, что позволит обеспечить стабильность процесса восстановления.
Новые узлы и кластеры в среде промышленной эксплуатации
Независимо от того, являются ваши базы данных частью неизменной инфраструктуры или нет, существуют возможности для регулярных перестроек, при которых по мере необходимости будут использоваться процедуры восстановления.
Базы данных редко включаются в автоматическое масштабирование систем из-за того количества времени, которое может потребоваться для начальной загрузки нового узла и его помещения в кластер. Тем не менее нет никаких причин, мешающих команде создать расписание регулярного ввода новых узлов в кластер для тестирования этих процессов. Chaos Monkey (http://bit.ly/2zy1qsE) — инструмент, разработанный Netflix, который случайным образом отключает системы, позволяет сделать это таким образом, чтобы можно было протестировать весь процесс мониторинга, выдачи уведомлений, сортировки и восстановления. Если вы еще этого не сделали, то можете включить это в план контрольного списка процессов, которые ваш отдел эксплуатации должен выполнять через регулярные промежутки времени, чтобы все сотрудники ознакомились с процедурой. Эти действия позволяют протестировать не только полное и инкрементное восстановление, но и включение в поток реплицирования и процесс ввода узла в эксплуатацию.
Создание разных сред
Вы неизбежно будете создавать среды разработки, интеграционного и оперативного тестирования для демонстрационных и других целей. Некоторые из этих сред требуют полного восстановления данных, и в них необходимо реализовать восстановление узлов и полное восстановление кластера. Часть сред предъявляют другие требования, такие как поддержка частичного восстановления для тестирования функций и очистка данных в целях обеспечения конфиденциальности пользователя. Это позволяет тестировать восстановление данных на определенный момент времени, а также восстановление конкретных объектов. Все это сильно отличается от стандартного полного восстановления и бывает полезно для восстановления повреждений, вызванных действиями оператора и ошибками приложений. Создавая API, которые обеспечивают восстановление данных на уровне объекта и на определенный момент времени, вы можете облегчить автоматизацию и ознакомление работников с этими процессами.
ETL и конвейерные процессы для хранилищ данных, расположенных далее по конвейеру
Как и для задач построения среды, процессы и API восстановления из моментальных снимков или на уровне отдельных объектов могут быть успешно применены при передаче данных из рабочих БД в конвейеры для последующей аналитики и в потоковые хранилища.
Эксплуатационное тестирование
В процессе выполнения различных сценариев тестирования вам понадобятся копии данных. Одни тесты, например для емкости и нагрузки, требуют полного набора данных, что отлично подходит для полного восстановления. При функциональном тестировании могут потребоваться меньшие наборы данных, что позволит выполнить восстановление на определенный момент времени и на уровне объекта.
Само тестирование восстановления данных может стать непрерывной операцией. Кроме применения процессов восстановления данных в повседневных сценариях, можно настроить постоянное выполнение операций восстановления. Это позволит автоматизировать тестирование и валидацию, чтобы быстро выявлять любые проблемы, которые могут возникнуть при нарушении процесса резервного копирования. Когда заходит речь о реализации этого процесса, многие спрашивают о том, как проверить успешность восстановления.
При создании резервной копии можно получить много данных, которые затем использовать для тестирования, например:
- самый последний идентификатор в последовательности автоматического приращения;
- счетчик строк для объектов;
- контрольные суммы для подмножеств данных, которые только вставляются и, следовательно, могут рассматриваться как неизменяемые;
- контрольные суммы в файлах определения схемы.
Как и при любом тестировании, подход должен быть многоуровневым. Существует ряд тестов, которые либо будут выполнены успешно, либо быстро закончатся сбоем. Это должен быть первый уровень тестирования. Примеры — сравнение контрольных сумм по определениям метаданных/объектов, успешный запуск экземпляра базы данных и успешное подключение к потоку репликации. Операции, которые могут занять больше времени, такие как вычисление контрольных сумм и подсчет таблиц, должны выполняться позже в ходе проверки.
Незапланированные сценарии
С учетом всех повседневных плановых сценариев, которые можно использовать, процесс восстановления данных должен быть хорошо отлажен, документирован, отработан и в достаточной степени свободен от ошибок и проблем. Благодаря этому незапланированные сценарии редко оказываются настолько пугающими, насколько могли бы быть. Команда не должна видеть разницы между плановым и незапланированным восстановлением. Перечислим и подробно рассмотрим ситуации, которые могут потребовать от нас выполнения процессов восстановления:
- ошибка пользователя;
- ошибка приложения;
- наличие инфраструктурных сервисов;
- ошибки операционной системы и аппаратные ошибки;
- аппаратные сбои;
- сбои центра обработки данных.
Ошибка пользователя
В идеале ошибки пользователя должны возникать редко. Выстраивая для инженеров «перила» и «заграждения», вы можете предотвратить многие подобные ситуации. Тем не менее всегда остается вероятность того, что оператор случайно нанесет ущерб. Типичный пример — везде и всеми забываемое условие WHERE при выполнении UPDATE или DELETE в клиентском приложении базы данных. Или, например, выполнение сценария очистки данных не в тестовом окружении, а в рабочей «производственной» системе. Зачастую операция выполняется правильно, но в неподходящее время или не для тех хостов. Все это относится к ошибкам пользователя. Часто их выявляют и исправляют сразу же. Однако иногда последствия таких изменений остаются незамеченными в течение нескольких дней или недель.
Ошибки приложений
Ошибки приложений — самый страшный из обсуждаемых сценариев, поскольку они бывают очень коварными. Приложения постоянно изменяют способ взаимодействия с хранилищами данных. Многие приложения также управляют ссылочной целостностью и внешними указателями на такие ресурсы, как файлы или сторонние идентификаторы. Страшно представить, что будет, если просто внести изменение, которое портит данные, удаляет их или добавляет неверные данные способами, которые могут остаться незамеченными в течение довольно длительного времени.
Инфраструктурные сервисы
В главе 6 мы познакомились с магией сервисов управления инфраструктурой. К сожалению, эти системы могут оказаться столь же разрушительными, сколь и полезными, что может привести к широкомасштабным последствиям, связанным с редактированием файла, указанием на другую среду или неправильной настройкой конфигурации.
Ошибки ОС и аппаратные ошибки
Операционные системы и оборудование, с которым они взаимодействуют, — это тоже системы, созданные людьми, и, таким образом, в них возможны ошибки, которые могут иметь неожиданные последствия из-за недокументированных или плохо известных конфигураций. В контексте восстановления данных это особенно верно в отношении пути передачи данных из БД через кэши ОС в файловые системы, контроллеры и в итоге на диски. Повреждение или потеря данных случаются гораздо чаще, чем мы думаем. К сожалению, наше доверие к этим механизмам и опора на них порождают ожидание целостности данных вместо скептического отношения к ней.
Незаметное повреждение данныхИменно такая ошибка ОС и оборудования произошла в Netflix в 2008 году. Для обнаружения и исправления ошибок на дисках использовался код исправления ошибок (ECC). ECC автоматически ликвидирует однобитовые ошибки и обнаруживает двухбитовые. Таким образом, ECC-код позволяет обнаружить ошибку, вдвое превышающую расстояние Хэмминга, которую он способен исправить. Следовательно, он может исправить 46 байт на жестком диске 512-байтового сектора и обнаружить до 92 байт ошибки. То, что невозможно исправить, передается контроллеру как неисправимое, и контроллер диска увеличивает значение счетчика «неисправимая ошибка» в S.M. A.R.T. Ошибки размером свыше 92 байт передаются прямо в контроллер как хорошие данные. Это касается и резервных копий. Страшно, правда?
Именно поэтому следует с большим скептицизмом относиться к облачным и так называемым серверным вычислениям. Если у вас нет доступа к деталям реализации, то вы не можете быть уверены в том, что целостность данных будет главным приоритетом. Слишком часто она игнорируется или даже настраивается так, чтобы скорость имела более высокий приоритет. Нет знаний — нет силы.
Инструменты вычисления контрольных сумм для файловых систем, такие как ZFS, будут проверять контрольную сумму каждого блока, гарантируя обнаружение неверных данных. Если же использовать RAID-массив, что подразумевает зеркалирование или проверку четности, то он даже исправит данные.
Аппаратные сбои
Аппаратные компоненты выходят из строя в принципе, а в распределенных системах это случается регулярно. Вы постоянно сталкиваетесь со сбоями дисков, памяти, процессоров, контроллеров и сетевых устройств. Следствиями этих аппаратных сбоев могут стать выход из строя узлов или задержки на узлах, из-за чего система становится непригодной для использования. Системы общего доступа, такие как сетевые устройства, способны влиять на целые кластеры, делая их недоступными или разбивая на более мелкие кластеры, которым неизвестно о том, что сеть оказалась разделена. Это может привести к быстрому и значительному расхождению данных, которые необходимо объединить и исправить.
Сбои центра обработки данных
Иногда неполадки оборудования на сетевом уровне приводят к сбоям в центре обработки данных. Бывает так, что перегрузка соединительных панелей хранения данных вызывает каскадные сбои, как в случае с веб-сервисами Amazon в 2012 году (http://bit.ly/2zxSpzR). Иногда ураганы, землетрясения и другие катаклизмы приводят к тому, что выходят из строя целые центры обработки данных. Последующее восстановление проверит на прочность даже самые надежные стратегии восстановления.
Область действия сценария
Перечислив запланированные и незапланированные сценарии, которые могут вызвать необходимость восстановления, добавим к этим событиям еще одно измерение, чтобы наше представление стало объемным. Это будет полезно для выбора самого подходящего способа реагирования. Рассмотрим следующие варианты:
- сбой, локализованный в рамках одного узла;
- сбой всего кластера;
- сбой, затронувший весь центр обработки данных или несколько кластеров.
В случае локального, или одноузлового, сбоя восстановление ограничивается одним хостом. Возможно, вы добавите в кластер новый узел для увеличения емкости или замены неисправного узла. Или же в системе реализовано непрерывное обновление и тогда восстановление будет выполнено узел за узлом. В любом случае это локальное восстановление.
В масштабе кластера необходимость восстановления является глобальной для всех членов этого кластера. Возможно, произошло деструктивное изменение или удаление данных, которое каскадно распространилось на все узлы. Или же вам понадобилось ввести новый кластер для тестирования емкости.
Если случился сбой в масштабах центра обработки данных или нескольких кластеров, значит, необходимо восстановить все данные в месте их физического размещения или по всей области сбоя. Это может быть связано с отказом общего хранилища данных или со сбоем, вызвавшим катастрофический отказ центра обработки данных. Такое восстановление может потребоваться также при плановом развертывании нового дополнительного сайта.
Кроме области действия, существует область набора данных. Здесь можно перечислить три возможных варианта:
- один объект;
- несколько объектов;
- метаданные базы данных.
В масштабах одного объекта только этот конкретный объект требует восстановления данных — некоторых или всех. Обсуждавшийся ранее случай, в результате которого при выполнении операции DELETE удалялось больше данных, чем планировалось, относится к сбою в рамках одного объекта. При сбое нескольких объектов оказываются затронуты несколько или, возможно, все объекты в конкретной базе данных. Такое может произойти при повреждении приложения, неудачном обновлении или миграции сегмента. Наконец, бывают сбои в масштабах метаданных базы, когда с данными, хранящимися в базе, все в порядке, но теряются метаданные, делающие ее пригодной для использования, такие как пользовательские данные, полномочия безопасности или соответствия файлам ОС.
Последствия сценария
Важно не только определить сценарий, требующий восстановления, и выделить область сбоя, но и определить возможные последствия, поскольку при выборе подхода к восстановлению они будут значительными. Если потеря данных не влияет на SLO, можете выбрать методичный и медленный подход, позволяющий свести к минимуму расширение последствий. К более глобальным изменениям, которые приводят к нарушению SLO, следует подходить осторожно, выбирая быстрое восстановление обслуживания и только потом переходя к долгосрочной очистке. Можно разделить все подходы на с
