Helm chart'ının doris.host ile yönlendirdiği Doris telemetri deposunu nasıl sağlayacağınız — Doris'i nerede çalıştıracağınızı seçme, gereksinimler, küme içi Doris'in neden operatör kullandığı, operatörü kurma, DorisCluster uygulama ve Orbtrace'i ona karşı ayağa kaldırma.
Kubernetes'te Helm chart'ı Doris'i kurmaz — doris.mode varsayılan olarak external. Doris'i siz sağlar ve chart'ı doris.host ile ona yönlendirirsiniz. Bu sayfa, bunu yapmanın desteklenen her yolunu uçtan uca anlatır.
Bunu `helm install`'dan önce yapın
Orbtrace pod'u, web portunu bağlamadan önce şemasını Doris'e uygular; bu yüzden Doris erişilebilir olana kadar un-Ready kalır. Önce Doris'i ayağa kaldırıp sağlıklı olduğunu doğrulayın, sonra Orbtrace'i kurun.
Doris'i nerede çalıştıracağınızı seçin
Senaryonuz
Doris'i nasıl çalıştırırsınız
Operatör?
Değerlendirme / demo / tek host
Helm yerine Docker Compose kullanın. Compose paketi bir Doris FE + BE içerir — tek komut, ayrıca kurulacak bir şey yok.
Hayır
VM'de ya da yönetilen serviste Doris
Doris'i küme dışında, kümeden erişilebilir şekilde çalıştırın ve doris.host'u FE'sine ayarlayın.
Hayır
Küme içinde Doris (Kubernetes)
doris-operator çalıştırın ve bir DorisCluster uygulayın (aşağıda). Chart, operatör yönetimindeki FE Service'ine bağlanır.
Evet
Küme içi yol neden operatör ister
Doris kümelenmiş bir veritabanıdır — frontend (FE) ve backend (BE) node'ları birbirini ağ adresiyle bulur ve tek bir grup olarak kayıtlı kalmalıdır. Kubernetes'te bir pod her yeniden başladığında yeni bir IP alır, yani node'lar birbirini kaybeder. Doris ayrıca bazı adımların belirli bir sırada yapılmasını ister: bir node ekleme/çıkarma ve kümeyi kesintisiz, node node yükseltme. Kubernetes'in hazır parçaları (stock Doris imajıyla çalışan bir StatefulSet) bunların hiçbirini yapmayı bilmez. doris-operator, bir kez kurduğunuz ve bunu sizin için halleden küçük bir controller'dır — yeni FE/BE node'larını kümeye katar, pod'lar yeniden başladığında üyeliği doğru tutar ve güvenli rolling upgrade'leri sıralar. VM'de ya da yönetilen bir Doris'te adresler hiç değişmez, dolayısıyla koordine edilecek bir şey ve operatör gerekmez.
Gereksinimler
Herhangi bir küme içi Doris için (operatör yolu):
Bir Kubernetes kümesi ve Helm 3.8+.
Hızlı bir StorageClass — SSD/NVMe destekli. Doris BE compaction IOPS-bound'dur; dönen diskler yetişemez.
Bir Doris BE'nin indiği her node'da birkaç Linux kernel ayarı. Bunlar container içinde değil node'da (host/VM) durur — normal bir pod bunları değiştiremez, o yüzden node üzerinde önceden ayarlarsınız. Elasticsearch ve OpenSearch de tam olarak aynılarını ister:
vm.max_map_count >= 2000000 — bir sürecin tutabileceği azami memory-mapped bölge sayısı. Doris BE çok sayıda veri dosyasını memory-map'ler; Linux varsayılanı (65530) çok düşüktür ve BE başlamaz.
fs.inotify.max_user_instances = 8192 ve fs.inotify.max_user_watches = 1048576 — node'un aynı anda değişiklik için izleyebileceği dosya sayısı. Doris çok dosya açar; varsayılanlar yetmez.
swap kapalı — BE başlarken swapoff -a çalıştırır ve swap değil gerçek RAM bekler. Node'un RAM'ini iş yüküne göre boyutlandırın.
Nasıl uygulanır, node'ların nerede olduğuna bağlıdır — somut tarifler (VM sysctl, düz Kubernetes DaemonSet ya da OpenShift Node Tuning Operator) hemen aşağıda, Node ayarlarını uygulama bölümünde.
Operatörü kurmak için — bir kez — cluster-admin yetkisi. doris-operator cluster-scoped'tur: yalnızca bir cluster-admin'in oluşturabileceği yeni kaynak türleri (CRD'ler) ve küme geneli izinler (RBAC) ekler. Yani bir admin onu tüm küme için bir kez kurar. Sonrasında sıradan ekipler kendi namespace'lerinde sıradan (namespaced) izinlerle bir DorisCluster oluşturur — bir daha admin yetkisi gerekmez.
Küme dışı Doris (VM/yönetilen) için yalnızca yukarıdaki node kernel ayarlarını Doris host'larında yapmanız yeterlidir; operatör yok, cluster-admin adımı yok.
Applysave as doris-node-sysctl.yaml, then runkubectl apply -f doris-node-sysctl.yaml
(Kubernetes node'ları zaten swap kapalı çalışır, orada ekstra bir şey yapmanız gerekmez.)
OpenShift'te
Ayrıcalıklı DaemonSet kullanmayın; sysctl'leri Node Tuning Operator ile (bir Tuned custom resource) küme genelinde uygulayın ki BE pod'ları restricted-v2 altında ayrıcalıksız kalsın.
Önce operatörün kümenizde olduğunu kontrol edin — Tuned kaynak türü ancak operatör kuruluysa var olur (gerçek OpenShift varsayılan taşır; OpenShift Local/CRC ve bazı minimal OKD kurulumları taşımaz). Komut NotFound dönerse YAML'i atlayıp aşağıdaki ipucu kutusundaki yedek yolu kullanın:
Applysave as doris-node-tuning.yaml, then runoc apply -f doris-node-tuning.yaml
Kümede operatör yok mu? Sysctl'leri doğrudan node'lara yazın
Operatör yokken küme Tuned kaynak türünü hiç tanımaz; yukarıdaki oc apply bu yüzden no matches for kind "Tuned" in version "tuned.openshift.io/v1" / ensure CRDs are installed first hatasıyla düşer. Bu hata tam olarak bu durumu anlatır — aynı sysctl'leri, Doris BE'nin çalışacağı her node'a (pod'a değil, makineye) doğrudan yazın. Yalnızca node yeniden başlayana kadar geçerlidir ve sonradan eklenen node'lar aynı komutu ister. Bir değerlendirme için yeterli:
# Aday node'ları listeleyin (NAME sütunu; OpenShift Local/CRC'de tektir),# sonra her birine — ya da döngüyle tüm worker'lara tek seferde — uygulayın:oc get nodes -l node-role.kubernetes.io/workerfor n in $(oc get nodes -l node-role.kubernetes.io/worker -o jsonpath='{.items[*].metadata.name}'); do oc debug node/$n -- chroot /host sysctl -w \ vm.max_map_count=2000000 \ fs.inotify.max_user_instances=8192 \ fs.inotify.max_user_watches=1048576done# Doğrulama: oc debug node/<node-adı> -- chroot /host sysctl vm.max_map_count
Doris BE için bir storage pool'u label'larsanız match'i BE'nin indiği node'lara daraltın. OpenShift'e özgü diğer her şey (chart overlay'i, SCC, Route) OpenShift sayfasında.
Replikasyon faktörü (RF) — BE sayınızla eşleştirin
Replikasyon faktörü (RF), Doris'in her satırdan kaç kopya tuttuğudur — backend (BE) node başına bir kopya. Bir BE öldüğünde verinizi koruyan şey budur: RF 2 ile her satır iki BE'de yaşar, birini kaybetmek atlatılabilir. Orbtrace, Doris tablolarını replication_num = doris.profile.replicationNum ile oluşturur (medium / large profillerinde 2 — iki kopya).
Kural bundan çıkar: RF = N, en az N canlı BE node'u ister — koyacak tek node varken bir satırın 2 kopyasını tutamazsınız. Yani RF'den az BE'niz varsa, ilk CREATE TABLE başarısız olur (Doris replication num … available backend num is 1 döner), Orbtrace açılışta bilerek durur (migration runner'daki bir güvenlik kontrolü) ve pod'u hiç Ready olmaz — un-Ready kalır / crashloop yapar. Bu, "kurdum ama ayağa kalkmıyor" durumlarının en yaygın sebeplerinden biridir.
İki taraf uyuşmalı — BE node sayısı (Doris tarafı) ve app'in istediği RF (Orbtrace chart değerleri):
Taraf
Değer
Nedir
Doris
BE node sayısı — beSpec.replicas (operatör) ya da BE host sayısı (VM)
RF'nin tavanı
Orbtrace
doris.profile.replicationNum
app'in tabloları oluşturduğu RF — BE sayınızdan ≤ olmalı
Orbtrace
doris.allowSingleReplica
yalnızca tek BE'de RF = 1'i kabul etmek için true yapın
Yani Doris RF'nizle birlikte değişen app-tarafı parametre doris.profile.replicationNum'dur (tek BE için artı doris.allowSingleReplica). Bu, tablolar oluşturulurken (ilk açılışta) uygulanır — sonradan yükseltmek yalnızca yeni tabloları etkiler; mevcut tablolar, Doris tarafında değiştirene kadar (ALTER TABLE … SET ("replication_num" = "N")) RF'lerini korur. RF'nizi ilk açılıştan önce belirleyin.
Üretim:≥ 2 BE ile replicationNum ≥ 2 çalıştırın (hyperscale için ≥ 3 BE'de 3). Aşağıdaki referans DorisClusterbeSpec.replicas: 3 kullanır ve varsayılan RF = 2'yi karşılar.
Tek-BE (tek-node / PoC): tek-BE bir Doris RF = 2'yi karşılayamaz. Ona karşı çalışmak için chart my-values.yaml'ınızda iki değeri de ayarlayın — riski kabul edin ve gerçekten RF = 1 tablolar oluşturun:
my-values.yaml
doris: allowSingleReplica: true # veri-kaybı riskini kabul et profile: replicationNum: 1 # tabloları RF=1 ile oluştur
RF = 1, tek bir BE kaybının kalıcı, geri döndürülemez veri kaybı olması demektir — üretimde asla kullanmayın.
Neden ikisi de, sadece `replicationNum: 1` değil?
İkisi farklı işler yapar — biri değer, diğeri onay kapısı:
doris.profile.replicationNum, app'in CREATE TABLE'a yazdığı RF'dir. Varsayılan 2'de bırakırsanız, tek BE'de Doris'in kendisi create'i reddeder (replication num should be less than the number of available backends).
doris.allowSingleReplica, app'teki bir dayanıklılık guard'ıdır (DorisMigrationRunner): açıkça opt-in etmedikçe RF 2'nin altında çalışmayı reddeder — tam olarak doris.bundledAck gibi bir fail-fast, ki kimse sessizce kırılgan RF=1 tablolar göndermesin.
Yalnızca replicationNum: 1 → guard boot'u durdurur. Yalnızca allowSingleReplica: true → RF=2 create patlar. İkisi birlikte = çalışır.
Seçenek A — VM'de ya da yönetilen serviste Doris (operatör yok)
Kümenizle aynı ağda, her BE host'una node kernel ayarları uygulanmış bir Doris FE + BE kümesini VM'lerde (ya da yönetilen bir Doris) ayağa kaldırın. Sonra chart'ı FE'sine yönlendirin — bu anahtarlar my-values.yaml'ınıza gider (bkz. Helm ile kurun):
my-values.yaml
doris: mode: external # varsayılan — chart Doris'i hiçbir zaman çalıştırmaz host: <doris-fe-host-unuz> # kümeden erişilebilir Doris FE'nizin FQDN'i queryPort: 9030 # varsayılan Doris MySQL query portu httpPort: 8030 # varsayılan Doris HTTP (Stream Load) portu password: <doris-root-parolanız> # parolasız taze bir Doris için boş ("")
Bunları my-values.yaml'ınıza ekleyin — Helm ile kurun (3. adım) sayfasında oluşturduğunuz küçük overrides dosyası; 4. adım kurulumu çalıştırır.
Boyutlandırma (FE/BE sayıları, CPU/RAM/disk) Kapasite planlama sayfasındadır. Hepsi bu — aşağıdaki operatör bölümünü atlayıp Orbtrace'i ayağa kaldırın bölümünden devam edin.
Seçenek B — Operatör ile küme içinde Doris
Ne kurarsınız
doris-operator (SelectDB) — Doris'i Kubernetes'te yöneten controller. Küme başına bir kez kurulur.
Bir DorisCluster kaynağı — operatörün stock apache/doris FE/BE imajlarını kullanarak çalışan pod'lara dönüştürdüğü Doris örneğiniz (FE + BE).
OpenShift'te: Doris namespace'inde bir kerelik izinler
İki OpenShift güvenlik varsayılanı operatörün pod'larını engeller. Operatör, BE pod'larına ayrıcalıklı bir default-init container'ı enjekte eder (vm.max_map_count'u yükseltir) — varsayılan namespace Pod Security Admission'ı (restricted/baseline) herhangi bir ayrıcalıklı container'ı reddeder, dolayısıyla BE pod'u hiç oluşturulmaz ve cluster initializing'de kalır. Ayrıca stok apache/doris image'ları root olarak çalışır: restricted-v2'nin rastgele UID'si altında FE, start_fe.sh: Permission denied ile crashloop yapar — anyuid SCC'si pod'ların image'ın kendi kullanıcısını korumasını sağlar. doris namespace'ini oluşturun (Adım 2 içine deploy eder), PSA'sını gevşetin ve iki SCC'yi de verin — blok idempotent'tir, tekrar çalıştırmak güvenlidir:
(label/policy komutlarını namespace olmadan çalıştırmak namespaces "doris" not found ile düşer — üstteki create satırı bloğun parçası olması bu yüzden. Adım 2'deki kubectl create namespace doris bundan sonra AlreadyExists der; sorun değil.)
Atlarsanız operatör logunda would violate PodSecurity "…": privileged (container "default-init" must not set securityContext.privileged=true) yazar, DorisCluster initializing'den çıkmaz ve Orbtrace app'i eksik BE yüzünden crashloop yapar. vm.max_map_count yine >= 2000000 olmalıdır — ayrıcalıklı init bunu ayarlar ya da Node Tuning Operator ile node genelinde uygularsınız (Gereksinimler); her hâlükârda bu iki izin gereklidir. Ayrıcalıklı init'ten ve her iki izinden tamamen kaçınmak için Doris'i küme dışında çalıştırın (Seçenek A) — OpenShift'te önerilen yol. Adım adım OpenShift sayfasında.
Adım 2 — DorisCluster'ı uygulayın
Bu DorisCluster testbed-doğrulamalıdır (3-FE / 3-BE topolojisinde temiz bir 60 dakikalık sürekli yazma). BE ConfigMap'i, yazmaların sürekli yük altında reddedilmesini önleyen compaction tuning'ini taşır — onu küme ile birlikte uygulayın. storageClassName'i hızlı SSD/NVMe sınıfınıza ayarlayın ve BE replika/belleğini Kapasite planlama'ya göre ölçekleyin.
kubectl create namespace doriskubectl apply -f doriscluster-orbtrace.yamlkubectl -n doris get doriscluster -w # FE/BE fazının Ready olmasını bekleyin
Küçük bir cluster'da mı deniyorsunuz? Referans CR schedule edilemez
Yukarıdaki referans DorisClusterproduction boyutundadır: 3 FE × 4 CPU + 3 BE × 8 CPU ≈ 36 CPU istek. Küçük bir cluster'da (OpenShift Local, tek node, kind) pod'ları sonsuza dek Pending / Insufficient cpu kalır. Yalnızca değerlendirme için, dosyadaki DorisCluster dokümanını (ConfigMap'i koruyarak) şu 1 FE / 1 BE varyantla değiştirin:
Tek bir BE her satırın yalnızca tek kopyasını tutabilir; chart tabloları RF = 1 ile oluşturmalıdır — my-values.yaml'da her ikisini de ayarlayın: doris.allowSingleReplica: true ve doris.profile.replicationNum: 1 (Replikasyon faktörü bölümü ikisinin de nedenini anlatır). Bu varyantı asla üretimde kullanmayın.
FE config'ini override etmeyin
feSpec.configMapInfo üzerinden bir fe.confeklemeyin — operatörün configMapInfo'su operatör-enjekte fe.conf'u (priority networks, edit-log port) değiştirir ve FE crashloop'a girer. Yukarıdaki BE be.conf güvenli yoldur. Tek enterprise FE knob'u için, küme ayağa kalktıktan sonra çalışma zamanında ayarlayın:
kubectl -n doris exec orbtrace-doris-fe-0 -- mysql -h127.0.0.1 -P9030 -uroot \ -e "ADMIN SET FRONTEND CONFIG ('max_dynamic_partition_num'='2000')"
Orbtrace'i kurmadan önce doğrulayın
Önce kümenin sağlıklı olduğunu doğrulayın — bu, sonradan Ready olmayan bir Orbtrace pod'unu debug etmekten sizi kurtarır. Operatör yolu için:
kubectl -n doris exec -it orbtrace-doris-fe-0 -- mysql -uroot -P9030 -h127.0.0.1 \ -e "SHOW FRONTENDS\G SHOW BACKENDS\G"
Her FE Alive: true ve quorum'da olmalı; her BE Alive: true olmalı. (VM/yönetilen bir Doris için aynı sorguyu onun FE'sine karşı çalıştırın.)
Orbtrace'i ayağa kaldırın
Chart'ı az önce doğruladığınız Doris'e yönlendirin. Chart varsayılanları zaten doris namespace'inde orbtrace-doris adlı bir operatör Doris'ini varsayar:
Bunları my-values.yaml'ınıza ekleyin — Helm ile kurun (3. adım) sayfasında oluşturduğunuz küçük overrides dosyası; 4. adım kurulumu çalıştırır.
Bu doris.* anahtarları, Helm ile kurun (3. adım) sayfasında düzenlediğiniz my-values.yaml'ınıza gider. Bağlantıyı iki alan taşır:
doris.host — FE adresi. Operatör için varsayılan zaten referans DorisCluster ile eşleşir (doris namespace'inde orbtrace-doris), dolayısıyla o adları kullandıysanız değiştirmeniz gerekmez. VM/yönetilen bir Doris için FE'nizin FQDN'ini verin. (queryPort 9030 = app'in okuduğu MySQL wire; httpPort 8030 = Stream Load — standart Doris portları, yalnızca sizinkiler farklıysa değiştirin.)
doris.password — Doris root parolası. Taze bir operatör Doris'i için boş bırakın; DorisCluster/VM'inizin bir root parolası varsa ayarlayın (ya da --set-string doris.password=…), yoksa app bir kimlik-doğrulama hatasıyla un-Ready kalır.
Sonra Helm ile kurun sayfasına göre Orbtrace'i kurun. İlk açılışta uygulamanın migration runner'ı otel_* tablolarını ve Orbtrace uzantı sütunlarını oluşturur — bitmesini bekleyin:
Orbtrace pod'u, şema uygulanıp Doris'e erişebildiğinde Ready olur.
Sorun giderme
FE quorum'a ulaşmıyor — çift FE sayısı ya da node'lar arası scheduling. Referans DorisCluster 3 FE'yi anti-affinity ile kullanır.
BE Alive: false — neredeyse her zaman BE node'unda vm.max_map_count ayarlanmamıştır (Gereksinimler) ya da BE, FE edit-log portuna ulaşamıyordur.
Orbtrace un-Ready kalıyor / STORAGE_UNAVAILABLE raporluyor — doris.host veya doris.password uyuşmazlığı ya da kurulum sırasında Doris Ready değildi. Yukarıdaki doğrulama adımına karşı yeniden kontrol edin.