Кальмар чи інші HTTP-кеші з кеш-пам'яткою SSD?


9

Я розглядаю можливість створення кешу кальмарів (або, можливо, лаку) для системи з накопичувачами SSD.

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

Припустимо, що я можу поставити 7 SSD в конфігурацію RAID. (Є деякі випадки, які дозволять мені спакувати набагато більше)

Питання щодо впровадження:

  • Чи варто використовувати RAID0? (Я очікую, що з часом привід вийде з ладу, тому це здається небезпечним.)

  • Чи варто використовувати RAID10? (Це вдвічі зменшує слід мого диска, що дорого коштує.)

  • Чи варто використовувати RAID5? (Відомо, що SSD мають "погану" ефективність запису та обмеження запису, а всі додаткові записи паритету можуть значно уповільнити це.)

  • Чи варто просто ставитися до кожного диска як до власного сховища даних кальмарів? (наскільки добре кальмари обробляють кілька сховищ даних? І що станеться, якщо / коли не вдасться?)

  • Чи слід ігнорувати сховища даних і просто ввести SSD у великі розділи SWAP і дозволити linux VM робити це? (здається неохайним)

Будемо дуже вдячні за будь-які поради людей, які використовують SSD у виробничих середовищах. (особливо якщо ви використовуєте їх для кешів HTTP)


+1 за цікаве запитання: я ніколи не замислювався над тим, щоб робити диски просто у великий розділ для заміни
Боб

Так, безумовно, цікаво ... хоча я сильно схильний не потрапляти в пропускну здатність SSD і просто додати більше оперативної пам’яті за ці гроші.
Оскар Дувеборн

На жаль, слід, який мені потрібен кеш, не вписується в оперативну пам'ять. У мене вже є кеші кальмарів, які підтримуються оперативною пам’яттю, для цих об’єктів.
Joel K

Відповіді:


8

Ми використовували лак на ssd-накопичувачах останні 9 місяців, він надзвичайно добре працював для нас. Раніше ми використовували кеш-пам'ять лише для кешу із шаром коропа. Це спрацювало, але фрагментація пам’яті була справжньою проблемою, що вимагала частого перезавантаження. Squid 2.x також використовуватиме лише одне ядро, що робить його досить неефективним у поточному обладнанні.

Для нашого веб-сайту, який дуже сприймає кеш, ми бачимо приблизно 10% використання процесора на 8-ядерній машині, що обслуговує 100 Мбіт / с трафіку. У наших тестах у нас не вистачає пропускної здатності, перш ніж ми потрапимо на ліміти процесора з 2 портами 1 Гбіт.

У мене є поради щодо запуску лаку з кешам ssd.

  • Випадкове виконання запису дійсно має значення. Ми спробували кілька постачальників для ssd накопичувачів, перш ніж сісти на Intel x-25m. Ми бачили деякий пост у розмірі всього .1 Мб / с для 4-х випадкових записів, ми отримуємо 24 Мб / с 4 к випадкових записів з x-25m.

  • Рейд0. Кеш в 2.0 не є стійким, тому не потрібно турбуватися про надмірність. Це робить перезавантаження шкоди, але це рідко. Ви можете виконувати такі дії, як завантаження нового конфігурації та очищення об'єктів без перезавантаження.

  • mmap-режим. Кеш лаку можна mmap'd до файлу або використовувати простір swap. Використання swap для нас не працює добре, воно, як правило, використовує більше пропускної здатності вводу-виводу, щоб обслуговувати ту саму кількість трафіку. У коді linux для чотирьох секторів перечитано, ми написали патч, щоб видалити це, але не спробували його у виробництві.

  • Планувальник термінів. З 2.6.28+ це знає ssd і працює добре. Ми спробували noop, але виявили, що термін закінчується справедливішим, оскільки пропускна здатність вводу-виводу стає обмеженою.

  • Вимкнути читання вперед. Оскільки немає затримки обертання, немає сенсу читати зайві дані лише тому, що вони вам можуть знадобитися. i / o пропускна здатність є цінним для цих речей.

  • Виконати 2.6.28+. mmap багато місця на Linux дає менеджеру пам’яті гарне тренування, але розділені патчі lru дуже допомагають. Використання kswapd cpu сильно впало, коли ми оновили.

Ми розмістили наш файл vcl, а також декілька інструментів, які ми використовуємо з лаком у тексті посилання . В vcl також входить акуратний хак, що реалізує дуже швидкий сервер geoiplookup на основі бази даних maxmind.


1

Я не використовую SSD в кеш-пам'яті HTTP, але можу зробити такі спостереження:

Не всі SSD є рівними, тому ви повинні бути дуже обережними у виборі гідних. FusionIO робить SSD-накопичувачі, підтримувані PCIe, які є справді висококласними виконавцями (з відносно низькою ємністю), але затратні. SSC-накопичувачі X25-E SLC від Intel дуже добре працюють і є більш доступними, але все ще низькою ємністю. Робіть свої дослідження! Я точно можу порекомендувати варіанти SLC X25-E, оскільки я їх використовую у виробничих системах.

Існують і інші SSDS, які можуть давати вам велику швидкість послідовного читання / запису, але важливим для чогось, наприклад, кеша є випадковий IO, і багато SSD мають приблизно таку ж випадкову продуктивність, що і спінінг-диски. Завдяки ефектам посилення запису на SSD диски, що обертаються, часто будуть краще. Багато SSD мають контролери низької якості (наприклад, старші контролери JMicron), які можуть постраждати від значно погіршеної роботи в деяких ситуаціях. Anandtech та інші сайти роблять хороші порівняння з такими інструментами, як іометр, перевірте це.

І, звичайно, SSD невеликі. Intel X25-E, який я б сказав, є найкращим SATA SSD, який я бачив, лише у 32 та 64 ГБ варіантах.

Для рівнів RAID все ще застосовуються стандартні примітки про ефективність RAID. Запис на RAID 5, як правило, передбачає зчитування блоку даних, який ви збираєтеся змінити, зчитування блоку паритету, оновлення паритету, запис блоку даних і написання паритету, тому воно все одно буде давати гірші показники, ніж інші RAID рівнів, навіть із SSD. Однак при таких накопичувачах, як X25-E, які мають такі високі показники випадкової вводу-виводу, це, мабуть, має значення менше, оскільки це все ще перевершує випадковий IO на спінінг-дисках для масиву аналогічного розміру.

З того, що я бачив, пропускна здатність контролера RAID занадто рано насичується, щоб отримати максимальну користь із 7 дискового набору RAID, принаймні, що стосується послідовності продуктивності. Ви не можете отримати більше ніж приблизно 800 Мб / с із поточних моделей контролерів SATA (3ware, areca тощо). Маючи більше менших масивів через декілька контролерів (наприклад, декілька RAID1, а не один RAID10), це покращить це, хоча індивідуальна продуктивність кожного масиву постраждає.

Щодо кешу HTTP, я думаю, вам краще послужити пристойним набором спінінгових дисків та великою кількістю оперативної пам’яті. Об'єкти, які часто отримують доступ, залишатимуться в кеш-пам'яті - або у внутрішньому кеші кальмарів, або у кеш-програмі fs. Просто надання машині більше оперативної пам’яті може значно зменшити завантаження диска завдяки цьому. Якщо ви використовуєте великий кеш кальмарів, ви, мабуть, захочете багато місця на диску, а високоефективні SSD-диски все ще мають відносно низьку ємність.


Навіть X25-M корисні
Pyrolistic

Я зробив домашнє завдання і знаю, щоб уникнути JMicrons. Я здебільшого розглядав X25-Ms (Intel MLC) і, можливо, новішу (не JMicron) версію OCZ Vertex.
Джоель К

Уау, вершина ocz має нижчий максимальний випадковий запис, ніж навіть х25-м !!!
Піролістичний

1

Я не дуже знайомий з накопичувачами SSD, але можу говорити про тип архітектури, яку я використав, яка може допомогти вирішити деякі ваші проблеми.

Брати і сестри

У моєму випадку я створив чотири сервери з 16 ГБ оперативної пам’яті кожен. Я встановив 9 ГБ як кеш-пам'ять пам'яті для використання кальмарів. Я налаштував їх як набір братів і сестер, щоб запит на один сервер запитував інші, перш ніж шукати дані. Загалом у мене було 36 Гб кешу пам'яті. Мені б не досягли більше чотирьох братів і сестер, оскільки зв’язок між ними починає вщухати.

VIP-персони

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

Діти

Я встановив свій веб-додаток для запиту локального сервера Squid, який працює на 127.0.0.1. Потім налаштував батьків цього екземпляра Squid як VIP. Це дозволяє дуже швидко вийти з ладу у випадку, коли весь VIP знизиться. Якщо батьки не відповідають, дитина запитує послуги безпосередньо. Це також зручно, якщо ви використовуєте один сервер Squid і не маєте VIP. Звичайно, якщо локальний екземпляр Squid на вашому веб-сервері знизиться, все переграє.

Кальмари самі

Я не дуже дивився на 3.0, але 2.x все ще є однопоточним. У якийсь момент у вас закінчуються буфери процесора або TCP. Я б поширював кеш-пам'ять на 2-3 менших поля, якщо це можливо. Крім того, ви можете захотіти планувати розподіл ферм для кальмарів у майбутньому, якщо бачите, що система зростає.

У будь-якому випадку удачі з вашою збіркою SSD. Мені цікаво почути, як це виходить, оскільки я, мабуть, піду цим маршрутом у майбутньому.


0

Чому ви навіть роздумуєте про рейд 10 або 5. Ви хочете тут виступити. Вам байдуже, чи диски просто йдуть вниз, оскільки це лише кеш-пам'ять.

Просто використовуйте рейд 0 або тримайте їх окремо. Я думаю, що окремо було б краще, оскільки несправність диска не призведе до зменшення всього кешу.


Наскільки добре відновлюється кальмар, якщо випадає єдиний сховище даних? (очевидно, що мені потрібно перевірити це) RAID5 - це компроміс, якщо Squid не є витонченим у відмові магазину даних.
Джоель К

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.