Мы разрабатываем новую кластерную архитектуру для нашего веб-сервиса и планируем использовать хранилище объектов Ceph и кубернеты для наших сервисов. для оптимизации наших серверов У нас есть разные варианты:
Используйте одинаковые серверы и запускайте Ceph и наши службы на всех из них и управляйте с помощью кубернетов.
Как и выше, используйте идентичные серверы, но пометьте некоторые из них как Ceph и не запускайте на них службы.
Используйте два типа серверов: один оптимизирован для io, а другой - для процессора. Затем запустите Ceph на io и сервисы на CPU. и управляй ими с кубернетами
Как и выше, с двумя отдельными серверами, но не используйте кубернеты для серверов io и позвольте ceph обрабатывать все (не проще ли не использовать кубернеты для нашего кластера Ceph?)
Я знаю, что идентичные серверы имеют преимущества лучшего масштабирования. С другой стороны, наличие двух типов серверов позволяет нам оптимизировать каждый из них. Какое лучшее решение?
Что следует учитывать:
Если вы используете вращающиеся диски, вы можете захотеть иметь отдельные диски для Ceph и для случайных задач Kubernetes. Таким образом, случайный ввод-вывод из задач Kubernetes не нарушает последовательность доступа Ceph (особенно для записи и чтения большого объема). Очевидно, вы можете сделать это с помощью (2), (3) или (4). Но вы также можете сделать это с помощью своего варианта (1), если у вас есть несколько дисков на ваших серверах (JBOD), и каждый диск выделяется либо для Ceph, либо для Kubernetes, но не для обоих (или если вы используете отдельную загрузочную флешку для Kubernetes и т. ..)
Если ваши серверы, оптимизированные для ЦП, поставляются с большим загрузочным диском, вы можете в конечном итоге почувствовать, что это хранилище застряло, потому что задания по обслуживанию не используют его все, и позже захотите запустить Ceph на этих узлах, чтобы отключить это хранилище. Но если это маленький диск / ssd, то вам может быть все равно.
Будет некоторая неопределенность в том, сколько серверов вам нужно. (например, рост, сбои, неточные оценки нагрузки). Из-за этой неопределенности вам приходится покупать больше. Перекупленность хуже с 2 SKU вместо 1 SKU. А потом, когда ваши потребности изменятся, будет сложнее перепрофилировать серверы. Такого рода услуги (1) или (2).
С точки зрения безопасности вам может быть удобнее, если обслуживающие задания выполняются не на том же компьютере, что и ваше хранилище. Это более важно, если у вас есть множество разных рабочих мест, которым доверяют в разной степени.
Я не уверен, какую «оптимизацию» вы хотите сделать для своих серверных SKU. Выбирать SKU, которые точно подходят для одного модуля, не рекомендуется. У вас должны быть модули меньшего размера и доверять планировщику bin pack.
Стоит ли запускать Ceph в Kubernetes?
Если вы хотите использовать Ceph для предоставления PV для ваших контейнеров вам следует запускать его вне Kubernetes.
Если вы хотите запустить Ceph с использованием DaemonSet и StatefulSet, вам следует подумать о этот. Есть несколько предложений, как решить, подходит ли это для вашей организации.
Какие типы SKU следует покупать?
Если вашим приоритетом является оптимизация развертывания Ceph для максимальной пропускной способности, вам понадобится один или несколько SSD для журнала Ceph и несколько SSD / HDD для блочного хранилища. Вы не захотите использовать эти устройства совместно с другими рабочими нагрузками. Если вы используете Kubernetes для управления Ceph в этой конфигурации, и вы статически разделяете все свои рабочие нагрузки на другие серверы, от использования Kubernetes будет мало пользы.
Если вы оптимизируете максимальную стоимость / плотность, правильный выбор зависит от сочетания рабочих нагрузок. Если Ceph является единственной рабочей нагрузкой хранилища, вы все равно можете сэкономить деньги, запустив его на SKU с оптимизированной плотностью хранения в отдельном месте.