Runtime'lar ve node'lar

Özet

Bir runtime, bir deployment'ın içinde çalıştığı bir compute rezervasyonudur: workspace'in deploy etmeye hak kazandığı bir makine havuzu. Bir deployment'ın devraldığı runtime sözleşmesini taşır — runtime sınıfı, kapasite, ömür, deployment başına tavan.
Bir node, bir runtime içindeki bir makinedir. Platform, container'ları node'lar arasında otomatik olarak zamanlar; kullanıcılar node'ları elle seçmez.
Bir flavor, bir node'un sağlandığı boyutlandırılmış şablondur (CPU / GPU / RAM / disk). Flavor kataloğu, hangi boyutların var olduğunu ve stokta ne olduğunu listeler.
Runtime'lar iki şekilde gelir: cloud destekli (platform bir flavor SKU'sundan talep üzerine node sağlar) ve statik (runtime, önceden kayıtlı müşteri donanımına bağlıdır — on-premise veya air-gapped).
Bir runtime'ın runtime sözleşmesi — kilitli olup olmadığı, node sayısı, sona erme zamanı, deployment başına tavanı ve runtime sınıfı — runtime seçimini körlemesine bir deploy yerine iş yüküne karşı kasıtlı bir eşleştirme yapan şeydir.

Runtime'lar ve node'lar nedir

Bir runtime, bir deployment'ın hedeflediği birimdir ve bir node, içindeki bir makinedir. Pipelogic, bir kullanıcının yaptığı seçimin (hangi runtime) platformun gerçekleştirdiği yerleşimden (hangi node) ayrıştırılması için ikisini ayrı modeller. Tek bir "iş yüküm nerede çalışıyor" kavramı, kullanıcı için önemli olan ayrıntıları — GPU sınıfı, örnek başına bellek, kiracılık modeli, iş yükünün yönetilen cloud'da mı yoksa müşterinin kendi donanımında mı çalıştığı — ve scheduler'ın sahip olması gereken ayrıntıları bir araya katlardı.

Runtime, kullanıcıların seçtiği şeydir: kendi kilit durumu, runtime sınıfı, ömrü ve hakkıyla adlandırılmış bir havuz. Node, içinde çalışan şeydir: platformun container'ları üzerine zamanladığı bir makine. Bu ayrım, kullanıcıların umursadıkları birim (runtime) hakkında akıl yürütmesini sağlarken, umursamadıkları birim (belirli bir makine) hakkında akıl yürütmemelerini sağlar ve scheduler'ın yerleşimi bir kullanıcı seçimi olarak açığa çıkarmadan container'ları yerleştirmesine olanak tanır.

Bir runtime'daki runtime sınıfı, birçok iş akışı için yük taşıyan ayrıntıdır. shared runtime'lar birden fazla kiracıyı barındırır ve geliştirme ile küçük iş yükleri için varsayılandır. dedicated runtime'lar, paylaşımlı havuz yerleşiminin çok belirsiz olduğu durumlar için compute'u tek bir workspace'e sabitler. on_premise ve air_gapped runtime'lar, müşterinin kaydettiği node'ları barındırır — workspace'in kendi donanımı, müşterinin ağının içinde, compute müşterinin çevresinden ayrılmadan platforma bağlı. Aynı backend, kod değişikliği olmadan bu sınıfların herhangi birine deploy edilir, çünkü backend'ler runtime'dan ayrıştırılmıştır.

Zihinsel model

   Workspace
       │
       │ owns
       ▼
   Runtime  (cloud-backed SKU  or  static set of nodes)
       │
       │ contains
       ▼
   Node     (a machine: VM / bare metal / cloud instance)
       │
       │ runs
       ▼
   container (one vertex of the deployed backend graph)

Kullanıcı runtime'ı seçer; platform node'u seçer. Bir deployment, bir backend'in bir runtime ile eşleştirilmesidir ve scheduler, deployment'ın container'larını sağlıklı ve boşluğu olan node'lara dağıtır. Kullanıcının tarafından, "iş yüküm nerede çalışıyor" bir runtime adlandırılarak yanıtlanır; gerisini platform halleder.

Bu yapının üzerindeki runtime eşleştirmesi için Deployment'lar sayfasına bakın.

Cloud destekli ile statik runtime'lar

Soru "bu iş yükünün compute'u nereden gelmeli" olduğunda bu çerçeveyi kullanın.

Bir cloud destekli runtime varsayılan şekildir. Runtime bir flavor SKU'su ile tanımlanır; platform, deploy zamanında o SKU'dan node'lar sağlar ve compute'u iş yüküyle eşleşecek şekilde boyutlandırır. Runtime, workspace'in listelemesinde mevcut node sayısı ve deployment başına tavanı ile görünür ve deployment'lar önceden bir sağlama adımı olmadan ona iner.

Bir statik runtime, müşteri-donanımı şeklidir. Runtime, önceden kayıtlı node'lara bağlıdır — müşterinin workspace'ine kaydettiği makineler, tipik olarak kendi ağlarının içinde, çoğu zaman genel internetten air-gapped. Runtime sınıfı (on_premise veya air_gapped) node'lardan devralınır. Statik runtime'lar, uyumluluk, gecikme veya veri-yerelliği nedenleriyle müşterinin kendi donanımında çalışması gereken iş yükleri içindir. Yönetilen cloud ve müşterinin donanımı, aynı platformda aynı backend'dir — aralarında kod değişikliği yok.

Statik runtime'lar için kayıt yüzeyi, bunları içeren planlarda mevcuttur; hak mevcut olduğunda ilgili ppl node enroll … komutları görünür. Adanmış cloud kapasitesini sabitlemek aynı kalıbı izler — o yüzey, plan izin verdiğinde görünür. ppl node flavors ile cloud flavor'larına göz atmak evrensel olarak mevcuttur; canlı katalog, stokta ne olduğunu ve her flavor'ın hangi runtime sınıflarına eşlendiğini listeler.

Bir runtime seçme

Her ppl backend deploy'a uzandığınızda bu çerçeveyi kullanın.

Runtime seçimi tek seferlik bir listele-ve-filtreledir. Workspace bir runtime kümesi görür; her biri locked olup olmadığını (kilitli bir runtime yeni deployment almaz), node sayısını (boşluk olup olmadığı), deployment_count'unu (kapasiteye karşı mevcut kullanım), runtime sınıfını (iş yükünün uyumluluk ve performans ihtiyaçlarıyla eşleşmek için) ve expires_at'ini (süreli runtime'lar için, runtime'ın kendisinin ne zaman geri alınacağı) reklam eder.

ppl runtime listppl runtime list --query=staging

Mevcut tek runtime doluysa veya runtime sınıfı iş yüküyle eşleşmiyorsa, deploy herhangi bir container başlamadan önce reddeder. Bu kasıtlıdır: platform, bir deployment'ı barındıramayacak bir runtime'a yerleştirmez, bu yüzden "deploy başarılı oldu" aynı zamanda "runtime beklentisi karşılandı" anlamına gelir. Deploy'u kabul edip runtime'da başarısız olmasına izin vermek, hatayı yararlı olamayacak kadar geç ortaya çıkarırdı.

Deployment eşleştirmesi sonra tek bir çağrıdır: ppl backend deploy --backend <bid> --runtime <cid>. Tek backend'li deploy'lar için --runtime isteğe bağlıdır: atlandığında, önce workspace'in yapılandırılmış varsayılan runtime'ı kullanılır ve platformun seçicisi ondan sonra deploy edilebilir bir runtime seçer. İş yükü belirli bir runtime gerektirdiğinde, birden fazla backend'i toplu işlerken (burada --runtime gereklidir) veya varsayılan eldeki çalışmaya uymadığında açık biçimi kullanın.

Runtime seçildikten sonraki operasyonel döngü için Deploy ve monitor sayfasına bakın.

Node'lar neden scheduler tarafından yönetilir

"Bunu hangi node'un çalıştıracağını seçebilir miyim" diye merak ettiğinizde bu çerçeveyi kullanın.

Node'lar görünürdür (ppl node list listeyi döndürür) ancak deployment yerleşimi için seçilebilir değildir. Scheduler, her container'ın nereye ineceğine, node'un kilitli olup olmadığına, yeteneklerine, mevcut yüküne ve deployment'ın kaynak ihtiyaçlarına göre karar verir. Bu karar kullanıcı tarafından kontrol edilemez, iki nedenden ötürü.

İlki, yerleşim, scheduler'ın kullanıcının sahip olmadığı bilgiyle çözdüğü bir optimizasyon problemidir. İki container'lı bir iş yükü, çalışma başına değişen ayrıntılara bağlı olarak tek bir node üzerinde birlikte yerleştirilebilir (shared-memory aktarım için) veya node'lar arasında yayılabilir (hata toleransı için). Container'ları belirli node'lara sabitlemek, ortalamada yerleşimi bozar ve hiçbir fayda sağlamadan operasyonel iş ekler.

İkincisi, node kimliği geçicidir. Cloud destekli node'lar döndürülür, bakım için boşaltılır ve flavor katalogları değiştiğinde değiştirilir. Bir deployment'ı belirli bir node'a sabitlemek, görünmez olması amaçlanan bu işlemleri açığa çıkarırdı. Kullanıcının sözleşmesi, kararlı bir kimliğe ve runtime sınıfına sahip olan runtime iledir; platform, altındaki node'ları yönetir.

Yerleşime ilişkin gözlemlenebilirlik yine de açığa çıkarılır. ppl deployment containers <did>, her container'ın hangi node'a indiğini gösterir, böylece takım container durumunu node durumuyla ilişkilendirebilir ve bir sorunun node-yerel mi (bir node yanlış davranıyor) yoksa sistemik mi (her node aynı sorunu gösteriyor) olduğunu söyleyebilir.

Runtime yaşam döngüsü ve işlemleri

Bir runtime, üzerinde çalışan herhangi bir deployment'tan ayrı kendi yaşam döngüsüne sahiptir. Bir runtime, kilidi açıkken ve sağlıklı bir node'u varken deployment'ları kabul eder; bir operatör onu lock edebilir (bakım için donmuş, yeni deployment kabul edilmez); ve expires_at'inde geri alınır. Cloud destekli runtime'lar platformun programına göre sona erer; statik runtime'lar müşteri node'larını ayırdığında sona erer.

Bir runtime'a inen her deployment'ın kendi tavanı vardır — runtime üzerinde reklam edilen deployment_timeout. Varsayılan olarak deployment'lar o tavana kadar otomatik uzar; deploy zamanında --fixed-duration <dur> geçirmek sabit bir son sabitler ve otomatik uzamayı devre dışı bırakır. İş yükünün bilinen bir duvar-saati bütçesi olduğunda (bir demo penceresi, zamanlanmış bir toplu iş) sabit bir süre sabitleyin; runtime kadar uzun süre çalışması gereken deployment'lar için otomatik uzamayı yerinde bırakın.

Yaygın hata şekilleri

Çoğu runtime ile ilgili hata, küçük bir şekil kümesinde toplanır:

no deployable runtime available — erişilebilir her runtime kilitli, dolu veya sağlıklı node'u yok. Düzeltme, boşluğu olan farklı bir runtime seçmek veya kapasite boşaltmaktır.
runtime locked — runtime bakım için donmuş. Düzeltme, kilidinin açılmasını beklemek veya çalışma için farklı bir runtime kullanmaktır.
Rezerve runtime ödenmedi veya rezervasyon süresi doldu — adanmış rezerve bir runtime'ın penceresi geçti. Düzeltme, rezervasyonu yenilemek veya farklı bir runtime'a deploy etmektir.
Deployment, çalışma bitmeden süresi doldu — runtime'ın deployment_timeout'u çalışmanın ihtiyaç duyduğundan kısaydı. Düzeltme, --fixed-duration'ı daha uzun bir pencereye sabitlemek veya daha uzun tavanlı bir runtime'a deploy etmektir.
deploy'dan unknown flavor — flavor adı mevcut katalogda değil (yalnızca cloud destekli runtime'lar). Düzeltme, ppl node flavors ile güncel bir flavor çözmek ve var olan birini seçmektir.

Daha geniş hata kalıpları Yaygın hatalar sayfasında bulunur.

Bu nereye oturur

Runtime'lar ve node'lar, platformun runtime katmanıdır. Deployment'ların altında otururlar — her deployment tam olarak bir runtime'a iner, deployment'taki her container tam olarak bir node'a iner — ve takımın platformun sahip olduğu zamanlama iç bileşenlerini açığa çıkarmadan kapasite, uyumluluk ve yerleşim hakkında akıl yürütmesi için yeterli sözleşme açığa çıkarırlar.

Runtime (kullanıcıya görünür runtime sözleşmesi) ile node (platform tarafından zamanlanan compute) arasındaki ayrım, aynı backend'in kod değişikliği olmadan paylaşımlı bir cloud runtime'ına ve müşteri-kaydettiği statik bir runtime'a deploy edilmesini sağlayan şeydir. Bu taşınabilirlik, backend'leri runtime'dan ayrıştırılmış tutmaktan kaynaklanır.

İlgili

Deployment'lar — bu yapının üzerindeki backend-artı-runtime runtime eşleştirmesi.
Backend'ler — deploy edilen tipli graf.
Lease'ler — runtime'lar aynı zamanda lease'lerin hedeflediği şeydir.
Deploy ve monitor — runtime seçildikten sonraki operasyonel döngü.
Yaygın hatalar — belirti → düzeltme araması.