Никаких проблем. И это не субд
а что это?
Andor
Дмитро
V 🏴☠️
Airat
Siarhei
Из полнотекстовых solar и пластик знаю пока
Siarhei
*эластик
Solyar
😡
Denis
Mikhail [azalio]
Vadim
идите оффтопить в девопс чатик
Nick
https://lucene.apache.org/solr/
http://sphinxsearch.com/
спс, да, 3 значит их таки solr, sphinx,elastic
Solyar
Сфинкс это не очень
Puma
Сфинкс как раз очень очень если хорошо укладывается в задачу
Puma
На тех же ресурсах выдаст сильно больше перфоманса
Solyar
Ну вообще тут зависит от задачи - в этом правы
Puma
Раньше его в каждый первый проект для поиска впендюривал ))
Vadim
продолжите этот невероятно полезный диалог в понедельник
Stanislav
спс, да, 3 значит их таки solr, sphinx,elastic
Эластик базируется на Lucene, но к нему предоставляет несколько вариантов кеширования и организации чанков Lucene. Один шард в терминах эластика - это один полный индекс Lucene. Solr также базируется на Lucene.
Сергей
Господа, кто нибудь базу в кубик пихал и получал от этого профит?
Pavel
если для стендов то профита много, если для прода ответьте на вопрос. сможетели вы почнить бд после поломки
Nick
Господа, кто нибудь базу в кубик пихал и получал от этого профит?
профит только в чартах\кластерах удобное переключение мастеров\слейвов. и в централизованном логировании\мониторинге
𝚔𝚟𝚊𝚙𝚜
Господа, кто нибудь базу в кубик пихал и получал от этого профит?
если нужно деплоить много однотииных конфигураций еще
Сергей
Ну вот про стенды это да
Сергей
Само собой
Сергей
Я про конфигурацию прода
Сергей
У меня просто в мыслях что если иметь сетевое быстрое хранилище по типу ceph, тогда профиты такие же как от стейтлесс
Сергей
А вот если такового нет, то больше вреда чем пользы
Сергей
Так как по сути один экземпляр базы привязан к конкретной ноже
Nick
Сергей
Так как она содержит его данные в себе. Простите за кучу сообщений, я слишком привык так делать, каюсь
Сергей
А всякие гуглы и амазоны нам недоступны
Сергей
Пока есть идея лишь держать на нодах ssd столько, чтобы хватило нам копию бд и сделать так, чтобы база сама могла оценить как она себя чувствует и в случае разрыва репликации могла бы сама себя восстановить
Сергей
Тогда можно будет любую ноду кубернетиса выносить с ноги и ничего плохого не случится
Stefan
господа, как вы думаете, если есть три ноды по 4 ядра на каждой
в случае с nginx ingress controller, его конфигурация worker_processes максимально допустимое значение 4? или всё же 12?)
склоняюсь к тому, что 4
Artem
Это ж параметр как раз самого нжинкса вроде
Андрей А
Задаёт число рабочих процессов.
Оптимальное значение зависит от множества факторов, включая (но не ограничиваясь ими) число процессорных ядер, число жёстких дисков с данными и картину нагрузок. Если затрудняетесь в выборе правильного значения, можно начать с установки его равным числу процессорных ядер (значение “auto” пытается определить его автоматически).
Параметр auto поддерживается только начиная с версий 1.3.8 и 1.2.5.
inqfen
Если не знаешь сколько надо, то число ядер - 1
Андрей А
Ставь auto - доверь выбор бездушной машине
Stefan
не то что бы меня это беспокоит, просто вдруг стало интересно
Igor
нжинкс уже умеет смотреть на сигруппу, в которой ранится?
Igor
я к тому, что авто ставить, чтобы оно смотрело на спеки хоста = получать полную херню
che
господа, как вы думаете, если есть три ноды по 4 ядра на каждой
в случае с nginx ingress controller, его конфигурация worker_processes максимально допустимое значение 4? или всё же 12?)
склоняюсь к тому, что 4
4, если поды только под nginx
Не ставь auto - некотролируемый сервис
NM
4, если поды только под nginx
Не ставь auto - некотролируемый сервис
Можно как worker а ля по сервисам расписать чтобы www докеры в отдельный кластер
Core
сценарий -> kubespray -> inventory.ini:
master-1 ansible_host=192.168.1.2 ip=192.168.1.2 etcd_member_name=etcd1
master-2 ansible_host=192.168.1.3 ip=192.168.1.3 etcd_member_name=etcd2
master-3 ansible_host=192.168.1.4 ip=192.168.1.4 etcd_member_name=etcd3
node-1 ansible_host=192.168.1.6 ip=192.168.1.6 etcd_member_name=etcd6
node-2 ansible_host=192.168.1.7 ip=192.168.1.7 etcd_member_name=etcd7
[kube-master]
master-1
master-2
master-3
[etcd]
master-1
master-2
master-3
[kube-node]
node-1
node-2
[k8s-cluster:children]
kube-master
kube-node
ПОДРАЗУМЕВАЕТСЯ -> ЛОКАЦИЯ ДИСКОВОГО ПРОСТРАНСТВА НА:
node-1 (192.168.1.6)
и
node-2 (192.168.1.7)
ВОПРОС:
config -> kubespray:
group_vars/k8s-cluster/addons.yml
ВАРИАНТ 1:
cephfs_provisioner_monitors: "192.168.1.6:6789,192.168.1.7:6789"
rbd_provisioner_monitors: "192.168.1.6:6789,192.168.1.7:6789"
ВАРИАНТ 2:
cephfs_provisioner_monitors: "172.24.0.6:6789,172.24.0.7:6789"
rbd_provisioner_monitors: "172.24.0.6:6789,172.24.0.7:6789"
Корректно: ВАРИАНТ 1 или ВАРИАНТ 2
?
George
Твой текст ничитаемая портянка
George
https://paste.ubuntu.com/p/3JKYsKNQbC/
окей. У тебя адреса на хостах какие? сколько сетевых интерфейсов?
Core
на каждом сервере (master-ах, noda-х) по 1 сетевому интерфейсу
Core
master-1 192.168.1.2
master-2 192.168.1.3
master-3 192.168.1.4
node-1 192.168.1.6
node-2 192.168.1.7
George
а 172.*.*.* откуда взял?
Core
IP по default в kubspray:
Core
group_vars/k8s-cluster/addons.yml
Core
config -> kubespray:
group_vars/k8s-cluster/addons.yml
ВАРИАНТ 1:
# CephFS provisioner deployment
cephfs_provisioner_monitors: "192.168.1.6:6789,192.168.1.7:6789"
# RBD provisioner deployment
rbd_provisioner_monitors: "192.168.1.6:6789,192.168.1.7:6789"
ВАРИАНТ 2:
# CephFS provisioner deployment
cephfs_provisioner_monitors: "172.24.0.6:6789,172.24.0.7:6789"
# RBD provisioner deployment
rbd_provisioner_monitors: "172.24.0.6:6789,172.24.0.7:6789"
Core
Корректно: ВАРИАНТ 1 или ВАРИАНТ 2
?
George
я задал конкретный вопрос )
George
я пока посмотрел и вроде как оно залетает сюда - https://github.com/kubernetes-incubator/external-storage/blob/master/ceph/cephfs/example/class.yaml ?
Core
я задал конкретный вопрос )
kubespray ставит по 172... в конфге для "cephfs_provisioner_monitors".
Если ceph не разворачивает дополнительную сеть следовательно "ВАРИАНТ 1" -> коректный.
Просьба: подтвердить
Lucky SB
Хз
Lucky SB
Данных нет
Lucky SB
Ты привел инфу из кубспрея