Специально полез посмотреть, Red Hat вывел из экспериментального статуса планировщик с поддержкой NUMA
https://docs.okd.io/4.14/scalability_and_performance/cnf-num...
Причем сравнительно недавно...> tenant-кластера запускаются в виртуальных машинах, которые уже можно жёстко лимитировать.
Ну то есть это и есть k8saas, потому что теннанты виртуализированы. Тогда всё понятно, тогда это нормально. Просто я подумал, что это очередное решение сделать железный кубик для хостинг провайдеров без изоляции. К нам такие приходили с предложениями "купите нас". Не скажу кто, потому что есть надежда, что исправятся.
Если клиентские Kubernetes виртуализованы, OVS можно оффлоадить в Cozystack и SR-IOV работает, значит у проекта есть будущее.
Просто с учетом той нагрузки, которую порождает репликация хранилища в Ethernet сетях и скорости адаптеров у хостинг провайдеров сложилось предпочтение в выборе вендора... В общем сетевая карточка может быть любой если это Mellanox. Начиная с ConnectX-5 можно тестировать функционал offloading для Cozystack.
> Проблемы начинаются на медленной сети и при геораспределённой репликации.
LINSTOR, как я посмотрю начал бесплатно выкладывать DRBD-транспорт для RDMA. Причем когда я говорю RDMA я имею в виду RoCEv2. iWarp ввиду тотальной деградации OEM-вендоров последних шести лет, фактически не существует в готовых решениях. Помер вместе с вендорами сетевок, которые его поставляли. Сейчас нужно отдельно Chelsio покупать, если он реально нужен. Всё настолько плохо с ним, что вся Azure перелезла на Mellanox и RoCEv2, который проектировался при участии MS.
Внедрение сети готовой к RoCEv2 - это как раз решение по вопросу репликации гиперконевергентных хранилищ. Логика простая:
В рамках PoD-а датацентра (в смысле комнаты) должна быть честная выделенная Spine-Leaf фабрика. В каждой стойке поднимается DCB с PFC и ETS (стандартное резервирование иерархического QoS для RDMA-приоритета на 50% большинство задач покроет) и обязательно ECN. Каждая стойка имеет L2 и держит гейтвеи на ToR, а наверх пойдёт L3 с роутингом по BGP. Трафик сети хранения при этом должен перекраситься из 802.1p в DSCP, где его вновь встречает PFC, ETS и ECN. При переходе в любую собственную транзитную фабрику вы снимаете PFC и оставляете только ETS+ECN.
В этой ситуации DRBD должен правильно заворачиваться в RoCEv2 и не просить кушать. При этом кластер у вас должен стоять в одной стойке (L2), а любое внешнее хранилище идущее по NFSv4 или iSER может находиться в той же комнате в соседних стойках. Если приспичит, что-то мигрировать, из комнаты в комнату, ETS и ECN вас спасут, при условии тюнинга DCQCN-буферов.
Далее начинается самое интересное. Если у вас есть требование по репликации данных сквозь Data Center Interconnect между отдалёнными локациями вы должны делать это объектно, а не блочно. В рамках комнаты у вас всё блочно, а если кластер растянут, то
- нужны свидетели, которые мониторят кластер в каждой локации в которых он присутствует
- свидетели могут не участвовать в кворуме в рамках локации, если там нечетное количество узлов, а могут и голосовать
- есть отдельный вами написанный протокол, который мониторит состояния свидетелей отдельно от основных кластерных узлов
- трафик свидетелей желательно дублировать дополнительно через OOB мимо BGP-фабрик, потому что сами понимаете почему =)
- трафик этой репликации идёт любым подходящим объектно-файловым способом, только не блоки. Эта нагрузка считается трафиком север-юг и подпадает под её квотирование для клиентов и QoS.
То есть каждая локация должна дать Fault Domain. В идеале, есть волшебная цифра 4, когда от каждого кластера в каждой стойке есть примерно по 4 сервера и один кластер присутствует не более чем в четырёх стойках. Тогда у вас Fault Domain-ы будут диск-сервер-стойка-локация. Если применяются блейды, то это сложнее, потому что нужно еще учитывать выход из строя шасси. Тут нужно привязываться именно к LINSTOR, что они предлагают.
И вот если всё это строить на оборудовании, которое сертифицируется под Azure Stack HCI, то это будет даже надёжно работать. Особенно это касается подбора HBA и дисков.
Вопрос только в SDN-контроллере. VXLAN в такой сети используется не только для клиентов, но и для растягивания L2-доменов оверлея этих клиентов. То есть, другие услуги провайдера скорее всего уже используют VXLAN и есть OVS на физических коммутаторах, а на транзитной сети шлются Type 5 маршруты EVPN по которым ходят ДРУГИЕ VXLAN-ы, соединяющие VRF-клиентов, которые, например, арендуют физические сервера.
Следующая чисто хостинг-провайдеровская задача притащить этот VRF из одного датацентра в другой и положить на виртуальный коммутатор в Cozystack. Ну то есть интеграция с каким-нибудь Juniper Contrail крайне важна, потому что иначе при внедрении продукта Cozystack окажется в собственном сегменте сети, в изоляции... и дальше по тексту.
Что касается БД, то там вообще DRBD не нужен, там же всегда одна и та же формула:
- синхронная репликация в локации
- асинхронная репликация между локациями
- логическая асинхронная мульти-мастер репликация с CRDT между регионами (странами)
Хранилища максимально локализированы. Просто зарезервируйте под это 10% на ETS в PoD, большинству хватит.
В общем, желаю вам успехов =)
