Одним из важнейших аспектов любого решения для хранения данных является надежность — насколько хорошо ваши данные защищены от потери или повреждения? И это может показаться особенно важным для облачной среды. Облачное хранилище рассчитано на надежность не менее
99,999999999% в год, или 11 девяток. Это означает, что даже с одним миллиардом объектов вы, вероятно, проживете сто лет, не потеряв ни одного!
Мы очень серьезно относимся к достижению наших целей по долговечности. В этом посте мы рассмотрим основные способы защиты данных в облачном хранилище. В то же время защита данных — это, в конечном счете, общая ответственность (наиболее частой причиной потери данных является случайное удаление пользователем или администратором хранилища), поэтому мы предоставим передовые методы защиты ваших данных от таких рисков, как стихийные бедствия и пользовательские ошибки.
Физическая прочность
Большинство людей думают о надежности в контексте защиты от сбоев сети, серверов и оборудования хранения.
В Google философия заключается в том, что программное обеспечение — это, в конечном счете, лучший способ защиты от сбоев оборудования. Это позволяет нам достичь более высокой надежности по привлекательной цене, вместо того, чтобы полагаться на экзотические аппаратные решения. Мы предполагаем, что оборудование будет постоянно выходить из строя — потому что это так! Но это не значит, что страдает долговечность.
Чтобы сохранить объект в облачном хранилище, мы разбиваем его на несколько «блоков данных», которые размещаем на разных серверах с разными источниками питания. Мы также создаем ряд «фрагментов кода» для избыточности. В случае отказа оборудования (например, сервера, диска) мы используем фрагменты данных и кода для восстановления всего объекта. Этот метод называется кодированием со стиранием. Кроме того, мы храним несколько копий метаданных, необходимых для поиска и чтения объекта, чтобы в случае отказа одного или нескольких серверов метаданных мы могли продолжить доступ к объекту.
Ключевым требованием здесь является то, что мы всегда сохраняем данные с избыточностью в нескольких зонах доступности, прежде чем запись будет признана успешной. Используемые нами кодировки обеспечивают достаточную избыточность для поддержки цели более 11 девятки устойчивости к аппаратным сбоям. После сохранения мы регулярно проверяем контрольные суммы, чтобы защитить данные в состоянии покоя от определенных типов ошибок данных. В случае несоответствия контрольной суммы данные автоматически восстанавливаются с использованием избыточности, присутствующей в наших кодировках.
Лучшая практика: используйте двух- или многорегиональные местоположения
Эти уровни защиты от рисков физической прочности хороши и хороши, но они не могут защитить от значительного физического разрушения региона — подумайте о военных действиях, падении астероида или других крупномасштабных катастрофах.
Целевой показатель прочности Cloud Storage 11 девяток применяется к одному региону. Чтобы пойти дальше и защититься от стихийных бедствий, которые могут уничтожить целый регион, подумайте о хранении наиболее важных данных в сегментах с двумя или несколькими регионами. Эти сегменты автоматически обеспечивают избыточность ваших данных в географических регионах. Использование этих сегментов не требует дополнительной настройки или изменений API в ваших приложениях, обеспечивая дополнительную устойчивость к очень редким, но потенциально катастрофическим событиям. В качестве дополнительного преимущества эти типы местоположений также имеют значительно более высокую доступность SLA, поскольку мы можем прозрачно обслуживать ваши объекты из более чем одного местоположения, если регион временно недоступен.
Долговечность при транспортировке
Другой класс рисков устойчивости связан с повреждением передаваемых данных. Это могут быть данные, передаваемые по сетям в самой службе облачного хранилища или при выгрузке или загрузке объектов в / из облачного хранилища.
Для защиты от этого источника повреждения данные, передаваемые в облачном хранилище, всегда без исключения защищены контрольной суммой. В случае ошибки проверки контрольной суммы запрос автоматически повторяется или возвращается ошибка, в зависимости от обстоятельств.
Лучшая практика: используйте контрольные суммы для выгрузки и скачивания
В то время как Google Cloud проверяет суммы всех объектов облачного хранилища, которые перемещаются в рамках нашего сервиса, для обеспечения сквозной защиты мы рекомендуем вам указывать контрольные суммы при загрузке данных в облачное хранилище и проверять эти контрольные суммы на клиенте при загрузке объекта..
Риски долговечности, вызванные деятельностью человека
Возможно, самый большой риск потери данных связан с человеческой ошибкой — не только с ошибками, совершаемыми нами как разработчиками и операторами службы, но и с ошибками, совершаемыми пользователями облачного хранилища!
Ошибки программного обеспечения потенциально являются самым большим риском для надежности данных. Чтобы избежать потери долговечности из-за ошибок программного обеспечения, мы в первую очередь стараемся избегать ошибок, приводящих к повреждению или стиранию данных. Затем мы обеспечиваем меры безопасности для быстрого обнаружения этих типов ошибок с целью их отлова до того, как ухудшение долговечности превратится в потерю долговечности.
Чтобы заранее выявлять ошибки, мы выпускаем новую версию Cloud Storage в рабочую среду только после того, как она пройдет большой набор интеграционных тестов. Сюда входит выполнение различных сценариев сбоя в крайних случаях, таких как выход из строя зоны доступности, и сравнение поведения API-интерфейсов кодирования и размещения данных с предыдущими версиями для выявления регрессий.
После утверждения новой версии программного обеспечения мы развертываем обновления поэтапно по зонам доступности, начиная с очень ограниченной начальной области воздействия и постепенно увеличиваясь до тех пор, пока она не станет широко распространенной. Это позволяет нам выявлять проблемы до того, как они окажут большое влияние, и пока есть дополнительные копии данных (или достаточное количество фрагментов кода стирания), из которых можно восстановить при необходимости. Эти развертывания программного обеспечения тщательно отслеживаются, и в случае необходимости предусмотрены планы быстрого отката.
Вы также можете многое сделать, чтобы защитить свои данные от потери.
Рекомендация: включите управление версиями объектов
Одним из наиболее распространенных источников потери данных является случайное удаление данных администратором хранилища или конечным пользователем. Когда вы включаете управление версиями объектов, Cloud Storage сохраняет удаленные объекты на случай, если вам потребуется восстановить их позже. Настроив политики управления жизненным циклом объектов, вы можете ограничить время хранения объектов с версиями до их окончательного удаления, чтобы лучше контролировать расходы на хранение.
Лучшая практика: сделайте резервную копию ваших данных
Целевая надежность Cloud Storage 11 девяток не избавляет от необходимости резервного копирования ваших данных. Например, подумайте, что может сделать злоумышленник, если получит доступ к вашей учетной записи Cloud Storage. В зависимости от ваших целей резервная копия может быть второй копией данных в другом регионе или облаке, локально или даже физически изолированной с воздушным зазором на ленте или диске.
Рекомендация: используйте политики сохранения доступа к данным и журналы аудита
Для долгосрочного хранения данных используйте функцию блокировки корзины облачного хранилища, чтобы задать политики хранения и обеспечить блокировку данных на определенные периоды времени. Это предотвращает случайное изменение / удаление и в сочетании с журналом аудита доступа к данным может удовлетворить нормативные и нормативные требования, такие как FINRA, SEC и CFTC, а также определенные правила хранения в отрасли здравоохранения.
Лучшая практика: используйте политики управления доступом на основе ролей
Вы можете ограничить радиус действия злонамеренных хакеров и случайных удалений, убедившись, что политики контроля доступа к данным IAM соответствуют принципам разделения обязанностей и наименьших привилегий. Например, отделите тех, кто может создавать сегменты, от тех, кто может удалять проекты.
Ключи шифрования и надежность
Все данные облачного хранилища всегда зашифрованы при хранении и передаче в облаке. Поскольку объекты невозможно прочитать без их ключей шифрования, потеря ключей шифрования представляет собой значительный риск для надежности — в конце концов, какой смысл в данных с высокой надежностью, если вы не можете их прочитать? В облачном хранилище у вас есть три варианта управления ключами: 1) доверить Google управление ключами шифрования за вас, 2) использовать ключи шифрования, управляемые клиентом (CMEK) с Cloud KMS, или 3) использовать ключи шифрования, предоставленные клиентом (CSEK) с внешний сервер ключей.
Google предпринимает аналогичные шаги, описанные ранее (включая кодирование стирания и проверку согласованности), для защиты ключей шифрования, находящихся под его контролем.
Лучшая практика: защитите свои ключи шифрования
Выбирая CMEK или CSEK для управления своими ключами, вы получаете прямой контроль над управлением своими собственными ключами. В этих случаях жизненно важно, чтобы вы также защищали свои ключи таким образом, чтобы обеспечить по крайней мере 11 девяток долговечности. Для CSEK это означает поддержание внешних резервных копий ваших ключей, чтобы у вас был путь к восстановлению, даже если ваши ключи каким-либо образом потеряны или повреждены. Если такие меры предосторожности не приняты, стойкость ключей шифрования будет определять надежность данных.
Выход за пределы 11 девяток
Google Cloud очень серьезно относится к защите ваших данных. На практике многочисленные методы, описанные здесь, позволили облачному хранилищу на сегодняшний день увеличить годовой срок службы более 11 девят. Добавьте к этому лучшие практики, которыми мы поделились в этом руководстве, и вы поможете гарантировать, что ваши данные будут здесь, когда они вам понадобятся — будь то сегодня позже или через десятилетия в будущем. Для начала ознакомьтесь с этой обширной коллекцией практических руководств по облачному хранилищу.
