PowerScale: Як підвищити продуктивність експорту системного журналу для продуктивності аудиту PowerScale Isilon

Відставання в експорті аудиту системи ніколи не наздоганяється. Побачити це просто, через розподілений характер аудиту баз даних і завантаженість OneFS. 

Методом для цього є:

1. Перегляньте останні позначки часу в отриманих повідомленнях системного журналу аудиту.
2. Якщо дати аудиторських записів відстають від вашої дати в реальному часі, вона позаду.
3. Якщо кожен день записи здаються послідовним відставанням, або іноді відстають, а іноді наздоганяють, це означає, що кластер і системний журнал знаходяться у відносному паритеті. Зазвичай, це прийнятно. Наскільки «відставати» прийнятно, залежить від навколишнього середовища.
4. Якщо з кожним днем продуктивність все більше і більше відстає і ніколи не наздоганяє, може виникнути необхідність зменшити навантаження на місцевий аудит на стороні Ісілону. 

Аудит працює в черзі FIFO (перший вхід, перший вийшов) на всіх вузлах.
Якщо дані аудиту експортуються швидше, ніж вони проковтуються, черга оновлюється.

Якщо вузол #1 поглинає і записує 1000 аудиторських подій в секунду, але здатний експортувати з цього вузла тільки 500 подій в секунду, і ця швидкість справедлива для 24x7x365, це означає, що для цього одного єдиного вузла Isilon:

• Через 1 с спостерігається відставання в 500 найменувань
• Через 1 хвилину 30 000 найменувань
• Через 1 годину 1 800 000 найменувань
• Через 1 день 43 200 000 найменувань

Однак, якщо навіть протягом половини годин дня система зможе споживати вдвічі дешевше або експортувати вдвічі швидше, відставання скоротиться вдвічі.

Оскільки розгортання системного журналу, яке використовувалося до 9.4, повідомлялося про випадки клієнтів із серйозними відставаннями аудиту відносно рідко.

Навіть з альтернативою ЦСЄ, яка є більш ефективною, ніж система до 9.4, іноді з'являються повідомлення про відставання через місцевий «дизайн аудиту» та показники поглинання.

Може бути важко зрозуміти, який обсяг є, поки аудит не пройде. Завдяки більш ефективній Центральній та Східній Європі ви також можете розгорнути додаткові цільові машини в Центральній та Східній Європі, а потім працювати зі стороннім постачальником, який «збирає» ці дані для перевірки аудиторських записів.

Додаткові ЦСЄ дозволяють стороні Ісілон більш ефективно експортувати. Кожен окремий вузол Isilon може одночасно підключатися до трьох (3) унікальних машин CEE.

Syslog відрізняється. Кожна визначена ціль системного журналу в настройках аудиту отримує кожну експортовану подію аудиту.
Уявіть, що з черги надсилається одна зареєстрована аудиторська подія. Якби існував один цільовий сервер системного журналу, вузол Isilon з цим елементом черги надсилав би цей запис через порт UDP 514 на основі 1:1 до цього єдиного цільового системного журналу.
Якщо було додано іншу цільову систему системного журналу, що дає дві суми, цей вузол Isilon замість цього повинен надіслати той самий елемент однієї черги обом унікальним цілям системного журналу. Це ефективно подвоює частину робочого навантаження в вузлі Ісілон. Три цілі системного журналу потроїли б частину роботи тощо.

Крім того, немає відповідних конфігурацій, які можна налаштувати для попередньої версії 9.4 OneFS у системному журналі, що стосується аудиту.

У ЦСЄ ви можете зменшити відставання, проводячи менше аудитів або додаючи більше цільових ЦСЄ та більше можливостей постачальників 3-ї партії за межами цих ЦСЄ.

За допомогою системного журналу ви можете зменшити відставання, лише менше перевіряючи з часом.

Оновіться до OneFS 9.4 або новішої версії.

Під час оптимальних та контрольованих лабораторних тестів експорт Syslog for Audit з випусками OneFS 9.4 показав покращення продуктивності ~ 300%.

Оновлення до версії OneFS 9.4+, ймовірно, покращить продуктивність експорту системи аудиту.

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

Якщо продуктивність системного журналу для експорту, навіть на OneFS 9.4+, не може подолати постійну або, здавалося б, непрацездатну чергу, через кілька тижнів після оновлення зверніться до служби підтримки для перевірки.
Єдиний спосіб зменшити кількість перевірених подій в секунду і на вузол - це налаштувати те, як і що перевіряється.

Там, де експорт системних журналів правильно "витікає" з кластера Isilon, подальша оптимізація виходить за рамки Isilon Support:

• Перегляньте дизайн аудиту за допомогою системних інженерів Dell. Подумайте, як ваші кінцеві користувачі (людські або автоматизовані) потрапляють до кластера в першу чергу, щоб виконувати зареєстровані дії аудиту.
• Збалансуйте робочі процеси та обсяг зареєстрованих дій у всіх вузлах Isilon більш однаково: Усі записані дії записуються лише для аудиту та експортуються з вузла, до якого підключено користувача.
• Якщо у вашому Isilon є двадцять вузлів, але лише п'ять приймають з'єднання протоколів, то 100% цих дій аудиту відбуватимуться лише на цих п'яти вузлах.
• Розгляньте можливість перегляду всього розгортання, щоб переконатися, що загальний обсяг усіх дій протоколів розподілений по якомога більшій кількості фізичних вузлів. Це розподіляє загальне навантаження аудиту на якомога більшу кількість вузлів.
• Розгляньте рішення на основі Центральної та Східної Європи як альтернативу.
• Подумайте про зменшення обсягу та обсягу того, що перевіряється. Не виходьте далеко за рамки організаційних або нормативних вимог. 
• Співпрацюйте з системною інженерією Dell для подальших обговорень.