Мультиплексирование NetBackup для резервного копирования Oracle RMAN
Мой вопрос... какой фактор мультиплексирования в NetBackup рекомендуется / вы используете для резервного копирования Oracle RMAN через сеть управления 1 Гбит / с на LTO3?
JB
Фон:
В корпоративных инструментах резервного копирования, таких как NetBackup, существует концепция мультиплексирования, которая заключается в объединении данных от нескольких клиентов резервного копирования одновременно для максимально быстрой подачи на современные высокоскоростные ленточные накопители.
Число одновременных чередующихся потоков данных клиента определяется коэффициентом мультиплексирования. Чем выше коэффициент мультиплексирования, тем больше данных подается на ленточный накопитель, но медленнее восстанавливается.
Поскольку общая скорость восстановления в основном определяется беспорядком (журнал событий, определить, доступны ли ленты, отзыв из внешнего хранилища, загрузка, инвентаризация и т. Д.), А не фактической скоростью восстановления на ленту, я уверен, используя высокий коэффициент для резервных копий файловой системы.,
Резервные копии Oracle с большими наборами данных, которые чаще всего восстанавливаются вместе, представляют собой другую проблему для резервных копий файловой системы.
3 ответа
Это полностью зависит от того, сможет ли ваш сервер Oracle передавать данные достаточно быстро, чтобы обеспечить потоковую передачу дисков LTO3. Я не мультиплексирую данные Oracle, потому что большие файлы обрабатываются достаточно быстро, чтобы приводы работали на приемлемой скорости.
Однако до того, как мы заменили серверы Oracle, и они создавали резервные копии только примерно вдвое быстрее, чем я, я фактически фактически мультиплексировал их.
Важно отметить, что при мультиплексировании с NetBackup восстановление выполняется немного медленнее, но не намного медленнее. Я знаю, что для Certian вы можете демультиплексировать на восстановление. Мы делаем это все время, чтобы проводить тесты восстановления и, в редких случаях, фактически заменять потерянные данные.
Я настоятельно рекомендую протестировать оба способа и посмотреть, сможете ли вы обеспечить достаточную скорость ваших накопителей LTO3 без мультиплексирования.
Первое, что нужно проверить, это то, какую пропускную способность сети (TCP) может обработать ваш сервер. Используйте netcat и т. Д. Если скорость составляет менее 30 МБ / с, мультиплексирование по сети бесполезно для вас, и мой дальнейший совет может быть проигнорирован. Вместо этого работайте над настройкой пропускной способности вашей сети. Теперь к делу.
Накопитель LTO3, как и любой другой линейный накопитель на магнитной ленте, работает хорошо только тогда, когда он получает поток данных с определенной постоянной пропускной способностью.
Лента проходит под головой с высокой скоростью, и вы не хотите ее останавливать. При каждой остановке привод должен выполнять длительную процедуру: замедляться до полной остановки, ускоряться назад, проходить точку конца данных, снова замедляться, ускоряться вперед, чтобы достичь точки конца данных. Когда NetBackup не передает данные достаточно быстро, буфер часто переполняется, поэтому накопителю приходится часто останавливаться / перематываться / запускаться. Спектакль сильно пострадал. Это называется операцией "старт-стоп" или "чистка обуви".
Drive несколько регулирует скорость ленты, но не очень, она может упасть примерно до 50% от максимальной скорости.
Весь смысл мультиплексирования Netbackup состоит в том, чтобы обеспечить лучшую пропускную способность потоковой передачи и избежать запуска-остановки. Проверьте пропускную способность вашей резервной копии RMAN, если она составляет 30 МБ / с или менее, у вас есть классическая операция начала и остановки.
Теперь позвольте мне прояснить одну вещь. Если у вас нет старт-стопа, я бы вообще не рекомендовал мультиплексировать резервные копии RMAN. RMAN достаточно сложен без мультиплексирования. Я не хочу связываться с RMAN, я хочу, чтобы мое восстановление было максимально быстрым, легким и плавным.
Однако, если вы обнаружите, что ваша пропускная способность резервного копирования неприемлемо низкая, я бы предложил для начала использовать около трех потоков мультиплексирования. Увеличивайте число каждую ночь, пока вы не получите больше пропускной способности. И убедитесь, что каждый поток идет от разных дисковых шпинделей. Не из разных разделов / табличных пространств / файловых систем / баз данных / серверов /LUN / других уровней виртуализации. Это мало что значит, если таковые имеются. Физические дисковые шпиндели. Если вы подаете много потоков с одних и тех же шпинделей, вы просто вызовете побои, и общая производительность снизится еще больше.
Примечание: теоретически NetBackup также может демультиплексировать восстановление. Если я правильно помню, он немного останавливается перед восстановлением, чтобы дать шанс для новых попыток восстановления. В этом случае они будут работать совместно, как мультиплексные резервные копии. Но, пожалуйста, проверьте это с помощью руководства, я уверен только в этом на 90%.
Я нашел самый простой способ решить эту проблему - записать начальную резервную копию на диск, а затем скопировать образы резервной копии на ленту.
Мультиплексные резервные копии с большей вероятностью охватывают ленты, их труднее импортировать или использовать вне netbackup, их медленнее восстанавливать, и это всесторонний уродливый хак, созданный для предотвращения появления блеска в обуви.
Netbackup обладает действительно хорошей функциональностью прямого доступа к диску, а инструменты CLI позволяют довольно легко создавать механизмы дублирования изображений.