Что такое бэкап сервера
Сравнение способов резервного копирования
Подготовку нового сервера к работе следует начинать с настройки резервного копирования. Все, казалось бы, об этом знают — но порой даже опытные системные администраторы допускают непростительные ошибки. И дело здесь не только в том, что задачу настройки нового сервера нужно решать очень быстро, но еще и в том, что далеко не всегда бывает ясно, какой способ резервного копирования нужно использовать.
Конечно, идеальный способ, который бы всех устраивал, создать невозможно: везде есть свои плюсы и минусы. Но в то же время вполне реальным представляется подобрать способ, максимально подходящий под специфику конкретно проекта.
В этой статье мы расскажем об основных способах резервного копирования серверов под управлением Linux-систем и о наиболее типичных проблемах, с которыми могут столкнуться новички в этой очень важной области системного администрирования.
Схема организации хранения и восстановления из резервных копий
Часто причиной восстановления данных служит повреждение файловой системы или дисков. Т.е. бекапы нужно хранить где-то на отдельном сервере-хранилище. В этом случае проблемой может стать «ширина» канала передачи данных. Если у вас выделенный сервер, то резервное копирование очень желательно выполнять по отдельному сетевому интерфейсу, а не на том же, что выполняет обмен данных с клиентами. Иначе запросы вашего клиента могут не «поместиться» в ограниченный канал связи. Или из-за трафика клиентов бекапы не будут сделаны в срок.
Далее нужно подумать о схеме и времени восстановления данных с точки зрения хранения бекапов. Может быть вас вполне устраивает, что бекап выполняется за 6 часов ночью на хранилище с ограниченной скоростью доступа, однако восстановление длиной в 6 часов вас вряд ли устроит. Значит доступ к резервным копиям должен быть удобным и данные должны копироваться достаточно быстро. Так, например, восстановление 1Тб данных с полосой в 1Гб/с займет почти 3 часа, и это если вы не «упретесь» в производительность дисковой подсистемы в хранилище и сервере. И не забудьте прибавить к этому время обнаружения проблемы, время на решение об откате, время проверки целостности восстановленных данных и объем последующего недовольства клиентов/коллег.
Инкрементальное резервное копирование
При инкрементальном резервном копировании копируются только файлы, которые были изменены со времени предыдущего бэкапа. Последующее инкрементальное резервное копирование добавляет только файлы, которые были изменены с момента предыдущего. В среднем инкрементальное резервное копирование занимает меньше времени, так как копируется меньшее количество файлов. Однако процесс восстановления данных занимает больше времени, так как должны быть восстановлены данные последнего полного резервного копирования, плюс данные всех последующих инкрементальных резервных копирований. При этом в отличие от дифференциального копирования, изменившиеся или новые файлы не замещают старые, а добавляются на носитель независимо.
Инкрементальное копирование чаще всего производится с помощью утилиты rsync. С его помощью можно сэкономить место в хранилище, если количество изменений за день не очень велико. Если измененные файлы имеют большой размер, то они будут скопированы полностью без замены предыдущих версий.
С более подробной информацией о работе rsync можно ознакомиться на официальном сайте.
Для каждого файла rsync выполняет очень большое количество операций. Если файлов на сервере много или если процессор сильно загружен, то скорость резервного копирования будет существенно снижена.
Из опыта можем сказать, что проблемы на SATA-дисках (RAID1) начинаются примерно после 200G данных на сервере. На самом деле всё, конечное же, зависит от количества inode. И в каждом случае эта величина может смещаться как в одну так и в другую сторону.
После определенной черты время выполнения резервного копирования будет очень долгим или попросту не будет отрабатывать за сутки.
Для того, чтобы не сравнивать все файлы, есть lsyncd. Этот демон собирает информацию об изменившихся файлах, т.е. мы уже заранее будем иметь готовый их список для rsync. Следует, однако, учесть, что он дает дополнительную нагрузку на дисковую подсистему.
Дифференциальное резервное копирование
При дифференциальном резервном копировании каждый файл, который был изменен с момента последнего полного резервного копирования, копируется всякий раз заново. Дифференциальное копирование ускоряет процесс восстановления. Все, что вам необходимо — это последняя полная и последняя дифференциальная резервная копия. Популярность дифференциального резервного копирования растет, так как все копии файлов делаются в определенные моменты времени, что, например, очень важно при заражении вирусами.
Дифференциальное резервное копирование осуществляется, например, при помощи такой утилиты, как rdiff-backup. При работе с этой утилитой возникают те же проблемы, что и при инкрементальном резервном копировании.
В целом, если при поиске разницы в данных осуществляется полный перебор файлов, проблемы такого рода резервирования аналогичны проблемам с rsync.
Хотим отдельно отметить, что если в вашей схеме резервного копирования каждый файл копируется отдельно, то стоит удалять/исключать ненужные вам файлы. Например, это могут быть кеши CMS. В таких кешах обычно очень много маленьких файлов, потеря которых не скажется на корректной работе сервера.
Полное резервное копирование
Полное копирование обычно затрагивает всю вашу систему и все файлы. Еженедельное, ежемесячное и ежеквартальное резервное копирование подразумевает создание полной копии всех данных. Обычно оно выполняется по пятницам или в течение выходных, когда копирование большого объёма данных не влияет на работу организации. Последующие резервные копирования, выполняемые с понедельника по четверг до следующего полного копирования, могут быть дифференциальными или инкрементальными, главным образом для того, чтобы сохранить время и место на носителе. Полное резервное копирование следует проводить по крайней мере еженедельно.
В большинстве публикаций по соответствующей тематике рекомендуется полное резервное копирование выполнять один или два раза в неделю, а в остальное время время — использовать инкрементальное и дифференциальное. В таких советах есть свой резон. В большинстве случаев полного резервного копирования раз в неделю вполне достаточно. Выполнять его повторно имеет смысл в том случае, если у вас нет возможности на стороне хранилища актуализировать полный бекап и для обеспечения гарантии корректности резервной копии (это может понадобиться, например, в случаях, если вы по тем или иным причинам не доверяете имеющимся у вас скриптам или софту для резервного копирования.
Рассмотрим их характерные особенности на примере:
Резервировать мы будем только /home. Все остальное можно быстро восстановить вручную. Можно также развернуть сервер системой управления конфигурациями и подключить к нему наш /home.
Полное резервное копирование на уровне файловой системы
Типичный представитель: dump.
Утилита создает «дамп» файловой системы. Можно создавать не только полную, но и инкрементальную резервную копию. dump работает с таблицей inode и «понимает» структуру файлов (так, разреженные файлы сжимаются).
Создавать дамп работающей файловой системы «глупо и опасно», потому что ФС может изменяться во время создания дампа. Его надо создавать со снапшота (чуть позже мы обсудим особенности работы со снапшотами более подробно), отмонтированной или замороженной ФС.
Такая схема так же зависит от количества файлов, и время её выполнения будет расти с ростом количества данных на диске. В то же время у dump скорость работы выше, чем у rsync.
В случае, если требуется возобновить не резервную копию целиком, а, например, только пару случайно испорченных файлов), извлечение таких файлов утилитой restore может занять слишком много времени
Полное резервное копирование на уровне устройств
Например, с одним MySQL это будет выглядеть так:
* Коллеги рассказывают истории как у кого-то «read lock» иногда приводил к дедлокам, но на моей памяти такого не было ни разу.
Далее можно копировать снапшот в хранилище. Главное — следить за тем, чтобы во время копирования снапшот не самоуничтожился и не забывать, что при создании снапшота скорость записи упадет в разы.
Бекапы СУБД можно создать отдельно (например, используя бинарные логи), устранив тем самым простой на время сброса кеша. А можно создавать дампы в хранилище, запустив там инстанс СУБД. Резервное копирование разных СУБД — это тема для отдельных публикаций.
Копировать снапшот можно с использованием докачки (например, rsync с патчем для копирования блочных устройств bugzilla.redhat.com/show_bug.cgi?id=494313), можно по блокам и без шифрования (netcat, ftp). Можно передавать блоки в сжатом виде и монтировать их в хранилище при помощи AVFS, и примонтировать на сервере раздел с бекапами по SMB.
Сжатие устраняет проблемы скорости передачи, забития канала и места в хранилище. Но, однако если вы не используете AVFS в хранилище, то на восстановление только части данных у вас уйдет много времени. Если будете использовать AVFS, то столкнетесь с её «сыростью».
Альтернатива сжатию блоками — squashfs: можно подмонтировать, к примеру, по Samba раздел к серверу и выполнить mksquashfs, но эта утилита так же работает с файлами, т.е. зависит от их количества.
К тому же при создании squashfs тратится достаточно много ОЗУ, что может легко привести к вызову oom-killer.
Безопасность
Необходимо обезопасить себя от ситуации когда хранилище или ваш сервер будут взломаны. Если взломан сервер, то лучше чтобы не было прав на удаление/изменение файлов в хранилище у пользователя, который записывает туда данные.
Если взломано хранилище, то права бекапного пользователя на сервере так же желательно ограничить по максимуму.
Если канал резервного копирования может быть прослушан, то нужны средства шифрования.
Заключение
У каждой системы резервного копирования свои минусы и свои плюсы. В этой статье мы постарались осветить часть нюансов при выборе системы резервного копирования. Надеемся, что они помогут нашим читателям.
В качестве решений по резервному копированию, можно использовать supload и наше облачное хранилище.
Читателей, которые не могут оставлять комментарии здесь, приглашаем к нам в блог.
Что такое «backup»?
Очень часто я слышу фразы вроде «зачем мне бэкап, у меня же есть RAID!». Или «я делаю бэкапы на второй HDD в сервере!». Или что-то подобное. Очень часто через несколько месяцев после этого я слышу вопрос «а как мне восстановить убитые данные?». И это печалит.
В статье я хочу немного порассуждать о том, что такое «резервное копирование» и какая схема такого копирования поможет защититься от потери своих данных. Ну и попытаться обличить некоторые мифы и вредные привычки.
Большинство, думаю, ничего для себя нового не найдет, но если вы все еще относитесь к категории тех, кто бэкапы не делает или делает, но это не бэкапы — добро пожаловать!
Требования?
Давайте определимся с терминологией. Что такое резервная копия?
Логично предположить, что это копия данных, предварительно сохраненная с целью восстановления в случае уничтожения оригинала.
Отсюда вытекает первое требование — изолированность. Не имеет смысла делать копию документов на квартиру и хранить ее там же, где оригинал. Так не имеет смысла делать копию данных и хранить ее на том же диске/в том же сервере, что и оригинал. Логично? Вполне.
Едем дальше. Если мы делаем копию данных, значит, боимся их потерять. Так? Так. Значит, все резервируемые данные для нас ценны. Так? Снова так. Отсюда второе требование — целостность. Не смысла в копировании без проверки целостности — на выходе мы вполне можем получить битые данные или потерять часть безвозвратно.
Ну и хватит, наверное. Статья ориентирована на SOHO-пользователей, а не на энтерпрайз, поэтому требования к безопасности, скорости disaster recovery, ограниченной избыточности и прочему мы рассматривать не будем.
И что в итоге?
В итоге мы получили три требования, которым должна соответствовать система резервного копирования для того, чтобы носить это гордое имя и надежно хранить ваши данные. Изолированность защитит от сбоя оборудования или внешних факторов (пожара, потопа и т.д.), а также злонамеренного удаления данных (не позволит злоумышленнику или вирусу заразить/удалить и бэкап тоже), контроль целостности гарантирует, что зарезервированы все ваши данные и вы не останетесь у разбитого корыта при утрате основного экземпляра, узнав о проблемах слишком поздно, версионированность не даст бэкап-системе переместить пулю из ноги пользователя, который прострелил себе колено — ему же в голову.
Ближе к практике.
Анализируя существующую или придумывая для себя новую СРК — подумайте, соответствует ли она критериям, изложенным выше?
Пересекаются ли в одном месте основная и резервная копия? Обеспечивается ли при этом изолированность резервной? Существует ли возможность одновременно изменять файлы в основном и резервном хранилище? Существует ли значительная (более значительная, чем атомный взрыв) вероятность того, что оба носителя будут одновременно уничтожены или утеряны? Если ответ на любой из этих вопросов «да» — в системе есть ошибка. К примеру, если вы сделали бэкап файлов с ноутбука на usb flash и убрали ее в сейф — вы молодец. Если вы сделали этот бэкап и положили флешку в сумку к ноутбуку — вы не сделали бэкап.
Обеспечивает ли ваша схема целостность данных? К примеру, если на резервном носителе закончится место и копия не сможет корректно сохраниться — вы об этом узнаете?
Обеспечивает ли она полноту? Если это приложение — сохранены ли настройки, если база данных — схема и т.д.?
Можно ли из существующей копии получить работающий оригинал? Или чего-то не хватает?
Представляете ли вы себе, что будете делать, если потеряете основные данные? Есть ли (пусть простейшая) методика восстановления? Все ли ее пункты выполнимы и достаточны для получения данных? Практике известны примеры, когда бэкап делался на зашифрованный HDD, а сложный и безопасный ключ шифрования хранился не в голове у владельца и даже не на желтой бумажке, а… да-да, на том ноутбуке, откуда и делался бэкап. Как вы понимаете, при краже ноутбука данные были утрачены безвозвратно.
Проведите «учения» — представьте, что основной носитель утрачен и попытайтесь восстановиться. Уверен, с первого раза у вас ничего не выйдет, или выяснится, что многое на самом деле не совсем так, как вы представляли ранее.
Ответили? Провели? Все прекрасно? Нет, не совсем. Не забывайте о СРК. Поддерживайте ее в актуальном состоянии. Начали использовать новое ПО? Внесите его каталоги в список на бэкап. Подумайте, как его восстанавливать. Следите за состоянием резервного носителя (если это одиночный диск, флешка или NAS — он совсем не вечный). Думайте о своих данных, кроме вас этого не сделает никто.
Мифы и примеры плохих решений
Утилиты вроде dropbox тоже для бэкапа мало годятся — если, конечно, не предусмотрена версионируемость. Случайно испортив данные в основной копии вы потеряете и резервную, едва между ними синхронизируются изменения. Данные будет уже не вернуть.
Вместо заключения
Берегите свои данные, потратив 15 минут «до» — можно сэкономить 15 часов «после». Не забывайте бородатый анекдот про тех, кто не делает бэкапы и тех, кто их уже делает.
Резервное копирование: где, как и зачем?
Защита данных предполагает наличие бэкапа — резервных копий, из которых можно выполнить их восстановление. Для большинства компаний и организаций резервное копирование данных относится к числу наиболее важных приоритетов. Около половины компаний работают со своими данными как со стратегическим активом. И ценность хранимых данных постоянно растет. Их используют для повышения качества обслуживания клиентов, поддержки текущей деятельности, исследований и разработок, учета, они задействованы в системах автоматизации, интернета вещей, искусственного интеллекта и др. Поэтому задача защиты данных от аппаратных сбоев, человеческих ошибок, вирусов и кибератак становится крайне актуальной.
В мире наблюдается рост киберпреступности. В прошлом году более 70% компаний подверглись кибератакам. Компрометация персональных данных клиентов и конфиденциальных файлов может иметь серьёзные последствия и приводить к огромным убыткам.
Вместе с тем появляется культура работы с данными, понимание того, что данные – это ценный ресурс, с помощью которого компания может получать дополнительную прибыль или сокращать издержки, а вместе с этим — и желание обеспечить надежную защиту своих данных.
Вариантов резервирования несколько: локальное или удаленное хранение резервных копий на собственной площадке, облачное хранение или бэкапы у хостинг-провайдеров.
Хранить и защищать
Как показывают результаты опросов, примерно четверть респондентов выполняет резервирование данных ежемесячно, столько же – еженедельно, и более четверти – ежедневно. И это вполне оправдано: в результате такой предусмотрительности почти 70% организаций избежали в минувшем году простоев из-за потери данных. В этом им помогают совершенствующиеся программные инструменты и сервисы.
Согласно исследованию IDC мирового рынка программного обеспечения репликации защиты данных (Data Replication and Protection), его продажи в мире будут расти с 2018 по 2022 годы ежегодно на 4,7% и достигнут 8,7 млрд. долларов. Аналитики DecisionDatabases.com в своем отчете (Global Data Backup Software Market Growth 2019-2024) пришли к выводу, что в ближайшие пять лет среднегодовые темпы роста мирового рынка программного обеспечения резервного копирования данных будут составлять 7,6%, и в 2024 году его объем достигнет 2,456 млрд. долларов против 1,836 млрд. долларов в 2019 году.
В октябре 2019 года Gartner представила «магический квадрант» по программному обеспечению резервного копирования и восстановления ИТ-систем дата-центров. Ведущими вендорами этого ПО стали Commvault, Veeam, Veritas, Dell EMC и IBM.
При этом растет популярность облачного резервного копирования: продажи таких продуктов и сервисов, по прогнозам, будут расти более чем вдвое быстрее рынка программного обеспечения защиты данных в целом. По прогнозу Gartner, уже в этом году до 20% предприятий будут использовать резервное копирование в облако.
По прогнозам Marketintellica, мировой рынок ПО для создания и хранения резервных копий на своей (on premises) и на сторонней площадке (off-site) в ближайшей перспективе будет стабильно расти.
По информации IKS Consulting, в России сегмент «облачное резервное копирование как сервис» (BaaS) увеличивается в среднем на 20% в год. По данным опроса Acronis 2019 года, компании все чаще полагаются именно на облачное резервное копирование: его используют более 48% респондентов, а около 27% предпочитают комбинировать облачное и локальное резервное копирование.
Требования к системам резервного копирования
Тем временем требования к программному обеспечению резервного копирования и восстановления данных меняются. Чтобы успешнее решать задачи защиты данных и оптимизировать расходы, компании готовы приобретать более простые, гибкие и недорогие решения, считают аналитики Gartner. Привычные методы защиты данных не всегда соответствуют новым требованиям.
Системы резервного копирования и восстановления данных должны предусматривать простое развертывание и администрирование, удобное управление процессом резервирования и восстановления, оперативное восстановление данных. Современные решения нередко реализуют функции репликации данных, позволяют автоматизировать операции, предусматривают интеграцию с облаками, встроенные функции архивирования, поддерживают аппаратные снимки данных.
По прогнозу Gartner, в ближайшие два года до 40% компаний перейдут на новые решения резервного копирования, заменив имеющееся ПО, а многие будут использовать одновременно несколько продуктов или сервисов, оптимально защищающих те или иные системы. Чем же их не устраивают прежние решения резервного копирования и восстановления данных?
Все в одном
Аналитики полагают, что в результате такого перехода компании получают более гибкие, масштабируемые, простые и производительные системы, нередко представляющие собой унифицированное программное обеспечения для управления данными и их хранения. Усовершенствованные продукты резервного копирования и восстановления включают в себя инструменты эффективного управления данными, дают возможность перемещать данные туда, где их хранение наиболее эффективно (в том числе автоматически), управлять ими, защищать и восстанавливать.
С ростом разнообразия и объемов данных важным требованием становится комплексная защита и управление данными: файлами, базами данных, данными виртуальных и облачных сред, приложений, а также доступ к различным типам данных в первичных, вторичных и облачных хранилищах.
Комплексные решения управления данными обеспечивают единое управление ими в масштабе всей ИТ-инфраструктуры: их резервное копирование, восстановление, архивирование и управления моментальными снимками. Однако администраторы должны четко понимать, где, как долго и какие данные хранятся, какие к ним применяются политики. Быстрое восстановление приложений, виртуальных машин и рабочих нагрузок из локального или облачного хранилища данных минимизирует простои, а автоматизация позволяет свести к минимуму ошибки из-за человеческого фактора.
Крупные организации с комбинацией унаследованных, традиционных и современных приложений нередко выбирают системы резервного копирования, поддерживающие широкий спектр операционных систем, приложений, гипервизоров и реляционных баз данных, обладающие высокой масштабируемостью (до нескольких петабайт и тысяч клиентов), а также предусматривающих интеграцию с широким спектром систем хранения данных, публичных, частных и гибридных облаков и ленточных накопителей.
Как правило, это платформы с традиционной трехуровневой архитектурой из агентов, медиа-серверов и сервера управления. Они могут объединять функции резервного копирования и восстановления, архивирования, аварийного восстановления (DR) и облачного резервного копирования, оптимизировать производительность, используя алгоритмы искусственного интеллекта и машинного обучения.
Как считают в компании Forrester, централизованное управление источниками данных, политиками, способность к надежному восстановлению данных и безопасность являются наиболее важными характеристиками решений резервного копирования.
Современные решения могут с любой периодичностью выполнять резервное копирование виртуальных машин на основе моментальных снимков практически без снижения производительности рабочих сред. Они ликвидируют разрыв между целевой точкой восстановления (Recovery Point Objective, RPO) и целевым временем восстановления (Recovery Time Objective, RTO), гарантируют доступность данных в любое время и обеспечивают непрерывность бизнеса.
Рост объемов данных
Тем временем в мире продолжается экспоненциальный рост объема создаваемых данных, и в ближайшие годы эта тенденция сохранится. По прогнозу IDC, объем создаваемых за год данных вырастет с 2018 до 2025 годы с 33 до 175 ЗБ. Среднегодовые темпы роста превысят 27%. На этот рост влияет и увеличение числа пользователей интернета. В прошлом году интернетом пользовались 53% населения Земли. Число пользователей интернета ежегодно увеличивается на 15-20%. Новые и развивающиеся технологии, такие как 5G, видео UHD, аналитика, IoT, искусственный интеллект, AR/VR, влекут за собой генерацию все больших объемов данных. Источниками роста объема данных также являются также развлекательный контент и видео с камер систем видеонаблюдения. Например, рынок хранения видео с камер наблюдения, по прогнозам MarketsandMarkets, будет расти на 22,4% в год и достигнет в этом году 18,28 млрд долларов.
Экспоненциальный рост объемов создаваемых данных.
За последние два-три года объемы корпоративных данных выросли примерно на порядок. Соответственно, усложнилась задача резервного копирования. Емкости хранилищ данных достигают сотен терабайт и продолжают увеличиваться по мере накопления данных. Потеря даже части этих данных может сказаться не только на бизнес-процессах, но и повлиять на репутацию бренда или на лояльность клиентов. Поэтому создание и хранение бэкапов в значительной мере влияет на весь бизнес.
Сориентироваться в предложениях вендоров, предлагающих свои варианты резервного копирования, бывает нелегко. Существуют разные варианты создания и хранения резервных копий, но наиболее популярными являются локальные системы резервного копирования и использования облачных сервисов. Резервное копирование в облако или в ЦОД провайдера обеспечивает надежную защиту данных и минимизирует риски, связанные с программными сбоями, техническими неисправностями оборудования и ошибками сотрудников.
Миграция в облака
Данные можно накапливать и хранить в собственных центрах обработки данных, но при этом придется обеспечить отказоустойчивость, кластеризацию и масштабирование емкости, иметь в штате квалифицированных специалистов по администрированию систем хранения. В этих условиях передача всех подобных вопросов на аутсорсинг провайдеру очень актуальна. Например, при размещении баз данных в ЦОД провайдера или в облаке можно возложить ответственность за хранение, резервирование данных, функционирование баз данных на профессионалов. Провайдер будет нести финансовую ответственность по соглашению об уровне обслуживания. Помимо прочего это позволяет быстро развернуть типовую конфигурацию для решения конкретной задачи, а также обеспечить высокую степень доступности за счёт резервирования вычислительных ресурсов и резервного копирования.
В 2019 году объем мирового рынка облачного резервного копирования составил 1834,3 млн. долл., и ожидается, что к концу 2026 года он достигнет 4229,3 млн. долл. при среднегодовом росте 12,5%.
При этом все больше данных будет храниться не в корпоративных сетях и не на конечных устройствах, а в облаке, причем, согласно IDC, доля данных в публичных облаках вырастет к 2025 году до 42%. Более того, организации переходят к использованию мультиоблачных инфраструктур и гибридных облаков. Такого подхода придерживаются уже 90% европейских компаний.
Облачное резервное копирование представляет собой стратегию резервного копирования данных, которая включает отправку копии данных по сети на сервер за пределами собственной площадки. Обычно это сервер сервис-провайдера, который взимает с клиента плату на основе выделенной емкости, пропускной способности или количестве пользователей.
Широкое внедрение облачных технологий и необходимость управления большими объемами данных способствуют росту популярности облачных решений для резервного копирования. Кроме того, с внедрением облачных решений резервного копирования связывают такие преимущества как простое управление и мониторинг, резервное копирование и восстановление в режиме реального времени, простая интеграция облачного резервного копирования с другими корпоративными приложениями, дедупликация данных и поддержка различных клиентов.
Ключевыми игроками данного рынка аналитики считают компании Acronis, Asigra, Barracuda Networks, Carbonite, Code42 Software, Datto, Druva Software, Efolder, IBM, Iron Mountain и Microsoft.
Мультиоблачные среды
Поставщики систем хранения данных делают все возможное, чтобы их продукты эффективно работали в мультиоблачной среде. Задача — упростить использование данных и перемещать их туда, где они необходимы, а их хранение — наиболее эффективно. Например, они применяют распределенные файловые системы следующего поколения, которые поддерживают единое пространство имен, обеспечивая доступ к данным в разных облачных средах, предлагают общие стратегии и политики управления в разных облаках и на локальном уровне. Конечная цель состоит в управлении, защите и эффективном использовании данных, где бы они ни находились.
Мониторинг — еще одна из проблем мультиоблачного хранения. Нужны инструменты мониторинга для отслеживания результатов в мультиоблачной среде. Независимый инструмент мониторинга, разработанный для нескольких облаков, позволит получить общую картину.
Прогноз роста мирового рынка систем управления мультиоблачными средами.
Совмещение периферийного и мультиоблачного хранения – также непростая задача. Чтобы эти системы эффективно работали вместе, нужно знать объемы и типы данных, где и как эти данные будут собираться, передаваться и сохраняться. Для планирования процесса потребуется также знать, как долго должны храниться данные каждого типа, где, когда и сколько данных нужно будет передавать между различными системами и облачными платформами, как осуществляется их резервное копирование и защита.
Все это поможет администраторам свести к минимуму сложности, связанные с объединением периферийного и мультиоблачного хранения.
Данные на периферии
Еще один тренд – периферийные вычисления. Как считают аналитики Gartner, в ближайшие годы около половины всех корпоративных данных будут обрабатываться за пределами традиционных ЦОД или облачной среды: все более значительная их доля размещается на периферии — для хранения и локальной аналитики. По прогнозу IDC, в регионе EMEA доля «периферийных» данных вырастет почти вдвое — с 11% до 21% от общего объема. Причины — распространение интернета вещей, перенос аналитики и обработки данных ближе к их источнику.
Переход от облачных и централизованных вычислений к периферийным вычислениям уже начался. Такие системы становятся все более востребованными. Затраты и сложность создания централизованной архитектуры для обработки большого объема данных чрезмерно велики, такая система может стать плохо управляемой по сравнению с распределением обработки данных по периферии или на соответствующем уровне сети. Кроме того, на периферии можно объединять или деперсонализировать данные перед отправкой в облако.
Данные за границей
Некоторые компании предпочитают хранить данные за рубежом, считая такой вариант надежной защитой данных от несанкционированного доступа и важным фактором снижения риска. Данные за границей – это гарантия защиты ценной информации. Размещенное за рубежом оборудование не находится под российской юрисдикцией. А благодаря шифрованию сотрудники ЦОД могут вообще не иметь доступа к вашим данным. В современных зарубежных дата-центрах используется высоконадежное оборудование, обеспечиваются высокие показатели надежности на уровне ЦОД в целом.
Использование иностранных ЦОД может иметь и ряд других преимуществ. Клиент застрахован от рисков, связанных с форс-мажорами или недобросовестной конкуренцией. Использование таких площадок для хранения и обработки данных позволит минимизировать подобные риски. Например, в случае изъятия серверов в России компания сможет сохранить копию своих систем и данных в зарубежных ЦОД.
Как правило, ИТ-инфраструктура зарубежных ЦОД – это стандарты качества, высокий уровень безопасности и контроля хранения данных. В них используются новейшие ИТ-решения, межсетевые экраны, технологии шифрования каналов связи, средства защиты от DDoS-атак. Энергообеспечение ЦОД также реализовано с высоким уровнем надежности (до TIER III и IV).
Резервное копирование в зарубежных ЦОД актуально для любого бизнеса в РФ, не работающего с персональными данными пользователей, хранение и обработка которых, согласно закону № 152-ФЗ «О персональных данных», должна осуществляться на территории России. Эти требования можно выполнить путем развертывания двух площадок: основной в России, где происходит первичная обработка данных, и зарубежной, где размещаются резервные копии.
Зарубежные площадки нередко используют и в качестве резервного ЦОД. Тем самым достигается максимальная безопасность и надежность, минимизируются риски. В ряде случаев они удобны для размещения данных и подключения к ним европейских клиентов. При этом достигается лучшее время отклика для европейских пользователей. Такие дата-центры имеют прямой доступ к европейским точкам обмена трафиком. Мы например предлагаем своим клиентам сразу 4 точки размещения данных в Европе — это Цюрих (Швейцария), Франкфурт (Германия), Лондон (Великобритания) и Амстердам (Нидерланды).
Что нужно учитывать при выборе дата-центра?
Используя услуги коммерческих ЦОД, помимо удобной структуры расходов, бизнес получает более гибкий сервис, который можно масштабировать в режиме реального времени, а оплачиваются только потребляемые ресурсы (pay-per-use). Услуги внешнего ЦОД также позволяют снизить риски, связанные с неопределенностью будущего, легко адаптировать ИТ к новым технологическим трендам, сосредоточиться на своих ключевых бизнес-процессах, а не на обслуживании ИТ-инфраструктуры.
Провайдеры учитывают при строительстве и эксплуатации своих площадок лучшие практики и международные стандарты, предъявляющие высокие требования к инженерным и ИТ-системам ЦОД, такие как ISO 27001:2013 Information Security Management (управление информационной безопасностью), ISO 50001:2011 Energy Management System (эффективное планирование систем энергоснабжения дата-центра), ISO 22301:2012 Business Continuity Management System (обеспечение непрерывности бизнес-процессов ЦОД), а также европейские стандарты EN 50600-x, стандарт PCI DSS, касающийся безопасности обработки и хранения данных пластиковых карт международных платежных систем.
В результате заказчик получает отказоустойчивый сервис, обеспечивающий надежный надежное хранение данных и непрерывность бизнес-процессов.