Это немного многословно и многословно. Если вы пришли сюда в поисках советов по улучшению производительности и / или пропускной способности резервного копирования commvault, то вам следует щелкнуть здесь, чтобы получить полезные сведения.
Я давно не писал в блоге. Прошло очень много времени с тех пор, как я писал в блоге обо всем, что мы делали в $ Dayjob.
Большую часть года я провел, разбирая решение для резервного копирования здесь.
Первоначально у нас был сервер хранения данных с 30 с лишним ТБ хранилищ SATA, использующий немного технологии LSI с кэшем записи с резервным питанием от батареи … Довольно хорошо для запланированного резервного копирования rsnapshot. Однако в мае мы решили отсортировать резервные копии за пределами площадки и разработать некую стратегию аварийного восстановления.
Наш торговый посредник прислал нам несколько цитат для ряда аппаратных и поддерживаемых программных решений. Мы ограничены бюджетом, и в результате также ограничены технологиями, которые мы могли бы использовать для резервного копирования.
У нас есть файл-накопитель Hitachi / Bluearc NAS, который состоит из двух уровней, одного высокоскоростного пула SAS и одного низкоскоростного, но огромного пула SATA. Все хранилище подключено к объединительной плате NAS с помощью FibreChannel 4 Гбит, а 2 головки NAS кросс-коммутированы и соединены с нашим базовым коммутатором с помощью 4 (2 на каждую) 10 Гбит Fibre Ethernet.
Учитывая стоимость носителей и простоту транспортировки вне площадки, была выбрана система резервного копирования на ленту. С точки зрения автономного / автономного хранилища гораздо дешевле иметь ленточные носители, которые находятся в коробке, а не коробки с вращающейся ржавчиной, которые должны храниться в прохладном помещении, включая расходы на электроэнергию и обслуживание.
Первое решение будет включать прямое подключение накопителей на магнитной ленте к файлу. В идеале, с FibreChannel, но, поскольку мы уже использовали все порты FC на фильтре для хранения, нам пришлось бы инвестировать в пару коммутаторов FC. Это немалые затраты и делает это решение непомерно дорогим.
К счастью, существует альтернатива, где у нас есть резервный сервер, мы используем NFS для монтирования экспортированных файловых систем, подключаем его к ядру через 10Gbit Ethernet, а затем подключаем ленточные накопители к этому серверу.
Мы заказали у нашего поставщика системы хранения автозаменку Spectra Logic T50e, программное обеспечение Commvault Backup и сервер для его запуска. Это где проблемы начались.
Как и ожидалось, была как минимум одна проблема с оборудованием. Наше ядро 10Gbit полностью волоконно, особенно MMF, но здесь дело не в этом. Новый резервный сервер, который был заказан, был подключен к сетевой карте X540-T2, скорость которой 10 Гбит по сравнению с медной.
Нам нужен был один с SFP, 
как этот, X520-SR2. Таким образом, мы должны были заказать один из них, доставить его и отложить весь проект до прибытия этой карты. Три .. Дня. Позже, NIC прибыл. Без какой-либо оптики. Видимо при заказе у Dell это две отдельные позиции. Это не тот случай, когда вы заказываете у Intel или кого-либо еще.
Итак, через неделю мы получили весь NIC и заставили его работать. Примерно через 2 недели торговый посредник / распространитель программного обеспечения commvault был на месте, чтобы установить программное обеспечение на наш сервер. Проблема … Нам сказали, что весь программный пакет работает на Linux. Фактический сценарий состоит в том, что контроллер резервного копирования (Commcell GUI) работает только в Windows (несмотря на то, что он просто Java-приложение). Мало того, что он работает только на Windows, но он работает только на Windows Server 2008 (вероятно, работает на 2003, но кто, черт возьми, хочет установить это в новой системе). Поэтому нам пришлось откуда-то получить лицензию на Windows-сервер. К счастью, одна из вещей, которые я скачал, была оценочной версией Windows 2008, ISO, и положила ее в центральный магазин ISO. Поэтому в тот день, когда появился установщик Commvault, мы предполагали, что план будет примерно таким:
1) Установите программное обеспечение на Linux-коробку.
2) Начните копировать вещи.
3) паб?
Вместо этого нам пришлось попробовать установить Windows 2008 R2 на виртуальную машину (которая была медленнее, чем холодная ириска). В конце концов, я просто украл компьютер своего напарника и установил на нем сервер Windows, а затем перенес его из-под нашего стола в кладовую. В какой-то момент нам понадобится P2V и освободить рабочую станцию (или установить ее где-нибудь более постоянное).
Так что … большую часть дня заняли траханья с Windows Servers, прежде чем приступить к каким-либо вещам по настройке.
Я думаю, что это хорошо, что по большей части процесс установки агента Unix / Linux Commvault довольно прост, поскольку после настройки на стороне сервера установка клиента завершается, происходит общение с сервером и в значительной степени устанавливает себя.
Кстати, больше установок должно произойти, как это.
Как бы то ни было … В итоге мы установили клиент Linux и «Media Agent» — это тот самый бит, который фактически общается с NFS, а также общается с подключенными к Fibrechannel ленточными устройствами и управляет автоматическим сменщиком. Нам пришлось определить каталоги для резервного копирования в контроллере Windows Server, затем настроить, что и куда и так далее. (Это определенно блог для другого дня). Мы запустили резервную копию * всего * — которая в то время составляла около 20 ТБ, и вышли из строя домой.
В какой-то момент мы придумали цифры для объема данных, которые мы будем резервировать при работе на полную мощность. В общей сложности это составляет около 30 ТБ, и мы хотели иметь возможность сделать это за выходные, поэтому в до 48 часов. Таким образом, нам нужна резервная система, которая может работать со скоростью не менее 30 ТБ / 48 часов, что обеспечивает стабильную пропускную способность 173 МБ / с. — Это важно, и мы вернемся к этой цифре несколько раз.
Первое лучшее резервное копирование, которое мы попробовали, мы получили общую объединенную пропускную способность 290 ГБ / час (Commvault выбирает ГБ / час, поскольку это единица выбора, довольно странная, если честно ..) 290 ГБ / час — 80,5 МБ / s .. При такой скорости полное резервное копирование займет 30 ТБ / (80,5 МБ / с), что составляет около 4,4 дня. Таким образом, мы бы перешли наше 48-часовое окно резервного копирования более чем вдвое.
Это время, когда мы решили, что у нас могут возникнуть две проблемы, и решили разбиться на очень длинный и глубокий ряд кроличьих дыр, окружающих цели, сравнивающих как производительность ленты (включая CommVault), так и сравнительный анализ Bluearc NAS ,
Это на самом деле намного сложнее, чем все это, потому что нет единой точки этой системы, которая так или иначе не связана с кучей других систем. Нам нужно взглянуть на Bluearc, ядро 10 Гбит, новый сервер резервного копирования, карты Fibre Channel, ленточные накопители, ленточную библиотеку и все промежуточное программное обеспечение между ними.
К счастью, бенчмаркинг NFS довольно прост, и я придумал, как провести несколько тестов IOZone за одну ночь, чтобы на следующий день у меня было от 1 до 1000 точек данных производительности IOZone.
Нам пришлось выяснить оптимальные параметры для чтения файлов NFS на скорости, учитывая диапазон возможных размеров блоков и блоков, а также ряд вариантов, касающихся однопоточной или многопоточной.
Это сценарий, который я создал вместе для генерации тестов с использованием IOZone.
THREADS="1 2 4 8 16 24"
RS="8k 256k 512k 1M 4M 8M 16M"
FS="1M 2M 8M 16M 32M 256M"
echo "cd /mnt/shows/benchmarktest/`hostname`/" > `hostname`-fullbenchmark.sh
for f in $FS;
do for r in $RS;
do for t in $THREADS;
do echo "iozone -R -b autobench-${t}T-${r}-${f}-`date +%s`.asc -l${t} -u${t} -i0 -i1 -F $(seq -w -s ' ' 1 ${t}) -r ${r} -s ${f}";
done;
done;
done >> `hostname`-fullbenchmark.sh
«/ mnt / shows» — это место, которое находится в нашем хранилище Fast SAS, поэтому, по крайней мере, в этом тесте мы будем рассматривать максимально приближенную к максимальной пропускной способности, которую мы когда-либо надеемся получить из наших дисковых массивов. Поскольку большинство наших данных также хранятся в этом более быстром пуле, они, вероятно, будут аналогичным образом представлять реальные данные.
Так или иначе.
После первого теста производительности мы видим примерно прямую корреляцию между количеством потоков и пропускной способностью вплоть до того момента, когда число потоков превышает количество ядер, и пропускная способность замедляется. Этого следовало ожидать, потому что, когда у вас больше запущенных потоков, чем ядер ЦП, вы получаете все больше переключателей контекста и так далее.
Другой вывод, который легко сделать, заключается в том, что перечитанная производительность сумасшедшая. По сути, Bluearc имеет определенное количество высокоскоростного кеша для данных, которые считываются и перечитываются, поэтому при первом получении вы извлекаете его с диска. Последующие чтения происходят из памяти, и, следовательно, ослепительно быстро, но только для небольших размеров файлов. Большие файлы не могут быть сохранены во встроенном кэше, и именно здесь опция BlueArc для уровня SSD становится феноменально крутой. Это также имеет безумную цену, но мы идем.
В целом лучшая производительность была при размере блока 4 Кбайт / записи, файла размером 1 МБ, при использовании 20 потоков чтения (на коробке с 32 ядрами 20 потоков — это самое приятное место), и это дало нам скорость чтения 1,4 ТБ / час. ,
Мы сообщили об этих результатах в BlueArc, который полагал, что мы, возможно, столкнулись с ошибкой в аппаратно оптимизированном NFS-сервере, который они предоставляют. У нас были два варианта: а) обновить до последней версии патча и / или б) попробовать отключить аппаратную оптимизацию и посмотреть, что произойдет.
Мы запустили еще одну серию тестов IOZone за одну ночь с отключенной оптимизацией аппаратного обеспечения и обнаружили, что при некоторых размерах чтения / количестве потоков производительность значительно улучшается, в основном это небольшие фрагменты из большого файла, всего 2 потока считывателей, в то время как производительность для операций с несколькими читателями был абсолютно уничтожен.
Эффект от этого заключается в том, что если бы мы обслуживали только 2-4 клиента или 2-4 потока считывателей, мы могли бы придерживаться программной обработки NFS, но для производительности нескольких пользователей (например, имея ферму из 100 чтение и запись рендернеров на диски), мы бы облажались, если бы оставили аппаратный режим NFS выключенным.
Таким образом, мы снова включили это и приступили к настройке размеров блоков чтения NFS, чтобы они точно соответствовали лучшей производительности, которую мы видели.
За последние 100 дней к нам присоединились некоторые инженеры Bluearc (действительно трудно отследить, когда произошли реальные события), и они обновили наши RAID-массивы, а также головы NAS до последней версии, которая, казалось, улучшала NFS производительность тоже.
Это действительно очень быстрый обзор настройки производительности NFS. Наверное, есть еще что сказать, если я могу вспомнить!
Интересно отметить производительность 10Gbit Ethernet в том, что в используемом нами сценарии мы, вероятно, используем 1-4 потока одновременно, используя соединение. Это делает невероятно трудным насыщение канала связи, поскольку большинство приложений, написанных за последние 10 лет, были разработаны с учетом 1 Гбит Ethernet, поэтому они либо плохо масштабируются, либо жестко запрограммированы для использования небольшого числа. нитей. Это, как ни странно, включает в себя клиент NFS для Linux, и если вы сравните модель клиента NFS в Linux с базовой моделью, используемой в Solaris, в котором используется SunRPC, на самом деле можно мультиплексировать по одному соединению, задав число сетевые темы.
Если вы загрузились в Solaris / OpenSolaris / OpenIndiana, вы можете отредактировать этот параметр, выполнив следующую маленькую жемчужину.
$ mdb -kw
clnt_max_conns/W 8
q
«mdb» немного похож на «sysctl.conf» в Linux, а «clnt_max_conns» — это количество потоков, используемых для клиента NFS. Мы обнаружили, что если мы загрузимся в OpenIndiana, смонтируем монтирования NFS и установим clnt_max_conns достаточно высоко, мы получим невероятную производительность из Bluearc, пока OpenIndiana не заблокируется и не упадет. На самом деле мы не приложили много усилий, чтобы выяснить это, это было больше, чем просто подтверждение концепции, чтобы увидеть, сработало ли это. Полагаю, я бы очень хотел вернуться к работе с OpenIndiana на 10Gbit Ethernet, но на самом деле времени нет.
К сожалению.
Я сделал несколько вещей с опциями драйвера NIC в Linux, пытаясь получить приличную производительность от этих сетевых адаптеров 10G, и пришел, что несколько удивительно, к выводу, что если вы оставите модуль драйвера по умолчанию таким, каким он был при установке устройства вы получаете гораздо лучшую производительность, чем когда начинаете ссориться с такими вещами, как масштабирование окна TCP, контрольная сумма TCP и выборочный ACK. Чем меньше вы играете, тем выше ваша производительность, и если по какой-либо причине вы получите немного лучшую производительность за счет поворотов, она будет в диапазоне 0,5-1%, а не на 10-20% увеличения скорости.
Это еще кое-что, что я бы хотел потратить на тестирование и тестирование, но, опять же, у нас нет ни времени, чтобы изучить это подробно или подробно, ни имеющегося оборудования для работы. 10-гигабитные сетевые карты все еще довольно дороги. Я полагаю, когда они снизятся в цене, я, вероятно, куплю некоторые свои собственные и возьму с собой старую добрую скрипку и настройки, и напишу это … Однажды. ? Полагаю, если бы кто-то захотел купить мне комплект, я бы оценил его и написал какой-то эталон о том, какую производительность вы получаете, изменяя все различные настройки, но опять же, как и во всех остальных случаях, производительность все очень хорошо и хорошо, но это будет лишь эталонный тест, поскольку ваша реальная производительность и пропускная способность, как правило, сильно различаются в зависимости от того, что вы делаете с аппаратным обеспечением.
С отсутствующим тестированием NFS (на данный момент) пришло время хорошенько заглянуть в ленточные накопители.
К счастью, это довольно просто для тестирования ленточного накопителя .. Есть три варианта сделать это.
1) Commvault «Validate Drive» — вы загружаете ленту, она записывает на нее что-то, читает ее обратно и дает вам скорость. По крайней мере, этот механизм просто генерирует данные из / dev / zero или где-либо еще и записывает их прямо на ленту, поэтому диски не задействуются.
2) IBM TapeTool — это диски IBM HH-5 Ultrium, так что есть утилита IBM Tape Test, я подозреваю, что она делает нечто очень похожее на инструмент Validate Drive.
3) Гну тар. Несмотря на то, что они являются умными ленточными накопителями, подключенными к FC, они по-прежнему являются магнитными символьными устройствами, поэтому мы можем записывать их напрямую с помощью mt и tar.
Полученные результаты:
1) Commvault сообщил о скорости записи ~ 120 МБ / с и скорости чтения ~ 135 МБ / с для обоих дисков.
2) Утилита IBM Tape Tool сообщила о скорости записи ~ 130 МБ / с для обоих дисков: http://imgur.com/AYH3x http://imgur.com/IOUiP
3) Когда дело дошло до использования Gnu Tar для бенчмаркинга, было проще всего сделать его двухэтапным процессом.
Инструмент `pv` невероятно полезен для такого рода вещей, поскольку вы можете визуализировать объем данных, передаваемых по каналу FIFO.
С tar просто запустите что-то похожее на следующее.
tar cvf - /path/to/thing/to/backup | pv > /dev/st0
Таким образом, tar прочитает материал по пути и запишет его в файл — это STDOUT, который передается в pv, чтобы увидеть пропускную способность, а затем записывается в / dev / st0 (тестируем это, записывая в / dev / null также допустимо только для тестирования производительности NFS, просто возьмите данные с помощью tar и поместите их в bitbucket).
Если мы сможем получить производительность с помощью tar где-нибудь рядом с эталонными скоростями записи от TapeTool или Commvault, мы докажем 2 вещи. 1) что ленточные накопители могут обрабатывать данные с такой скоростью, а также что серверы NFS могут передавать их с такой скоростью.
На уровне SAS мы получаем такую производительность.
2GB 0:00:44 [ 253MB/s] [ <=> ]
Из уровня SATA мы получаем:
2.43GB 0:01:10 [ 116MB/s] [ <=> ]
Что и следовало ожидать. Мы всегда ожидали, что диски SATA будут работать медленнее примерно на этом уровне.
Таким образом, с уровнем SAS, способным выдавать один поток со скоростью 253 МБ / с, это 126 МБ / с на диск, что довольно близко (немного выше) скорости проверки Commvault и немного ниже эталонного теста IBM TapeTool.
Таким образом, на реальных данных мы эффективно доказали, что диски SAS могут работать с нужной скоростью, чтобы ленты были довольны на полной скорости. Мы также доказали, что ленточные накопители могут записывать с такой скоростью.
Так почему, черт возьми, мы все еще видим производительность 300-400 ГБ / час через Commvault?
Разбивая его на части, в CommVault есть * множество * различных параметров, которые можно настроить в зависимости от настройки производительности.
Я собираюсь вернуться к этому более подробно в какой-то момент, но это разбивается на:
В свойствах субклиента:
1) Количество считывателей данных: установите это значение в 2 раза больше количества накопителей на магнитной ленте (даже если служба поддержки CommVault не скажет!)
2) Разрешить несколько считывателей данных на диске или точке монтирования — отметьте это.
3) Устройство хранения -> Опция передачи данных -> Настройка ресурсов -> Сетевые агенты: установите это значение на 2 или 4 (смотрите, какой из них лучше для вас).
В Свойствах политики хранения (в частности, свойствах ваших политик хранения):
1) Потоки устройств (установите это в 2 раза больше ваших стримеров)
2) Включить рандомизацию потока: отметьте это.
3) Выберите инкрементную политику хранения (и внесите в нее те же изменения, что и эту).
В свойствах копии (всех заданных политик хранения):
1) Вкладка «Медиа» -> Включить мультиплексирование
2) Установите коэффициент мультиплексирования в 2 раза больше количества ленточных накопителей.
3) Включите «Использовать потоки устройств вместо мультиплексирования, если это возможно».
В панели управления Global Commvault:
В Медиа Менеджмент
1) Установите размер порции для файловой системы Linux на 16384 МБ.
Свойства медиа-агента:
1) «Максимальное количество параллельных операций передачи данных»
Установите «Ограничить» до 200 (самый высокий это будет). — Почему здесь есть какие-то ограничения, для меня загадка.
На вкладке «Управление» поле «Передача данных»
2) Включите «Оптимизация для одновременного резервного копирования локальной сети».
С указанными выше настройками мы теперь получаем производительность от 700 до 900 ГБ / час в зависимости от того, что мы копируем, но, к счастью, пока это находится в нашем окне резервного копирования. Я боюсь, что если мы планируем сделать больше резервных копий за тот же период времени, нам потребуется больше слотов для магнитной ленты и больше ленточных накопителей.
И это все, я боюсь. Я не могу рассказать вам больше о настройке Commvault. Я надеюсь, что если какой-нибудь бедный ублюдок попытается настроить CommVault для обеспечения приличной скорости резервного копирования, это будет полезно.