В этой статье я собираюсь обсудить доступность данных, сохраненных в облаках. Вторым (и наиболее интересным) пунктом программы выступает приватность и защищенность этих данных.
Хочу заметить сразу, в этой части я пишу скорее о теоретической части вопроса, чем о практической. Предположим, пользователь собирается настроить бэкап своих данных в облаке. Какие потенциальными проблемы при этом могут возникнуть и как их избежать? Для начала стоит повторить очевидное: а для чего пользователь захочет использовать такой вид бэкапа данных?
Во-первых, облачные провайдеры обещают высокую доступность данных (дальше в тексте я буду иногда называть это availability). Во-вторых подразумевается, что данные, даже если они будут недоступны в текущий момент, все еще где-то сохранены, и доступ к ним появится позже. Эта характеристика именуется durability.
Дополнительное немаловажное преимущество заключается в том, что сохраненные данные будут доступны с любой точки мира, был бы нормальный доступ в Интернет.
Итак, три основных рекламируемых преимущества:
К сожалению, мы не живем в идеальном мире. Все, даже самые замечательные, технические средства и усилия, применяемые провайдерами для обеспечения надежности и доступности данных, могут быть легко сведены на нет. Причины могут самые разнообразные, но вероятность их появления очень даже немала. Различные ошибки в софте, проблемы с партией закупленных железок, элементарные человеческие ошибки персонала могут привести к тому, что данные будут недоступны в течение недопустимо большого количества времени (т.е. пострадает availability). И это еще цветочки, потому что полное удаление данных – тоже возможно (в данном случае страдает durability).
Чтобы не быть голословной, приведу несколько примеров происшествий последних лет. Начнем с доступности. Всем известный Amazon S3 – это сервис с заявленной доступностью «three nines», что означает, сервис может быть offline в течение не более чем 10-ти минут в неделю. Два серьезных outage у них случилось в 2008 году. В июне сервис был недоступен в течение 8 часов. В феврале проблемы с доступом длились примерно 3 часа. И это не единственные случаи. Тот же сервис был в оффлайне в последний раз уже в прошлом 2011 году. Отсутствие доступа к облачному сервису FlexiScale продолжалось вообще несколько дней. Кстати, его причиной как раз была ошибка сотрудника. Он случайно удалил одно из хранилищ данных. К счастью пользователей FlexiScale, данные были впоследствии восстановлены.
Пользователи Carbonite cloud storage оказались не столь удачливыми. В 2009 году оператором были потеряны данные многих клиентов. Carbonite в инциденте обвинила поставщиков железа. Так это или нет, для нас не столь важно. Важен сам факт потери. Провайдер Linkup вообще перестал существовать после того как потерял данные большинства своих клиентов.
Кстати то, что провайдер просто может перестать существовать вместе с Вашими данными, это тоже еще одна потенциальна угроза. Особенно если данные нужно хранить в течение очень долгого срока.
В чем же основной источник описанных проблем? В том что используется один единственный провайдер. Конечно, очень хорошо иметь redundancy на уровне серверов, используемых провайдером. И на уровне данных, сохраняемых в нескольких экземплярах. Однако то факт, что облако управляется одним оператором, одним типом софта и, наверняка, управляется централизованно может свести на нет все выше означенные меры.
Ответ очевиден. Если доступность данных, да и их выживаемость не столь важна, не беспокоиться. Или сохранять еще одну копию данных локально.
Если же:
стоит использовать несколько облачных хранилищ данных одновременно. Примерно как на завлекательной картинке к этому посту.
Для этого необходимо для этого необходимо использовать избыточность данных, i.e. redundant data.
Самый простой способ это сделать – это использовать репликацию данных.
Несмотря на свою простоту и традиционность, этот метод имеет ряд существенных недостатков. Первый заключается в том, что слишком много места занимается на серверах. Второй – в том, что слишком большой объем трафика расходуется на сохранение данных. А именно сохранение данных на серверах (и их обновление), составляют самую частую операцию при бэкапе данных.
К счастью, существуют иные подходы, позволяющие сэкономить и на занятом дисковом пространстве и на трафике, не снижая при этом уровень доступности данных.
О них я подробно напишу в следующей части. Третья часть будет посвящена вопросам безопасности.
Хочу заметить сразу, в этой части я пишу скорее о теоретической части вопроса, чем о практической. Предположим, пользователь собирается настроить бэкап своих данных в облаке. Какие потенциальными проблемы при этом могут возникнуть и как их избежать? Для начала стоит повторить очевидное: а для чего пользователь захочет использовать такой вид бэкапа данных?
Мотивация
Во-первых, облачные провайдеры обещают высокую доступность данных (дальше в тексте я буду иногда называть это availability). Во-вторых подразумевается, что данные, даже если они будут недоступны в текущий момент, все еще где-то сохранены, и доступ к ним появится позже. Эта характеристика именуется durability.
Дополнительное немаловажное преимущество заключается в том, что сохраненные данные будут доступны с любой точки мира, был бы нормальный доступ в Интернет.
Итак, три основных рекламируемых преимущества:
- Высокая availability
- Высокая durability
- Flexibility: доступ к данным из любой точки мира с подключением к Интернету
Действительно ли заявленные свойства соответствуют действительности?
К сожалению, мы не живем в идеальном мире. Все, даже самые замечательные, технические средства и усилия, применяемые провайдерами для обеспечения надежности и доступности данных, могут быть легко сведены на нет. Причины могут самые разнообразные, но вероятность их появления очень даже немала. Различные ошибки в софте, проблемы с партией закупленных железок, элементарные человеческие ошибки персонала могут привести к тому, что данные будут недоступны в течение недопустимо большого количества времени (т.е. пострадает availability). И это еще цветочки, потому что полное удаление данных – тоже возможно (в данном случае страдает durability).
Чтобы не быть голословной, приведу несколько примеров происшествий последних лет. Начнем с доступности. Всем известный Amazon S3 – это сервис с заявленной доступностью «three nines», что означает, сервис может быть offline в течение не более чем 10-ти минут в неделю. Два серьезных outage у них случилось в 2008 году. В июне сервис был недоступен в течение 8 часов. В феврале проблемы с доступом длились примерно 3 часа. И это не единственные случаи. Тот же сервис был в оффлайне в последний раз уже в прошлом 2011 году. Отсутствие доступа к облачному сервису FlexiScale продолжалось вообще несколько дней. Кстати, его причиной как раз была ошибка сотрудника. Он случайно удалил одно из хранилищ данных. К счастью пользователей FlexiScale, данные были впоследствии восстановлены.
Пользователи Carbonite cloud storage оказались не столь удачливыми. В 2009 году оператором были потеряны данные многих клиентов. Carbonite в инциденте обвинила поставщиков железа. Так это или нет, для нас не столь важно. Важен сам факт потери. Провайдер Linkup вообще перестал существовать после того как потерял данные большинства своих клиентов.
Кстати то, что провайдер просто может перестать существовать вместе с Вашими данными, это тоже еще одна потенциальна угроза. Особенно если данные нужно хранить в течение очень долгого срока.
Причина
В чем же основной источник описанных проблем? В том что используется один единственный провайдер. Конечно, очень хорошо иметь redundancy на уровне серверов, используемых провайдером. И на уровне данных, сохраняемых в нескольких экземплярах. Однако то факт, что облако управляется одним оператором, одним типом софта и, наверняка, управляется централизованно может свести на нет все выше означенные меры.
Что делать?
Ответ очевиден. Если доступность данных, да и их выживаемость не столь важна, не беспокоиться. Или сохранять еще одну копию данных локально.
Если же:
- данные хочется хранить в течение очень долгого срока
- нет возможности их хранить еще и локально
- по любой иной причине нужно хранить данные именно в сети,
стоит использовать несколько облачных хранилищ данных одновременно. Примерно как на завлекательной картинке к этому посту.
Для этого необходимо для этого необходимо использовать избыточность данных, i.e. redundant data.
Самый простой способ это сделать – это использовать репликацию данных.
Несмотря на свою простоту и традиционность, этот метод имеет ряд существенных недостатков. Первый заключается в том, что слишком много места занимается на серверах. Второй – в том, что слишком большой объем трафика расходуется на сохранение данных. А именно сохранение данных на серверах (и их обновление), составляют самую частую операцию при бэкапе данных.
К счастью, существуют иные подходы, позволяющие сэкономить и на занятом дисковом пространстве и на трафике, не снижая при этом уровень доступности данных.
О них я подробно напишу в следующей части. Третья часть будет посвящена вопросам безопасности.
