Домен даних: Посібник із найкращих практик віртуальної стрічки

Посібник з найкращих практик VTL

МЕТА

Цей документ містить рекомендації щодо передової практики, які допоможуть забезпечити оптимальну продуктивність і віртуальну стрічку домену даних (VTL) у середовищах резервного копіювання, а також забезпечити простоту підтримки та обслуговування продукту.

ВІДНОСИТЬСЯ ДО

• Всі системи Data Domain
• Усі релізи програмного забезпечення з підтримкою VTL
• Протокол VTL
• Сторонні програми для резервного копіювання («BA»), такі як NetWorker, TeraSAM тощо

РІШЕННЯ

1. Основні рекомендації, щоб уникнути поганої продуктивності:
   1. Дуже важливо, щоб ви переконалися, що кваліфікаційний сертифікат VTL був виконаний для вашої установки та перевірений на належну роботу. Використання непідтримуваних HBA, драйверів тощо є поширеним джерелом проблем.
   2. Намагайтеся, щоб система Data Domain була заповнена менш ніж на 85%. Очищення файлової системи та інші операції виконуються швидше та ефективніше, якщо система має достатньо вільного диска для виконання цих важливих завдань.
   3. Спробуйте запланувати очищення файлової системи (також відоме як збирання сміття або очищення файлової системи) для виконання в той час, коли активні резервні копії не виконуються.
   4. Типовий графік очищення файлової системи є достатнім у більшості середовищ. Ознайомтеся з документом "Очищення розкладу на системі домену даних": Кращі практики 12089», щоб краще зрозуміти цей процес. Якщо ви все ще вважаєте, що є причина змінити розклад за замовчуванням, щоб очищення файлової системи працювало частіше, зверніться до служби підтримки домену даних для обговорення.
   5. Не плануйте, щоб реплікація перекривалася з активним вікном резервного копіювання VTL. Обидва процеси вимагають значних ресурсів і виконуються швидше, якщо виконувати їх окремо, а не одночасно.
   6. Ніколи не використовуйте шифрування, мультиплексування, попереднє стиснення або дедуплікацію на стороні клієнта з клієнтського BA (тобто NetWorker, TeraSAM), оскільки вони значно знижують коефіцієнт стиснення, отриманий у системі Data Domain. Виконуйте ці дії лише в системі Data Domain. Деякі програми резервного копіювання включають ці функції за замовчуванням (тобто HP Data Protector за замовчуванням використовує мультиплексування), тому переконайтеся, що всі вони вимкнені для вашої програми.
   7. Хоча система Data Domain може пропонувати більш високі обмеження в параметрах конфігурації (кількість потоків, регулювання, реплікація і так далі), використання більш помірних конфігурацій часто забезпечує найкращу загальну продуктивність. 
   8. Переконайтеся, що ви прочитали та зрозуміли всі сповіщення від системи Data Domain. Якщо ви не зрозуміли оповіщення, зателефонуйте в службу підтримки для уточнення.
   9. Не використовуйте пул за замовчуванням для всього. Створіть хоча б один інший пул і створіть всі стрічки в створених вами пулах. Якщо ви використовуєте реплікацію (або можете в майбутньому), важливо створити та використовувати від 5 до 10 контекстів реплікації (тобто пул VTL) для покращення продуктивності.
   10. Переконайтеся, що ваші конкретні компоненти сумісні з VTL.

2. Компоненти VTL

   1. Ініціатори:
      1. Необхідно, щоб порт ініціатора FC був призначений тільки для VTL-пристроїв Data Domain.
      2. Тільки ініціатори, які повинні обмінюватися даними з певним набором цільових портів VTL в системі Data Domain, повинні бути зоновані з цією системою Data Domain.
      3. Створіть корисний псевдонім для кожного ініціатора, якого ви зонуєте, і підключіться до системи Data Domain, бажано включивши ім'я хоста і порт в ім'я псевдоніма. 
      4. Використовуйте тільки зонування один в один; створюйте зони на комутаторі Fibre Channel, що складаються лише з одного ініціатора та однієї цілі на зону. 
   2. Слоти: 
   • Кількість слотів або дисків, які повинна мати бібліотека, визначається кількістю одночасних потоків резервного копіювання та відновлення. Кількість дисків також обмежена конфігурацією та загальними обмеженнями продуктивності вашої конкретної системи Data Domain. Кількість слотів зазвичай ґрунтується на тому, скільки стрічок використовується протягом циклу політики утримання.

   3. Точки доступу до картриджів:

      • Перегляньте документацію з інтеграції домену даних для вашої конкретної програми резервного копіювання, щоб визначити, чи потрібно емулювати точки доступу картриджів (CAP) для вашого конкретного середовища.

   4. Чейнджер:

      • На один VTL може бути тільки один чейнджер.
      • Найчастіше, модель чейнджера, яку вам слід вибрати, залежить від вашої конкретної комплектації:
        • Використовуйте емуляцію бібліотеки RESTORER-L180 під час використання програмного забезпечення Symantec Backup
        • Використання емуляції бібліотеки TS3500 при використанні платформи IBM System i
        • Ви також можете використовувати емуляцію бібліотеки TS3500 при використанні TeraSAM 6.2 на платформах AIX 6.1 і AIX 5.3.
        • Більшість інших інсталяцій повинні використовувати емуляцію бібліотеки L180 (не Symantec, не IBM system i)

   5. Стрічковий привід

      1. Автоматичний офлайн:  Якщо завантажена стрічка, накопичувач підключений до мережі. У цьому стані чейнджер не в змозі перемістити стрічку з приводу без попереднього вивантаження стрічки. Однак, якщо увімкнено Auto-offline, відбувається неявне вивантаження диска, і тому стрічку можна перемістити з диска, навіть якщо програма не виконала команду «Вивантажити». Цей параметр може бути корисним для певних програм і є глобальним для всієї служби VTL (один параметр для всіх дисків).
      2. Автоматичне виймання:  Якщо стрічку перемістити з накопичувача або слота в САР, вона надходить безпосередньо в сховище. Цей параметр може бути корисним для тих програм, які перевіряють, чи видалено стрічки з CAP. Вони зазнають невдачі під час операції "виймання" бібліотеки, якщо стрічки все ще знаходяться в CAP після тимчасової затримки. Автовиймання робить ці програми щасливими, тому що стрічки відразу зникають з CAP. Цей параметр також є глобальним для всієї служби VTL (один параметр для всіх дисків)
      3. Найкраще використовувати тільки один тип стрічкового приводу на одну бібліотеку.

   6. Цільові HBA

      1. Розгляньте можливість розподілу навантаження резервного копіювання на кілька портів FC у системі Data Domain, щоб уникнути вузьких місць на одному порту. 
      2. Перевірте швидкість кожного порту FC на перемикачі, щоб переконатися, що порт налаштований на потрібну швидкість.
      3. Встановіть для вторинних портів значення "none", якщо це явно не потрібно для вашої конкретної конфігурації.
      4. Налаштуйте драйвер основної операційної системи для постійного прив'язування LUN. Це дозволяє уникнути ситуацій, коли через зміну цілей потрібно переналаштовувати програмне забезпечення для резервного копіювання або операційну систему. 

• Робота VTL

  1. Слоти: Створіть достатню кількість слотів, щоб вони містили кількість створених вами стрічок. Створення декількох додаткових слотів не є проблемою, якщо це не надмірна кількість.
  2. Ковпачки
  3. Стрічки
     1. Створюйте лише стільки стрічок, скільки потрібно, щоб задовольнити ваші вимоги до резервного копіювання. Кількість початкових стрічок становить менше ніж удвічі більше дискового простору, доступного на реставраторі. Створення занадто великої кількості віртуальних стрічок може створити сценарій, коли система Data Domain може передчасно заповнитися та спричинити несподіваний збій у роботі системи. У міру того, як стає доступною глобальна статистика стиснення, додаткові стрічки можуть додаватися поступово. 
     2. Якщо система заповнюється на 100%, ви повинні видалити всі порожні стрічки, які можуть існувати в системі, а потім видалити достатньо даних, щоб потужність системи була нижчою за 80%. Щоб уникнути цього трудомісткого завдання, щоб запобігти виникненню повної системи події.
     3. У системі призначення реплікації ніколи не зчитуйте зі стрічки, яка реплікується.
     4. Завжди використовуйте унікальні стрічкові штрих-коди, навіть у різних басейнах.
     5. Завжди використовуйте один і той же стрічковий суфікс (розмір) для всіх басейнів. Якщо з якихось причин вам потрібно використовувати інший суфікс, як мінімум ви повинні зберігати той самий суфікс у межах басейну.
     6. Оптимальний розмір стрічок залежить від багатьох факторів, включаючи конкретний БА, що використовується, і характеристики даних, що резервуються. Загалом, краще використовувати більшу кількість менших стрічок, ніж меншу кількість великих, щоб контролювати використання диска та запобігати переповненню системи.
     7. Для TeraSAM рекомендується використовувати стрічки меншого розміру (тобто 30-50G), щоб допомогти швидше звільнити простір.

  4. Програми для резервного копіювання

     1. Переконайтеся, що ви використовуєте найбільший оптимальний розмір блоку для вашого бізнес-аналітика для максимальної продуктивності, працюючи з системою Data Domain. Оптимальна кількість залежить від багатьох факторів, таких як швидкість диска, кешування ОС і ваше конкретне програмне забезпечення для резервного копіювання. Перегляньте рекомендації постачальника та Посібники з інтеграції.
     2. Загалом, розмір стрічкового блоку, кратний 64K, забезпечує кращу продуктивність, але обов'язково ознайомтеся з найкращими практиками або посібниками з інтеграції для вашого конкретного програмного забезпечення (посилання див. нижче). Якщо ви отримуєте доступ до пристрою Data Domain з декількома резервними серверами, використовуйте найбільший розмір блоку, доступний для всіх серверів у середовищі (особливо в гетерогенному середовищі ОС).

• Групи доступу

  1. Нумерація пристроїв в межах кожної дискретної групи доступу VTL повинна починатися з LUN 0.
  2. Краще не змінювати конфігурацію групи доступу VTL під час великого навантаження на систему Data Domain.
  3. Рекомендується, щоб у вас був рівно один ініціатор на групу доступу.

• Статистика

  1. При використанні статистики кешу позначок файлів VTL скидання статистики слід виконувати перед завантаженням стрічок на диски. Якщо скидання статистики виконується після завантаження стрічок і доступу до них на стрічкових накопичувачах, команда vtl show detailed-stats може ввести в оману. У звіті кількість «безкоштовних» може бути більшою, ніж кількість «alloc», що є несподіваним, але нешкідливим у цьому випадку. Це викликано скиданням статистики накопичувачів під час їх використання; Скидання статистики – це не атомарна операція.
  2. Як правило, статистику слід скинути перед завантаженням стрічок на диски.