О Чем Стоит Задуматься, Сохраняя Свои Данные в Облаке. Часть 1

    В этой статье я собираюсь обсудить доступность данных, сохраненных в облаках. Вторым (и наиболее интересным) пунктом программы выступает приватность и защищенность этих данных.




    Хочу заметить сразу, в этой части я пишу скорее о теоретической части вопроса, чем о практической. Предположим, пользователь собирается настроить бэкап своих данных в облаке. Какие потенциальными проблемы при этом могут возникнуть и как их избежать? Для начала стоит повторить очевидное: а для чего пользователь захочет использовать такой вид бэкапа данных?

    Мотивация


    Во-первых, облачные провайдеры обещают высокую доступность данных (дальше в тексте я буду иногда называть это 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.
    Самый простой способ это сделать – это использовать репликацию данных.

    Несмотря на свою простоту и традиционность, этот метод имеет ряд существенных недостатков. Первый заключается в том, что слишком много места занимается на серверах. Второй – в том, что слишком большой объем трафика расходуется на сохранение данных. А именно сохранение данных на серверах (и их обновление), составляют самую частую операцию при бэкапе данных.

    К счастью, существуют иные подходы, позволяющие сэкономить и на занятом дисковом пространстве и на трафике, не снижая при этом уровень доступности данных.

    О них я подробно напишу в следующей части. Третья часть будет посвящена вопросам безопасности.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 27

      –4
      Я По Старинке На Болванки Катаю
        +8
        А это действительно кардинально меняет смысл, если вместо «доступность», «надежность» и «гибкость» использовать «availability», «durability» и «flexibility»? Т.е. вы правда думаете, что так понятнее?
          –1
          Да весь текст какой-то… SEO-шный.
            0
            Поддерживаю.
            Во-первых, облачные провайдеры обещают высокую доступность данных (дальше в тексте я буду иногда называть это availability).
            <...>
            Дополнительное немаловажное преимущество заключается в том, что сохраненные данные будут доступны с любой точки мира, был бы нормальный доступ в Интернет.

            Итак, три основных рекламируемых преимущества:

            Высокая availability
            Высокая durability
            Flexibility: доступ к данным из любой точки мира с подключением к Интернету

            К сожалению, из такого текста сложно понять, чем же отличается availability (временная доступность, то есть сервис должен работать в любой момент времени), и flexibility (пространственная доступность, то есть доступ к данным из любой точки, и, возможно, с разных устройств.

            Еще я не очень понимаю смысл вставлять англоязычные термины посреди фразы, вроде

            что означает, сервис может быть offline в течение не более чем 10-ти минут в неделю. Два серьезных outage у них случилось в 2008 году.


            По сути статьи. Правильно ли я понял, что вы считайте, что хранение данных в облаке — в целом менее безопасный способ, чем хранение их, например, дома на запасном жестком диске?
              0
              «К сожалению, из такого текста сложно понять, чем же отличается availability (временная доступность, то есть сервис должен работать в любой момент времени), и flexibility (пространственная доступность, то есть доступ к данным из любой точки, и, возможно, с разных устройств. » — именно по этому причине я привела английские варианты терминов с устоявшимися значениями.

              «По сути статьи. Правильно ли я понял, что вы считайте, что хранение данных в облаке — в целом менее безопасный способ, чем хранение их, например, дома на запасном жестком диске? » — смотря что вы имеете ввиду под безопасностью? Если речь идет о том что данные выживут, будут доступны, то ответ будет один. Если речнь идет о конфиденциальности данных, то ответ будет совершенно иным.
                0
                В данном случае я имел ввиду именно их доступность и физическую сохранность.

                Я не думаю, что большая часть пользователей согласится хранить свою конфиденциальную информацию в облаке, причем проблема тут даже не в степени защищенности этих данных, а в психологическом моменте. Мне кажется, что облако лучше всего подходит именно для такой информации, которая не является слишком личной, но к которой нужно иметь доступ из разных мест. В качестве примера приходит на ум риэлтор, который может хранить таким образом данные о недвижимости, которые не являются чем-то сверхсекретным, но должны быть доступны ему в любое время.
                  0
                  Я думаю что стоит отделить апельсины от яблок)

                  Одно — это технический аспект. Другое — психологический, восприятие пользователей.

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

                  Насчет конфиденциальности данных, как я уже упоминула, я писать собираюсь в третьей части.

                  Насчет психологического аспекта. Я не считаю что вы правы, хотя бы потому что облачные хранилища нацеленные на обычных пользователей живут и процветают и число их только множится. К тому же, восприятие людей меняется с изменением технологий. Нам рефлекторно страшнее летать, чем ездить на поезде. Но самолетами от этого пользоваться еще никто не перестал.
                    0
                    Ну лично я не стал бы хранить в облаке детализацию банковского счета или что-то еще в этом роде, хотя может быть это просто я такой параноик.
                      0
                      ммм, скажем так, все зависит от того, насколько большая существует необходимость того, чтобы данные не оказались потерянными. Тоесть, существуют случаи, когда, действительно, плевать на то, пропадут данные или нет, главное чтобы они не попали в третьи руки.

                      Однако, есть ситуации, когда необходимо искать компромис. Я задачу технического специалиста вижу именно в том, чтобы предоставить возможность такого компромисса, сохраняя безопасность данных на максимально достижимом и разумном уровне.

                      Я как раз хотела обсудить, как обезопасить себя и свои данные, когда отсылаешь их в облако. Ведь, по сути, отдавая данные облачному провайдеру, мы теряем контроль не только над самими данными, но и над их жизненным циклом. К примеру, как гарантировать то, что если пользователь захотел удалить данные, они на самом деле будут удалены.
                        0
                        Как вариант свой личный AES-256 с помощью программы BoxCryptor?
              +1
              Есть устоявшиеся термины, которые используются в международном сообществе. Я считаю что полезно всегда иметь возможно использовать такие тремины взаимозаменяемо с локальными аналогами.
                +2
                Я не против английского, если нет адекватных аналогов в русском языке. В данном случае это не так. Статья написана на русском языке для русскоговорящих людей и обилие совершенно не к месту употребленных английских слов режет глаза и только мешает. Тем более что указанные мной термины являются точно также устоявшимися в русскоговорящем сообществе, для которого вы эту статью и написали. Все хорошо в меру и к месту.
                  0
                  Хм, ну возможно дело в том, что я уже несколько лет за рубежом и вращаюсь в кругах, где собираются люди со всего мира. Я привыкла употреблять англиские термины, дабы быть уверенной что все понимают, о чем идет речь. Русские же термины для меня малознакмы.
                    0
                    Это многое объясняет :) Чувствуется, что статься написана как будто иностранцем.
                      0
                      >Русские же термины для меня малознакмы.
                      ну так как вы пишете статью на русском, то неплохо было бы для начала погуглить перевод этих терминов.
                        0
                        вы не видитечто-ли, что аналоги терминов я привожу? И что термины я использую взаимозаменяемо.
                          0
                          На мой взгляд, термины недостаточно чётко разъяснены.
                          Например объяснение Singerofthefall намного лучше.
                          Думаю, вам стоит отредактировать статью с учётом коментариев.
                    –1
                    Написали бы тогда на английском.
                    Всегда можно найти правильные и емкие эквиваленты в русском языке.
                    +1
                    В ваших словах безусловно есть разумное основание, но не откланяйтесь от темы, это не форум русского языка и литературы или стилистки\правил итп. Подобного рода замечания как правило сводят общение к софистике и уводят за пределы обсуждаемой тематики. Человек вполне корректно обозначил терминологию, заранее дал определения (я имею ввиду метод). Да, есть аналоги в русском языке. Да, они и мне кажутся более уместными здесь. Но неужели кто-то тут не разобрал смысл, который вкладывал автор! Можно же проявить понимание и, наконец, осознать, что здесь это мелочь, которую можно простить человеку. Какую цель вы преследуете делая замечания подобного рода? Что это дает всем тут? Зачастую, человек пишет про «облачные сервисы хранения данных\или еще что-нибудь» — куча комментов о правописании\орфографии\пуктуации — втф?!!!
                    Форма подачи информации безусловно важна! Но не в ущерб же семантики.
                    Классика софистики: автор не знает как грамотно писать по-русски -> автор тупой -> автор не прав.
                    И такое почти во всех каментах в каждом посту. Ну достали уже.
                    Если вы настолько озабочены этой проблемой (я не умаляю ее важности), выделите уже отдельный тред\пост на эту тему и расщипляйте там Розенталя. Помните о главном.
                      0
                      Вы выразили мою мысль очень четко. Похоже это любимое развлечение пнуть проходя мимо. После такого, честно говоря желание что-либо писать пропадает совершенно.
                    +1
                    Есть удобный вариант, применяемый в некоторых переводных книгах (чаще всего — материалы для подготовки к разным сертификациям) — использовать русскоязычный термин и сразу же за ним в скобках — англоязычный.
                      0
                      Где же она, эта третья часть статьи, из которой я узнаю как мне хранить мою 300 гиговую помойку, особо не тратя на это место и трафик?!
                        0
                        под хранил конечно же имел в виду бэкапить
                          0
                          Backup — без затрат траффика — имхо фантастика
                          0
                          в третей части я хотела про безопасность данных писать…
                            0
                            Извините, мне почему-то подумалось что следующая часть и будет третьей…
                              0
                              Ну, в общем, насчет «помойки» :) Ее точно хочется сделать очень надежно сохраненной, т.е. позаботиться о высокой доступности этих данных? Потому что в таком случае общий размер пространства на этой нужный будет явно больше 300 гигов. Лишь на каждом из сохраненных облаков он будет небольшим.

                              Тоесть рчеь будет идти как сэкономить на дополнительном пространстве и трафике, которые возникнут из-за избыточных данных.

                        Only users with full accounts can post comments. Log in, please.