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