Оновлення!. У коментах один із читачів запропонував спробувати (можливо, він сам над ним працює), тому я додав розділ про це рішення. Ще я написав тому що процес сильно відрізняється від інших.
Якщо чесно, я здався і відмовився від (у разі, поки). Буду використовувати . Чому? Через зберігання! Хто б міг подумати, що я більше возитимуся зі сховищами, ніж із самим Kubernetes. Я використовую , тому що це недорого і продуктивність хороша, і з самого початку я розгортав кластери за допомогою . Я не пробував керовані сервіси Kubernetes від Google/Amazon/Microsoft/DigitalOcean тощо, тому що всьому хотів навчитися сам. А ще я економний.
Так що так, я витратив багато часу, намагаючись вирішити, яке сховище вибрати, коли прикидав можливий стек на Kubernetes. Я віддаю перевагу рішенням з відкритим вихідним кодом, і не тільки через ціну, але я вивчив пару-трійку платних варіантів з цікавості, тому що у них є безкоштовні версії з обмеженнями. Я записав кілька цифр з останніх тестів, коли порівнював різні варіанти і вони можуть зацікавити тих, хто вивчає зберігання в Kubernetes. Хоча особисто я поки що з Kubernetes розпрощався. Ще хочу згадати , в якому можна безпосередньо готувати томи Hetzner Cloud, але я його поки що не пробував. Я вивчав хмарні програмно-визначені сховища, тому що мені потрібна була реплікація та можливість швидко підключати постійні томи на будь-якій ноді, особливо у разі збою нод та інших ситуацій. Деякі рішення пропонують снапшоти на момент часу та off site бекапи, а це зручно.
Я протестував 6–7 рішень для зберігання:
Як я вже казав , протестувавши більшість варіантів зі списку, спочатку зупинився на OpenEBS. OpenEBS дуже просто встановлювати та використовувати, але, якщо чесно, після тестів із реальними даними під навантаженням його продуктивність мене розчарувала. Це опенсорс, і розробники на своєму завжди дуже допомагали, коли мені була потрібна допомога. На жаль, у нього дуже низька продуктивність, порівняно з іншими варіантами, тому довелося провести тести заново. Зараз у OpenEBS 3 движки сховища, але я публікую результати бенчмарку для cStor. Поки що у мене немає цифр для Jiva та LocalPV.
У двох словах, Jiva трохи швидше, а LocalPV взагалі швидкий, не гірший, ніж бенчмарк диска. Проблема з LocalPV полягає в тому, що доступ до цього можна отримати тільки на тій ноді, де він був підготовлений, а реплікації зовсім немає. У мене були деякі проблеми з відновленням бекапу через на новому кластері, тому що імена нід відрізнялися. Якщо говорити про бекапи, у cStor є , З яким можна робити off site бекапи снапшотів на момент часу, що зручніше, ніж бекапи на рівні файлів з Velero-Restic. Я написав , щоб було простіше керувати бекапами та відновленнями з цим плагіном. В цілому, мені дуже подобається OpenEBS, але його продуктивність…
У Rook теж відкритий вихідний код, і від інших варіантів у списку він відрізняється тим, що це оркестратор сховища, який виконує складні завдання з управління сховищем з різними бекендами, наприклад , та інші, що значно спрощує роботу. У мене були проблеми з EfgeFS, коли я пробував його кілька місяців тому, так що я тестував, в основному, з Ceph. Ceph пропонує не тільки сховище блоків, а й сховище об'єктів, сумісне з S3/Swift та розподіленою файловою системою. Що мені подобається в Ceph, так це можливість поширити дані тома по кількох дисках, щоб він міг використовувати більше дискового простору, ніж вміщується на одному диску. Це зручно. Ще одна класна функція - коли додаєш до кластера диски, він автоматично перерозподіляє дані по всіх дисках.
У Ceph є снапшоти, але, наскільки я знаю, їх не можна використовувати безпосередньо в Rook/Kubernetes. Щоправда, я цього не заглиблювався. А ось off site бекапів немає, так що доведеться використовувати щось з Velero/Restic, але там тільки бекапи на рівні файлів, а не снапшоти на момент часу. Зате в Rook мені дуже сподобалася проста робота з Ceph – він приховує майже всі складні штуки та пропонує інструменти, щоб спілкуватися з Ceph безпосередньо для усунення несправностей. На жаль, на стрес-тесті томів Ceph у мене постійно виникала через яку Ceph стає нестабільним. Поки незрозуміло, чи баг це в самому Ceph або проблема в тому, як Rook керує Ceph. Я почаклував з налаштуваннями пам'яті, і стало краще, але до кінця проблема не вирішилася. У Ceph непогана продуктивність, як видно в бенчмарку внизу. А ще має хорошу панель моніторингу.
Мені дуже подобається Longhorn. На мою думку, це перспективне рішення. Щоправда, самі розробники (Rancher Labs) визнають, що для робочого середовища він поки не годиться, і це видно. У нього відкритий вихідний код і непогана продуктивність (хоча її оптимізацією вони ще не займалися), але тому дуже довго підключаються до поду, і в гірших випадках це займає 15-16 хвилин, особливо після відновлення великого бекапа або апгрейду робочого навантаження. У нього є снапшоти та off site бекапи цих снапшотів, але вони поширюються тільки на томи, тому вам все одно потрібно буде щось на кшталт Velero для бекапу інших ресурсів. Бекапи та відновлення дуже надійні, але непристойно повільні. Серйозно, просто дуже повільні. Використання процесорних ресурсів та завантаження системи часто підскакують під час роботи із середнім обсягом даних у Longhorn. Є зручна панель моніторингу, щоб керувати Longhorn. Я вже казав, що мені подобається Longhorn, але над ним треба добре попрацювати.
StorageOS – це перший платний продукт у списку. Він має версію для розробників з обмеженим розміром керованого сховища в 500 ГБ, але кількість вузлів, на мою думку, не обмежена. У відділі продажів мені сказали, що ціна починається від $125 на місяць за 1 ТБ, якщо я вірно запам'ятав. Там є базова панель моніторингу та зручний CLI, але з продуктивністю коїться щось дивне: у деяких бенчмарках вона цілком пристойна, але у стрес-тесті томів швидкість мені зовсім не сподобалася. Загалом не знаю, що й сказати. Тому я особливо не розбирався. Тут немає off site бекапів і доведеться також використовувати Velero з Restic для бекапу томів. Дивно, адже продукт платний. А ще розробники не горіли бажанням спілкуватися у Slack.
Про Robin я довідався на Reddit від їхнього техдиректора. Раніше я про нього не чув. Може тому, що шукав безкоштовні рішення, а Robin платне. У них досить щедра безкоштовна версія зі сховищем на 10 ТБ та трьома нодами. Загалом продукт цілком гідний і з приємними функціями. Там чудовий CLI, але найкрутіше — це те, що можна робити снапшот і бекап всієї програми (у селекторі ресурсів це називається релізами Helm або «flex apps»), включаючи томи та інші ресурси, тому можна обійтися без Velero. І все було б чудово, якби не одна маленька деталь: якщо відновлювати (або «імпортувати», як це називається в Robin) додаток на новому кластері – наприклад, у разі відновлення після аварії – відновлення, звичайно, працює, але продовжити бекап програми не можна. У цьому релізі це просто неможливо і розробники підтвердили. Це, м'яко кажучи, дивно, особливо якщо врахувати решту переваг (наприклад, неймовірно швидкі бекапи та відновлення). Розробники обіцяють все виправити наступного релізу. Продуктивність, загалом, хороша, але я помітив дивність: якщо запустити бенчмарк безпосередньо на томі, підключеному до хоста, швидкість читання набагато вища, ніж у тому томі, але зсередини пода. Всі інші результати ідентичні, але в теорії різниці не повинно бути. Хоч вони над цим і працюють, я засмутився через проблему з відновленням і бекапом — мені здалося, що я нарешті знайшов відповідне рішення, і я навіть готовий був платити за нього, коли мені знадобиться більше простору або більше серверів.
Тут мені особливо нема чого сказати. Це платний продукт, однаково класний та дорогий. Продуктивність просто диво. Поки що це найкращий показник. У Slack мені сказали, що ціна починається від $205 на місяць за ноду, як зазначено у гуглівському GKE Marketplace. Не знаю, чи буде дешевшим, якщо купувати напряму. У будь-якому випадку, я не можу собі таке дозволити, так що я був дуже і дуже розчарований, що ліцензія розробника (до 1 ТБ і 3 ноди) практично марна з Kubernetes, якщо ви не задовольняєтеся статичною підготовкою. Я сподівався, що корпоративна ліцензія автоматично знизиться до рівня розробника наприкінці пробного періоду, але не сталося. Ліцензію розробника можна використовувати лише безпосередньо з Docker, а налаштування в Kubernetes дуже громіздке та обмежене. Я, звичайно, віддаю перевагу опенсорсу, але якби у мене гроші, я б точно вибрав Portworx. Поки що його продуктивність просто не зрівняється з іншими варіантами.
Я додав цей розділ після публікації посту, коли один читач запропонував спробувати Linstor. Я спробував і мені сподобалося! Але треба ще покопатись. Наразі можу сказати, що продуктивність непогана (результати бенчмарку додав нижче). По суті, я отримав ту ж продуктивність, що і для диска безпосередньо, без витрат. (Не питайте, чому у Portworx цифри кращі, ніж бенчмарк диска безпосередньо. Поняття не маю. Магія, напевно.) Так що Linstor поки що здається дуже ефективним. Встановлювати його не те що складно, але не так легко, як інші варіанти. Спочатку мені довелося встановити Linstor (модуль ядра та інструменти/сервіси) та налаштувати LVM для thin provisioning та підтримки снапшотів за межами Kubernetes, безпосередньо на хості, а потім створити ресурси, необхідні для використання сховища з Kubernetes. Мені не сподобалося, що він не заробив CentOS і довелося використовувати Ubuntu. Не страшно, звичайно, але трохи дратує, тому що в документації (вона, до речі, чудова) згадується кілька пакетів, які неможливо знайти у вказаних репозиторіях Epel. У Linstor є снапшоти, але не off site бекапи, тому тут знову довелося використовувати Velero з Restic для бекапу томів. Я б віддав перевагу снапшотам замість бекапів на рівні файлів, але це можна стерпіти, якщо рішення буде продуктивним і надійним. У Linstor є відкритий вихідний код, але є платна підтримка. Якщо я правильно розумію, його можна використовувати без обмежень, навіть якщо ви не маєте договору на підтримку, але це треба уточнити. Я не знаю, наскільки Linstor перевірений для Kubernetes, але сам рівень зберігання знаходиться за межами Kubernetes і, зважаючи на все, рішення з'явилося не вчора, так що, напевно, вже перевірено в реальних умовах. Чи є тут рішення, яке змусить мене передумати та повернутися до Kubernetes? Не знаю не знаю. Потрібно ще поколупатися, вивчити реплікацію. Подивимося. Але перше враження гарне. Я абсолютно хотів би використовувати свої власні кластери Kubernetes замість Heroku, щоб отримати більше свободи і навчитися новому. Якщо Linstor встановлюється не так просто, як інші, скоро я напишу про це пост.
Бенчмарки
На жаль, я зберіг мало записів про порівняння, тому що не подумав, що про це писатиму. У мене є тільки результати базових бенчмарків fio і тільки кластерів з одним вузлом, так що для реплікованих конфігурацій у мене поки немає цифр. Але за цими результатами можна отримати зразкове уявлення про те, чого чекати від кожного варіанту, тому що я порівнював їх на однакових хмарних серверах, 4 ядра, 16 ГБ оперативної пам'яті, з додатковим диском на 100 ГБ для томів, що тестуються. Я прогнав бенчмарки тричі для кожного рішення і обчислив середній результат плюс скидав налаштування сервера для кожного продукту. Все це зовсім не науково, просто щоб ви зрозуміли загалом. В інших тестах я копіював 38 ГБ фото та відео з тому і на тому, щоб потішити читання та запис, але цифри, на жаль, не зберіг. Якщо коротко: Portworkx був набагато швидше.
Для бенчмарку томів я використав цей маніфест:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: dbench
spec:
storageClassName: ...
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
name: dbench
spec:
template:
spec:
containers:
- name: dbench
image: sotoaster/dbench:latest
imagePullPolicy: IfNotPresent
env:
- name: DBENCH_MOUNTPOINT
value: /data
- name: FIO_SIZE
value: 1G
volumeMounts:
- name: dbench-pv
mountPath: /data
restartPolicy: Never
volumes:
- name: dbench-pv
persistentVolumeClaim:
claimName: dbench
backoffLimit: 4Спочатку я створив том із відповідним класом сховища, а потім запустив завдання з fio за кадром. Я взяв 1 ГБ, щоб прикинути продуктивність і не чекати надто довго. Ось результати:
Я виділив найкраще значення для кожного показника зеленим, а найгірше червоним.
Висновок
Як бачите, в більшості випадків Portworx показав себе краще за інших. Але для мене він дорогий. Я не знаю, скільки коштує Robin, але там чудова безкоштовна версія, тому, якщо вам потрібен платний продукт, можете спробувати (сподіваюся, вони скоро виправлять проблему з відновленням та бекапами). З трьох безкоштовних у мене найменше проблем виникло з OpenEBS, але продуктивність у нього ні до біса. Жаль, я не зберіг більше результатів, але, сподіваюся, вам допоможуть наведені цифри та мої коментарі.
Джерело: habr.com