Ранее на этой неделе у меня был 'идеальный шторм' момент на моих серверах: два задания резервного копирования (по одному для каждого массива RAID10 в системе) выполнялись в течение 18 часов, а затем у нас был устойчивый всплеск трафика в моем приложении с интенсивным вводом-выводом. Результатом стала неприемлемо низкая производительность, и мне пришлось заставить администратора отменить резервное копирование. (Он был недоволен этим ... нисколько. "Я не несу ответственности, если ...")
Конечным результатом был сильный стресс, недовольные клиенты и очень ворчливый Стю.
Узким местом была загрузка диска. После того, как рабочие места были отменены, все стало работать нормально. Что я могу предложить своим администраторам, чтобы уменьшить воздействие на мои серверы?
Вот некоторые из кровавых подробностей:
Сама команда резервного копирования (Я получил это из ps, но на самом деле не знаю, что это значит.)
bpbkar -r 1209600 -ru root -dt 0 -to 0 -clnt xtx-le00 -class F_Full_on_Thursday
-sched Incr_Fri_to_Wed -st INCR -bpstart_to 300 -bpend_to 300 -read_to 300
-blks_per_buffer 127 -stream_count 8 -stream_number 8 -jobgrpid 223932 -tir -tir_plus
-use_otm -use_ofb -b svr_1259183136 -kl 28 -fso
Система
Данные
1 ТБ
Приложение
У нас есть система, в которой мы синхронизируем живые серверы с серверами резервного копирования (которые построены из дешевых дисков SATA емкостью 1 ТБ), а затем делаем полные резервные копии на ленте серверов резервного копирования. Отлично:
Я не уверен, как работает bpbkar на самом деле, но я бы использовал rsync для резервного копирования всех файлов за пределами сайта, а затем для их синхронизации, что потребовало бы очень мало ресурсов, поскольку обновляются только измененные файлы. Естественно, это означает, что для первоначального резервного копирования потребуется некоторое время, но вы уже говорите, что «напеваете 18 часов».
Затем вы могли бы просто управлять резервными копиями данных с другой машины, как вам хотелось бы.
Небольшое изменение: если вы решите отказаться от резервного копирования на магнитную ленту на диск, вы можете использовать RAID6, который будет предлагать двойную четность.
Если ваши резервные копии запускаются в обычном режиме за 18 часов, отмена их приоритета, вероятно, не решит проблему (если вы не хотите запускать резервные копии в течение пары дней за раз). Я был бы склонен установить механизм репликации диска на другую машину (мне нравится DRBD), а затем использовать LVM, чтобы сделать моментальный снимок на определенный момент времени, сделать резервную копию и двигаться дальше. Поскольку он работает на отдельной машине, (а) он может работать с любой силой, не затрагивая живое приложение, и (б) он не будет конкурировать с живым приложением для ввода-вывода диска, что означает, что он, вероятно, будет запускать намного быстрее.
Одно я могу сказать точно: все, что вы делаете на одной машине, полностью уничтожит ваш дисковый кеш - поскольку процесс резервного копирования считывает все данные с диска для резервного копирования (даже если он просто проверяет mtimes, а не читает и контрольная сумма всех файлов), в вашем кэше по-прежнему работает много блоков метаданных, и они будут выбрасывать полезные данные из кеша и вызывать больше операций ввода-вывода диска, чем это требуется в противном случае.
bpbkar - это клиент резервного копирования Veritas Netbackups. Он поддерживает регулирование, поэтому сочетание нормального ввода-вывода и резервного ввода-вывода не перегружает ваши диски. Посмотрите здесь:
http://seer.entsupport.symantec.com/docs/265707.htm
Есть ли что-то, что мешает вам делать полные резервные копии в выходные дни, когда вы говорите, что система в основном загружена в будние дни, и инкрементное резервное копирование в течение недели? Это поможет вам выполнить резервное копирование во время тихого интервала между 23:00 и 09:00.
Еще один голос за rsync. Я использую его для ежедневного резервного копирования 9 ТБ очень загруженного файлового сервера. никогда не было проблем.
Если вас беспокоит «момент времени», создайте снимок LVM, смонтируйте, rsync, umount, уничтожьте. Несколько выше нагрузка на сервер, но все же намного (намного!) Меньше времени, чем у полной копии.
Если администратор говорит, что это должно быть положительно, обязательно bpbkar, сначала выполните rsync для менее используемой системы, а затем запустите bpbkar от него. Нет необходимости перегружать вашу производственную систему.
Анектод из тестирования: когда мы приблизились к пределу ext3 в 8 ТБ, мы провели несколько тестов, чтобы определить, насколько возможно повредить файл из-за аппаратного сбоя во время копирования. отключили сервер, ящики для хранения и проводку SAN. скопировал десятки миллионов файлов.
Выводы:
коротко, rsync действительно очень хорошо работает. Любую ошибку лучше отнести к вашему оборудованию и / или файловой системе. bpbkar не будет работать лучше при тех же ошибках.
Судя по опубликованной вами команде и параметрам -class и -sched, похоже, что вы выполняете полное резервное копирование в четверг - вероятно, не лучший план с учетом вашего графика использования (900-2300 рабочих дней).
С такими огромными наборами данных вам следует учитывать время создания полной резервной копии, а также тип инкрементной резервной копии, которую вы делаете в течение недели. В NetBackup есть 2 типа инкрементных резервных копий:
Я бы подумал о смене стратегии резервного копирования для этой системы на полное резервное копирование в субботу или воскресенье и дифференциальное инкрементное резервное копирование на оставшуюся часть недели. Это запустит полное резервное копирование, когда для этого достаточно времени (нет / мало пользователей), и короткие инкрементальные копии за несколько часов низкого использования, которые у вас есть. Проблема с этим методом заключается в том, что восстановление может быть немного более запутанным - вам потребуется больше лент - лента для полной плюс все инкременты от этого полного до точки, в которую вам нужно восстановить данные.
Судя по вашему вопросу, похоже, что вы плохо знакомы с системой резервного копирования. Я понимаю, что системные администраторы отделены от операторов резервного копирования, но между ними необходимо некоторое обсуждение. Если операторы резервного копирования не имеют представления о том, как используется система, они не могут сформировать правильную политику и расписание для системы.
Попросите администраторов NetBackup лучше планировать резервное копирование - делайте полные резервные копии через неделю для каждого RAID-массива.
Вы также можете изучить синтетические полные резервные копии, чтобы вам не приходилось делать столько полных резервных копий.
Пара предложений:
Другие предложения rsync также хороши - нет причин, по которым rsynced копия данных не была бы такой же хорошей, как изображение на первичном сервере, если это не приложение для базы данных. Если это приложение типа базы данных, вы должны копировать журналы транзакций и образы резервных копий в другую систему по мере их создания и выполнять их резервное копирование.
Я бы сделал резервную копию данных на цели rsync в netbackup, но я бы также сделал резервную копию ОС и всего, кроме данных программы (материала, занимающего пространство) на основной цели и цели rsync. Резервное копирование данных ОС и программ должно быть простым и быстрым, и, вероятно, в любом случае оно должно быть в другой политике резервного копирования.
Здесь есть две проблемы: одна связана с вашей архитектурой, а другая - с вашей реализацией.
Вы можете легко оптимизировать свою реализацию, выполнив такие действия, как изменение окон резервного копирования или реже резервное копирование, или купив более быстрые диски, сети или ленточные накопители, или скопировав данные в другую систему. Эти изменения действительны, уместны, и, если на вашей стороне закон Мура, они могут поддерживать вашу работу должным образом навсегда.
Вы также можете попасть в ситуацию, когда все чаще и чаще сталкиваетесь с проблемами масштабирования. Если вы даже немного беспокоитесь о том, что у вас могут возникать проблемы с масштабированием все чаще и чаще, вам нужно подумать о том, как изменить дизайн вашей системы, чтобы улучшить ее масштабирование. Такие вещи непростые, но, поскольку они непростые, вам нужно спланировать их заранее, когда вам приставят пистолет к голове.
Пример настройки вашей архитектуры может включать перемещение всех ваших данных в систему типа NAS, такую как файловое устройство NetApp или ящик с Solaris и ZFS. При такой настройке вы создаете резервную копию сервера, который будет в основном вашей программой и конфигурацией, и используете функции управления данными SAN для резервного копирования SAN. Это могут быть снимки и журналы транзакций для снимка.
Вы также можете сделать что-то похожее на то, что делает archive.org, где вы храните данные во множестве разных систем, обычно любой конкретный фрагмент данных существует в нескольких системах, а затем у вас есть ферма интерфейсных систем, которые направляют запросы на в какой бы системе ни находились данные.
Наконец, вы уверены, что ваши резервные копии вообще работают? Выполнение резервного копирования в течение 18 часов в действующей системе приводит к созданию резервной копии, которая отражает эту систему за все эти 18 часов. В идеале резервная копия отражает систему в один атомарный момент времени, а не какое-то сумасшедшее скользящее резервное копирование, в котором одни данные взяты из одного момента времени, а другие - почти на целый день позже. Если какие-либо из ваших данных зависят от других частей данных в другом месте или указывают на них, эти зависимости будут сильно испорчены, если резервные копии получат данные в середине изменения, и с таким большим набором данных у вас 100% вероятность этого сценарий, если это возможно, для каждой вашей резервной копии.