Друзья, спасибо вам за комментарии, мы учли ваш интерес к хранилищу резервных копий и продолжаем раскрывать всем известную и наболевшую тему бэкапов.
Бэкап данных часто воспринимается администраторами как классическая ИТ-задача, в которой нет места экспериментам. Считается, что достаточно выбрать одно из проверенных решений и внедрить его. Однако на практике традиционные схемы резервного копирования становятся всё более дорогими и менее удобными. Вдобавок, увеличение объёма закономерно приводит к снижению надёжности. Поэтому постоянно разрабатываются новые системы бэкапа, более подходящие для современного оборудования и специфических бизнес-задач.
Системы резервного копирования отличаются не только доступными схемами и скоростью работы, но и концептуально – на уровне их архитектуры. Классические варианты рассчитаны на выделенные СХД с одноуровневой структурой. Это обособленные ленточные библиотеки или массивы дисков, которые используется только для хранения бэкапов. Согласно выбранному графику на них периодически записываются новые данные из продуктивной системы, в которой непосредственно работают сотрудники.
Сегодня одноуровневые СХД уже не удовлетворяют критериям доступности данных. По мере усложнения продуктивной системы и увеличения её объёма, возрастает как время создания бэкапов, так и восстановлениях из них. В какой-то момент оно становится неприемлемо высоким, и бизнес несёт убытки.
Основная проблема состоит в том, что одноуровневые хранилища перестают справляться с большой интенсивностью дисковых операций (IOPS) или слишком медленно обрабатывают данные. Например, к повреждённой БД в продуктиве может сформироваться очередь из тысяч запросов. Базу нужно срочно реанимировать, а время её восстановления из полной копии займёт несколько часов.
Решением проблемы низкой доступности резервных копий стали трёхуровневые системы хранения данных. Они позволяют разделить бэкапы по их текущей актуальности и обеспечивают сокращение времени их восстановления в разы.
На первом уровне таких СХД работают самые быстрые накопители небольшого объёма, например – SSD корпоративного класса. При заоблачной цене и относительно малой ёмкости они обладают на порядки более высоким показателем IOPS и рекордными скоростями чтения/записи. Это идеально подходит для операционных данных, которые может понадобиться восстановить прямо сейчас. Обычно таких данных в компании менее 5%, поэтому объём первого слоя выбирается минимально достаточным.
На втором уровне гибридной СХД обычно размещают быстрые (по меркам HDD) и относительно ёмкие SAS-диски в качестве промежуточного решения. Это компромисс между скоростью, объёмом и ценой. На них хранится значительная часть данных, которые может потребоваться восстановить в ближайшей перспективе.
Завершающим слоем, как правило, становится массив из дисков Nearline-SAS. У них большая ёмкость и демократичная цена, но очень низкая скорость работы. Поэтому они подходят для долговременного хранения тех копий данных, которые вряд ли понадобится восстанавливать в ближайшее время. Например, для уже выполненных проектов.
Каждый последующий слой трёхуровневой СХД обеспечивает удешевление хранения данных ценой увеличения времени их восстановления. Если из первого слоя их можно получить буквально за считанные минуты, то разворачивание бэкапа из третьего слоя может занять часы и даже дни. Поэтому важно корректно рассчитать конфигурацию гибридной СХД и применять дополнительные методы повышения доступности данных.
Гибридную СХД можно купить как готовую систему от известного вендора или даже создать самостоятельно на базе подходящих комплектующих и разработок с открытым исходным кодом. Однако со временем у фирменной СХД возникнут сложности с масштабированием, а у самодельной всегда будут сложности с обслуживанием другими специалистами.
Существует ещё один концептуально новый подход, смягчающий недостатки гибридной СХД при сохранении её ключевых преимуществ. Он сводится к переносу на уровень ПО ключевых функций управления и обслуживания систем резервного копирования. Ту же трёхуровневую схему хранения бэкапов можно реализовать средствами Acronis Backup Advanced. Входящий в состав дистрибутива узел хранения Acronis может автоматически перемещать резервные копии между различными носителями. К примеру, если развернуть узел хранения Acronis на Windows Server с RAID-массивом SSD, дисками и ленточной библиотекой, он будет перемещать бэкапы между этими устройствами по заданному расписанию.
Acronis Storage также позволяет организовать современное трёхуровневое хранение бэкапов без необходимости приобретать дорогостоящую СХД. С его помощью можно быстро развернуть систему хранения данных с использованием любых HDD и SSD. Наращивать её объём можно просто добавляя накопители любого типа и ёмкости. Вся настройка, управление и мониторинг состояния выполняются через простой веб-интерфейс. Внедрение и обслуживание Acronis Storage не требуют от администратора глубоких познаний.
В такой системе бэкапы автоматически перемещаются по расписанию между устройствами хранения с разными скоростными показателями. Даже в пределах одного сервера резервного копирования они могут перемещаться между дисками с разным интерфейсом и скоростью вращения.
Компания Acronis использует данное решение для организации собственного облачного хранилища резервных копий и успешно опробовала его на объёмах в несколько петабайт в трёх центрах обработки данных.
Выводы:
1. Традиционные одноуровневые системы хранения бэкапов редко соответствуют современным критериям доступности данных.
2. Гибридные СХД используют трёхуровневое хранение бэкапов, разделяя их по приоритету и обеспечивая высокую скорость восстановления данных.
3. С помощью программных решений можно удешевить трёхуровневое хранение резервных копий и упростить их обслуживание.
4. Acronis Storage избавляет от необходимости приобретать дорогую СХД и упрощает её масштабирование вплоть до петабайтных объёмов.
Хотите получить больше информации?
» Регистрируйтесь на вебинары по бэкапу и защите данных
» Скачайте демоверсию для бэкапа корпоративных серверов Acronis Backup Advanced
Не ленитесь, Друзья, делайте бэкапы вовремя!
ссылка на оригинал статьи https://habrahabr.ru/post/317016/
Добавить комментарий