Невелика оцінка впливу рівнів Сache на продуктивність введення/виводу в EMC VNXe3200

Введення

Нещодавно і не надовго до мене в руки потрапила система зберігання даних (СЗД) VNXe3200, яка була анонсована компанією EMC2 для замовників 5 травня 2014 року. VNXe3200 — це друге покоління entry-level Unified СГД компанії EMC2. У даній моделі з'явилися технології доступні раніше тільки на більш старших і більш дорогих midrange масивах. Зокрема технологія FastCachе — тобто кеш другого рівня на SSD-дисках, який постає в розріз між традиційним кешем в оперативній пам'яті контролера СГД (в термінології EMC — Storage Processor) та власне дисками. Я вирішив перевірити, як ця технологія впливає на продуктивність введення/виводу на наймолодших СГД компанії EMC2.

На відміну від старших СГД EMC VNX, в даній моделі як блочний, так і файловий доступ реалізований на одних і тих же контролерах (SP). СГД в базі має на кожен SP по 4 мідних порту 10Gbit/s (10GBASE-T), через які реалізується підключення клієнтів/хостів за протоколами CIFS/SMB, NFS і iSCSI. Порти ці з autonegotiation 10G/1G/100 мб в секунду. LДополнительно в кожен SP можна поставити плату на 4 порти 8Gb/s FC. Тестувати було вирішено за допомогою IOMETER. В цьому допомогла, в тому числі, ось ця стаття з Хабра: посилання.

Опис стенду і тестів

З профілем навантаження мудрувати не став, взяв стандартний Database pattern (Intel/StorageReview.com).



Для тестування був узятий Blade BL460c G7 сервер (один CPU 6 ядер + HT, 24GB ОЗП), підключений по FC до СГД через вбудовані в блэйдовую кошик FC комутатори c портами на 4Gbit/s. На сервері встановлена OS Windows 2012 R2 c завантаженням по FC з VNXe3200 (boot from SAN). До сервера був підключений, так само по FC, тестовий тому (LUN) розміром 1Tb c файловою системою NTFS. На СГД зібраний дисковий пул з 10 дисків (SAS 2,5" 10k RPM 600Gb) з двома приватними рейд групами (RG) в межах, які мають конфігурацію Raid5 (4+1). Так само на масиві з двох SSD дисків (2,5" 100Gb) зібраний FastCache (дзеркальна пара Raid1).

Тестування проводилося в три етапи.

1) За допомогою IOMETER створюється маленький тестовий файл розміром в 2Gb, в розрахунку що він повністю поміститися в Cache SP на СГД.
2) Попередній тестовий файл віддалявся і створюється тестовий файл розміром ~50Gb, в розрахунку на те, що він не поміститься в Cache SP, але зате повністю увійде в FastCache.
3) Попередній тестовий файл віддалявся і створюється тестовий файл розміром ~500Gb, в розрахунку на те, що він не поміститися ні в один з кешей і при 100% рандомном доступі практично дасть продуктивність наявних шпиндельних дисків.
Тести були налаштовані таким чином, щоб перед кожним проходом був «розігрів» в 10 хвилин, потім тест 20 хвилин. Кожен тест виконувався з експоненціальним зростанням потоків введення/виводу (1-2-4-8-16) на кожен з 12-ти workers (6 ядер + HT). При цьому, крім власне видаються СГД IOPS-ів, було цікаво комфортне середній час відгуку < 10 мілісекунд (ms). Відразу обмовлюся, що приведу «картинки» з графіками з інтерфейсу VNXe3200, але кількісні показники на них збігаються з результатами в csv файлах IOMETER, які будуть наведені посиланнями.

Далі трохи розрахунків.

Якщо не враховувати вплив cache на ввід/вивід, то для дисків SAS 10k EMC пропонує вважати за 150 IOPS на диск. У нас у сумі на бэкенде при 10 дисках повинно вийти 150*10=1500 IOPS. Якщо ми врахуємо нашу навантаження r/w 67%/33% і втрати на роботу з CRC у Raid5, то отримаємо наступне рівняння з однією невідомою. 1500=X*0.33*4+X*0.67, де X це у нас ті IOPS, які отримають хости з наших дисків. A 4 — це розмір «пенальті» для Raid5. Тобто в Raid5 для виконання однієї операції запису, що приходить з хоста, потрібно 4 операції вводу/виводу на бэкенде (на дисках СГД). Для Raid1/Raid10 значення пенальті — 2, для Raid6 — 6. У підсумку отримуємо X=1500/1,99= ~750 IOPS. На практиці я помічав що досягаються максимальні значення бувають більше розрахункових в 1,5-2 рази. Значить в піковому навантаженні можемо отримати 1125-1500 IOPS з наших 10 SAS дисків.

Перейдемо власне до тестів та їх результатів

Тест 1
Як і передбачалося тестовий файл практично повністю вмістився у cache SP.



При тестуванні ми отримали наступну картину за IOPS і влучаннями запитів вводу/виводу в кеш. Тут потрібно обмовитися про те, що даний графік показує на самому ділі все IO проходять через SP. Частина з них відпрацьовується з SP cache (hit), частина «пролітає» SP cache на крізь (miss) та відпрацьовується або з FastCache, або з шпиндельних SAS дисків.



При цьому середній час відгуку при максимальній кількості потоків в IOMETER (12 workers * 16 потоків IO = 192 потоку вводу/виводу) склало ~8 ms. Файл з результатами IOMETER тут. Перший тест був проведений з збільшенням кількості потоків на worker від 4 до 32 (4-8-16-32). Помітив пізно в чому каюся, але переробляти вже було колись.

Тест 2
В процесі тесту тестовий файл ~50GB майже повністю вмістився в FastCache, як і очікувалося.



В результаті вийшла наступна картинка, на якій видно, що практично всі запити пролітають повз SP cache.



Середній час відгуку на 192 потоках було ~12.5 ms. Комфортне час відгуку було на 8 потоках на worker ~8 ms (96 потоків IO). Файл з результатами IOMETER тут.

Тест 3
В процесі тесту введення/виведення рандомно «бігав» по всім ~500Gb і жоден cache в теорії тут допомогти не міг, що і видно на практиці за графіками нижче.




В результаті, як і планувалося, отримали продуктивність 10 SAS шпинделів в Raid5. При цьому 4 перших у СГД диска з використаних в пулі — це так званий VaultPack. Тобто частину від цих перших дисків (~82,5 GB з кожного) «відрізана» під системні потреби.



Середній час відгуку на 192 потоках було досить великим і склало ~149 ms. Комфортне час відгуку було при 1 потоці на worker (12 потоків IO) ~10 ms. Файл з результатами IOMETER тут.

Підсумки

Прийнято вважати, що активні («гарячі») дані становлять не більше 3-5% від загального обсягу даних, ще 15-20% «теплі» дані, а весь інший обсяг ~75-80% буває рідко затребуваний хостами (серверами/користувачами).

Тестування показало, що всі типи Cache у СГД в цілому позитивно впливають не тільки на загальну продуктивність масиву. Але і на середній час відгуку операцій вводу/виводу, особливо під високим навантаженням. А враховуючи вище сказане, кеш як раз будуть потрапляти найбільш «гарячі» дані.

Можна зробити висновок, що FastCache в EMC VNXe3200 буде цілком вдалим і корисним доповненням навіть при невеликих конфігураціях. Враховуючи, що процес його «розігріву» (попадання даних в кеш) відбувається досить швидко.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.