Бекап ОГРОМНОГО кол-ва данных
Модераторы: Trinity admin`s, Free-lance moderator`s
-
- Advanced member
- Сообщения: 127
- Зарегистрирован: 08 фев 2006, 18:10
- Откуда: Воронеж
- Контактная информация:
Бекап ОГРОМНОГО кол-ва данных
Имеется в хозяйстве:
Две СХД IBM Storwize V7000
Два сервера, подключенных к этим СХД через FC 8Gbit (каждый к своей хранилке)
Сервера работают в качестве файловых серверов samba, ОС redhat 6.
Каждый сервер подключен к своей хранилке.
Сервер1 имеет 92ТБ раздел.
Сервер2 имеет 92ТБ раздел и 23ТБ раздел.
У всех трех разделов ФС XFS.
Итого общий объем данных, которые нужно бекапить более 200ТБ
Как выполнять резервное копирование такого объема данных и главное какими средствами?
Сейчас резервное копирование выполняется с помощью ленточных библиотек LTO5 и LTO6 и программы bacula(данные пишутся по сети). Практика показала, что такое решение не жизнеспособно по нескольким причинам:
- время полного резервного копирования занимает около 3х недель
- второй пункт вытекает из первого, за 3 недели может случиться что угодно, отключение света, любой другой глюк и т.д. Почти не разу не удавалось записать бекап с первого раза
- не возможно продолжить бекап после прерывания, приходиться запускать заново
- все же ленточные библиотеки не предназначены для таких задач, судя по всему, такие объемы данных для них максимум слить данные в архив, но не бекапить постоянно, т.к. довольно часто ловлю глюки, то с приводами, то с роботом и бекап прерывается
- исходя из вышеперечисленного, в случае необходимости отката из бекапа, потеря составит не менее месяца, что не круто
В общем ищется альтернативное решение, более скоростное, более надежное(без застрявших картиджей в роботе и приводов, которые постоянно требуют чистки). Что можно придумать?
Мой вариант:
Собрать еще один сторвайз на 4ТБ дисках, объемом около 500ТБ, нарезать на куски по 92ТБ и 23ТБ и раздать их серверам(по FC), на них и бекапить. Только возникает вопрос, каким образом на горячую скопировать данные с одного раздела на другой? rsync? dd? тупо cp? или еще как?
В общем подкиньте идей для решения задачи.
Две СХД IBM Storwize V7000
Два сервера, подключенных к этим СХД через FC 8Gbit (каждый к своей хранилке)
Сервера работают в качестве файловых серверов samba, ОС redhat 6.
Каждый сервер подключен к своей хранилке.
Сервер1 имеет 92ТБ раздел.
Сервер2 имеет 92ТБ раздел и 23ТБ раздел.
У всех трех разделов ФС XFS.
Итого общий объем данных, которые нужно бекапить более 200ТБ
Как выполнять резервное копирование такого объема данных и главное какими средствами?
Сейчас резервное копирование выполняется с помощью ленточных библиотек LTO5 и LTO6 и программы bacula(данные пишутся по сети). Практика показала, что такое решение не жизнеспособно по нескольким причинам:
- время полного резервного копирования занимает около 3х недель
- второй пункт вытекает из первого, за 3 недели может случиться что угодно, отключение света, любой другой глюк и т.д. Почти не разу не удавалось записать бекап с первого раза
- не возможно продолжить бекап после прерывания, приходиться запускать заново
- все же ленточные библиотеки не предназначены для таких задач, судя по всему, такие объемы данных для них максимум слить данные в архив, но не бекапить постоянно, т.к. довольно часто ловлю глюки, то с приводами, то с роботом и бекап прерывается
- исходя из вышеперечисленного, в случае необходимости отката из бекапа, потеря составит не менее месяца, что не круто
В общем ищется альтернативное решение, более скоростное, более надежное(без застрявших картиджей в роботе и приводов, которые постоянно требуют чистки). Что можно придумать?
Мой вариант:
Собрать еще один сторвайз на 4ТБ дисках, объемом около 500ТБ, нарезать на куски по 92ТБ и 23ТБ и раздать их серверам(по FC), на них и бекапить. Только возникает вопрос, каким образом на горячую скопировать данные с одного раздела на другой? rsync? dd? тупо cp? или еще как?
В общем подкиньте идей для решения задачи.
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Re: Бекап ОГРОМНОГО кол-ва данных
А смотрели, в чем тормоза?
Наверно логичнее не к каждому серверу цеплять по луну, а снапшоты со сторвайзов монтировать к серверу бэкапа.
А в качестве носителя можно аппарат и попроще - V3700 или даже инфортренд.
Наверно логичнее не к каждому серверу цеплять по луну, а снапшоты со сторвайзов монтировать к серверу бэкапа.
А в качестве носителя можно аппарат и попроще - V3700 или даже инфортренд.
Re: Бекап ОГРОМНОГО кол-ва данных
Бэкапить такие объемы, наверное, бессмысленное занятие. Тут надо иметь избыточное хранилище (failover) для каждого сервера и файловую систему со снапшотами (zfs).
-
- Advanced member
- Сообщения: 127
- Зарегистрирован: 08 фев 2006, 18:10
- Откуда: Воронеж
- Контактная информация:
Re: Бекап ОГРОМНОГО кол-ва данных
Да собственно никаких тормозов и нет, время бекапа вытекает из объема и скорости записи на ленточный накопитель. Да и как я уже говорил, даже если удастся прокачать скорость записи на ленту, все равно с ней куча других проблем, хотелось бы от нее избавиться.gs писал(а):А смотрели, в чем тормоза?
Предлагаете делать снапшет на уровне сторвайза и монтировать его на сервер бекапов? Не получится по нескольким причинам:gs писал(а): Наверно логичнее не к каждому серверу цеплять по луну, а снапшоты со сторвайзов монтировать к серверу бэкапа.
- снапшет требует места, да и не продавит он производительность сторвайза? В линуксе, например, когда с LVM снимаешь снапшет, производительность дико падает, пока не удалишь снапшет
- и главная проблема: я недосказал, на самом деле 92ТБ раздел серверу от сторвайза отдается не одним луном, а несколькими(12шт) по 7.6ТБ, т.е. по одной рейд-группе, а уже на уровне сервера эти 12 рейд-групп собираются в один кусок с помощью LVM(страйп) для увеличения производительности
А он нужное кол-во дисков даст? По-моему, нет? По моим подсчетам 168 шпинделей по 4Тб надоgs писал(а): А в качестве носителя можно аппарат и попроще - V3700
Не в курсе что за зверь, не подкинете ссылок на варианты поглядетьgs писал(а): или даже инфортренд.
Дублирование сторвайзов не избавит от таких проблем как:digitalm писал(а):Бэкапить такие объемы, наверное, бессмысленное занятие. Тут надо иметь избыточное хранилище (failover) для каждого сервера
- логический обвал ФС
- случайное/умышленное удаление данных
- ну и глюки самого сторвайза, которых в нем еще вычищать и вычищать
В общем я б не стал хранить все яйца в одной корзине и называть это бекапом
ZFS только для соляры и фряхи, ни первое, ни второе официально на серверах ИБМ не поддерживается, а всякие костыли типа zfs on linux не предлагатьdigitalm писал(а):файловую систему со снапшотами (zfs).
-
- Advanced member
- Сообщения: 127
- Зарегистрирован: 08 фев 2006, 18:10
- Откуда: Воронеж
- Контактная информация:
Re: Бекап ОГРОМНОГО кол-ва данных
Похоже что-то вроде Infortrend EonStor DS S12F G2850/R2850 может подойти
Могли бы сконфигурить со 192 дисками 3ТБ и скинуть(цену) ?
Могли бы сконфигурить со 192 дисками 3ТБ и скинуть(цену) ?
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Re: Бекап ОГРОМНОГО кол-ва данных
Инфортренд я имел в виду такой: http://www.infortrend.com/us/products/m ... DS%203060R
Железки весьма приличные, диски из магазина (HCL широкий), но сервис только партнерский.
Щас посчитаем и еще подумаем над схемой.
Железки весьма приличные, диски из магазина (HCL широкий), но сервис только партнерский.
Щас посчитаем и еще подумаем над схемой.
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Re: Бекап ОГРОМНОГО кол-ва данных
Да, у V3700 только 120 дисков.
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Re: Бекап ОГРОМНОГО кол-ва данных
Ловите спецификации на профильное мыло.
Re: Бекап ОГРОМНОГО кол-ва данных
Может быть, проще, в стиле "каменного века" - 2 сервера (исходя из количества серверов с данными - распараллелить копирование и одновременно для резерва) СРК на базе обычной супермикры, каждый с каскадом из корпусов с JBOD? Все соединить по 10 Gbit и вдумчиво разделить нагрузку от источников?
-
- Advanced member
- Сообщения: 127
- Зарегистрирован: 08 фев 2006, 18:10
- Откуда: Воронеж
- Контактная информация:
Re: Бекап ОГРОМНОГО кол-ва данных
Спасибо, жду еще конфиг на 6ТБgs писал(а):Ловите спецификации на профильное мыло.
Не хотелось бы строить городульки и костыли.Bormoto писал(а):Может быть, проще, в стиле "каменного века" - 2 сервера (исходя из количества серверов с данными - распараллелить копирование и одновременно для резерва) СРК на базе обычной супермикры, каждый с каскадом из корпусов с JBOD? Все соединить по 10 Gbit и вдумчиво разделить нагрузку от источников?
Раз уже заложен фундамент FC сети(два свитча), надо его и развивать.
А по поводу софта, подсказали xfsdump, сейчас щупаю
-
- Advanced member
- Сообщения: 127
- Зарегистрирован: 08 фев 2006, 18:10
- Откуда: Воронеж
- Контактная информация:
Re: Бекап ОГРОМНОГО кол-ва данных
Прикинул тут, получается 120 дисков по 6Тб самый оптимальный вариант:
это 15 рейд-групп по 8 дисков (рейд 6), в каждой рейд-группе из 8 дисков 6 дисков под данные, 2 диска под парити. Итого одна рейд-группа 5,5 * 6 = 33ТБ
15 * 33 = 495ТБ, как раз то, что мне нужно
Теперь самое интересное, эта хранилка как отдает массивы хостам? Это просто молотилка, тика как ибм 3512/3524, которая отдает рейд-группы? Или она имеет какую-то логическую прослойку и менеджер логических томов, типа сторвайза?
В принципе мне менеджер томов не нужен, если эта хранилка поддерживает рейд 60, как указано в спеке. Если я могу собрать рейд 60 из 24 дисков с 8ми дисковыми группами, то это получается раздел 99ТБ, как раз.
Итого
4 раздела(4 рейд 60 по 24 диска) по 99ТБ (два для одного сервера и два для второго)
2 раздела(2 рейд 6 по 8 дисков) по 33ТБ(один для одного сервера и один для второго)
и еще один раздел 33ТБ остается прозапас
Главный вопрос, как эта хранилка отдает диски хостам и можно ли собрать рейд 60 из 24х дисков(рейд 0 поверх трех рейд 6 из 8 дисков)
это 15 рейд-групп по 8 дисков (рейд 6), в каждой рейд-группе из 8 дисков 6 дисков под данные, 2 диска под парити. Итого одна рейд-группа 5,5 * 6 = 33ТБ
15 * 33 = 495ТБ, как раз то, что мне нужно
Теперь самое интересное, эта хранилка как отдает массивы хостам? Это просто молотилка, тика как ибм 3512/3524, которая отдает рейд-группы? Или она имеет какую-то логическую прослойку и менеджер логических томов, типа сторвайза?
В принципе мне менеджер томов не нужен, если эта хранилка поддерживает рейд 60, как указано в спеке. Если я могу собрать рейд 60 из 24 дисков с 8ми дисковыми группами, то это получается раздел 99ТБ, как раз.
Итого
4 раздела(4 рейд 60 по 24 диска) по 99ТБ (два для одного сервера и два для второго)
2 раздела(2 рейд 6 по 8 дисков) по 33ТБ(один для одного сервера и один для второго)
и еще один раздел 33ТБ остается прозапас
Главный вопрос, как эта хранилка отдает диски хостам и можно ли собрать рейд 60 из 24х дисков(рейд 0 поверх трех рейд 6 из 8 дисков)
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Re: Бекап ОГРОМНОГО кол-ва данных
Вопрос перешел в оффлайн.
Re: Бекап ОГРОМНОГО кол-ва данных
А ОП пробовал amanda и функцию RAIT (подразумевая, что несколько приводов LTO)? В конфигурациях RAIT аманда будет писать поток на несколько приводов одновременно, также повышая надежность хранения.
-
- Advanced member
- Сообщения: 127
- Зарегистрирован: 08 фев 2006, 18:10
- Откуда: Воронеж
- Контактная информация:
Re: Бекап ОГРОМНОГО кол-ва данных
Запросил еще две конфигурации, посчитайте пожалуйста.gs писал(а):Вопрос перешел в оффлайн.
Нет, не пробовал, но боюсь, что с надженостью лент и моими объемами данных, запись на несколько приводов одновременно только добавит проблем, а не решит их.sivanov писал(а):А ОП пробовал amanda и функцию RAIT (подразумевая, что несколько приводов LTO)? В конфигурациях RAIT аманда будет писать поток на несколько приводов одновременно, также повышая надежность хранения.
По поводу технического решения уже определились: СХД + xfsdump
Кстати еще говорили про супермикро сервер с полками дисков по 90шт, а каким образом по FC отдавать массивы нодам? Разве linux умеет выполнять ф-ию СХД и отдавать по FC имеющиемя у него массивы, как блочные устройства?
Re: Бекап ОГРОМНОГО кол-ва данных
например https://www.openfiler.com/products/open ... target-faqmetallic писал(а):Кстати еще говорили про супермикро сервер с полками дисков по 90шт, а каким образом по FC отдавать массивы нодам? Разве linux умеет выполнять ф-ию СХД и отдавать по FC имеющиемя у него массивы, как блочные устройства?
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 30 гостей