vStack Center nedir
vStack Center, vStack Hyperconverged Infrastructure kümesinin (aşağıda vStack HCP olarak anılacaktır) yönetim katmanıdır. Yöneticiler onu sanal veri merkezleri (VDC), ağlar ve sanal makineler (VM) oluşturmak, rol atamak, güvenlik olay günlüğünü ve metrikleri görüntülemek için kullanır. VM'lerin kendisi küme düğümlerindeki hipervizörde çalışır. vStack Center kümenin yetkili durumunu tutar ve neyin nerede çalışacağına karar verir.
vStack HCP iki parçadan oluşan bir şemsiye üründür: vStack Center yönetimi üstlenir, vStack OS ise hipervizör ve depolama katmanı dahil düğüm işletim sistemini sağlar. vStack Center düğümlerle doğrudan etkileşime girmez. Görevi Cluster Manager'a gönderir, o da görevi düğümlere iletir. Bu ayrım API davranışına da yansır: bir VM işlemi tek bir veritabanı yazması değil, vStack Center ile düğümlerdeki ajanlar arasında bir alışveriştir. Düğümler, kurulumları, donanım gereksinimleri ve düğüm CLI'ı vStack OS dokümantasyonunda anlatılmaktadır.
vStack Center tarafından yönetilen bir küme bağımsız çalışır. Ayrı bir ürün olan GI, birden fazla kümeyi bir federasyonda toplar ve isteklere vekil olarak aracılık eder, ancak küme bundan haberdar değildir: metot kümesi ve erişim kuralları aynı kalır.
İki bileşen
vStack Center iki servisten oluşur. Biri dış istekleri kabul eder, diğeri onları yürütür.
| Bileşen | Ne yapar | Neyle çalışır |
|---|---|---|
cluster-endpoint | Kümenin HTTPS uç noktası. Gövdesi JSON-RPC 2.0 olan HTTP POST isteklerini kabul eder, her isteği kuyruğa koyar, yanıtı bekler ve istemciye döndürür. Çerez oturumlarını yönetir. VM konsoluna giden WebSocket bağlantılarına vekil olarak aracılık eder | RabbitMQ, istemci tarayıcısı |
dispatcher-cluster | vStack Center çekirdeği. İstekleri kuyruktan okur, yetkileri denetler, varlıkları ve asenkron işlemleri izler, işi ajanlara yönlendirir | PostgreSQL, SQLite, InfluxDB, ZMQ üzerinden Cluster Manager |
İstemci yalnızca ilk bileşeni görür: tek bir HTTPS adresi ve tek bir gövde biçimi. Geri kalan her şey kuyruğun arkasında gizlidir.
İstek yolu
Клиент → cluster-endpoint (HTTPS) → RabbitMQ → dispatcher-cluster → PostgreSQL / SQLite / InfluxDB
│ ZMQ
└→ Cluster Manager → узлы кластера (AMQP)
Клиент → cluster-endpoint (WSS) → VNC-сервер ВМ
Diyagramın iki pratik sonucu vardır. Birincisi, cluster-endpoint uygulama
işlemlerinin durumunu saklamaz; bu nedenle çekirdekten ayrı olarak yeniden
başlatılabilir ve ölçeklendirilebilir. İkincisi, VM konsolu trafiği kuyruğu
atlar: WebSocket üzerinden, uç nokta aracılığıyla doğrudan makinenin VNC
sunucusuna gider.
Her şey için tek protokol
vStack Center yalnızca JSON-RPC 2.0 kullanır: her işlemin bir adı, kendine ait bir argüman kümesi ve tutarlı bir yanıt biçimi vardır. Web arayüzü özel bir istemciyle aynı yolu izler; vStack Center'da web arayüzü için ayrı bir arabirim yoktur. Sonuç olarak, bir yöneticinin fareyle yaptığı her şey programatik olarak da yapılabilir. Bu nedenle bu dokümantasyondaki prosedür sayfaları, aynı işlemler için API metotlarını sonda listeler.
Yanıt yapısı tüm metotlar için aynıdır. Başarılı bir yanıt, ilgili işlemin yükünü içerir: bir nesne, bir dizi veya tek bir değer. Başarısız bir yanıt sayısal bir kod içerir. Kodlar metotlara göre gruplanır, dolayısıyla numara isteğin nerede durduğunu belirtir. İstek ve yanıt biçimleri API'ye genel bakış başvuru sayfasında anlatılmaktadır.
Oturum
Dağıtıcı, çağıranın kimliğini aktarım katmanından almaz. Çağıranı bir oturum
belirteciyle tanımlar: web arayüzü oturum açılırken bir belirteç alır ve her
işlemde bunu sunar; özel bir istemci de aynısını yapmalıdır. Dağıtıcı, belirteç
içermeyen istekleri uygulama mantığını çalıştırmadan önce -9494 ("No session
token") koduyla reddeder.
Zorunlu parola değişikliği ayrı bir yol izler. Bu bayrağa sahip bir kullanıcı, normal oturum yerine 5 dakika geçerli tek seferlik erişim alır. Parola değiştirilene kadar yalnızca parola değişikliğinin kendisi ve parola politikasının okunması kullanılabilir. Bu nedenle web arayüzü hemen yeni parola formunu gösterir; diğer bölümler değişiklikten sonra kullanılabilir hale gelir. Belirteç biçimleri ve yanıt alanları Kimlik doğrulama başvuru sayfasında anlatılmaktadır.
Kim neyi görebilir
vStack Center'daki yetkiler bir rol ve onun kapsamıyla tanımlanır: küme veya belirli bir VDC. Metot bölümleri erişimi aynı terimlerle tanımlar: "Cluster master — kümedeki herhangi bir VM" ve "normal kullanıcı — yalnızca rol atanmış VDC'lerdeki VM'ler."
| id | Rol | Kapsam |
|---|---|---|
| 1 | Cluster Master | Kümenin tamamına tam erişim |
| 2 | vDC Admin | VDC yöneticisi |
| 3 | vDC User | VDC kullanıcısı |
| 4 | vDC Viewer | VDC görüntüleyicisi |
| 5 | Resource Viewer | Küme kaynaklarını görüntüleme |
| 6 | Security Admin | Küme düzeyi: güvenlik günlüğü ve denetim |
| 7 | VM Developer | VDC düzeyi: sanal makine oluşturma ve yapılandırma |
VDC yönetim işlemleri, yani oluşturma, değiştirme ve silme, yalnızca
Cluster Master tarafından kullanılabilir. Bir VDC içindeki çalışma 2–4 ve 7
numaralı roller aracılığıyla devredilir. 6 ve 7 numaralı roller 3.0.3 sürümünde
eklendi.
Senkron ve asenkron metotlar
Bazı metotlar yalnızca veritabanını okudukları veya yazdıkları için hemen yanıt
verir. Örneğin vm-console, bir düğümle iletişime geçmeden bağlantı ayrıntılarını
döndürür. Diğer metotlar ise bir ajan işin tamamlandığını onayladıktan sonra
yanıt verir.
vms-create uzun bir sırayı izler: parametre doğrulama, havuz seçimi, veritabanı
yazması, zvol oluşturmak için Storage ajanına devir ve ardından kayıt için VM
ajanına devir. İstemci, iki aşamalı geri çağırma işlemesinden sonra yanıt alır ve
yanıt oluşturulan VM'nin eksiksiz bir tanımını içerir. vms-start da aynı şekilde
çalışır: metot ajana bir komut gönderir, nihai yanıt bir geri çağırma ile gelir ve
VM'nin başlatıldığı düğüm olan data.node_id değerini içerir.
Pratik sonuç şudur: istemci beklemeyi bilmelidir. İstek zaman aşımını veritabanının hızına göre değil, düğümdeki gerçek işlemin süresine göre ayarlayın.
Başlamadan önce bilinmesi gerekenler
Oturum belirteci olmayan bir istek işlenmez. Neden: dağıtıcı çağıranı
yalnızca oturum belirteciyle tanımlar; aktarım başlıkları bunun için kullanılmaz.
Çözüm: belirteci her uygulama çağrısında sunun, aksi halde yanıt -9494 kodunu
içerir.
Bazı işlemler yanıt döndürüldükten sonra tamamlanır. Neden: işi düğümlerdeki ajanlar yapar, dağıtıcı ise yalnızca onların geri çağırmalarını bekler. Çözüm: ilk yanıta değil, metodun nihai yanıtına güvenin ve istemci zaman aşımında ek süre bırakın.
Görünmeyen bir OS imajı "erişim reddedildi" yerine "bulunamadı" döndürür.
Neden: başka bir VDC'ye ait özel bir imajın varlığı ifşa edilmez. Onu seçmeye
çalışırsanız vms-create, -256 döndürür. Çözüm: küme genelinde paylaşılan bir
imaj (is_cluster_shared) kullanın veya gerekli imaj için VDC'nize görünürlük
izni talep edin.
Sonraki adımlar
Oturum açmadan çalışan bir VM'ye kadar olan yolun tamamı hızlı başlangıç bölümünde ele alınmaktadır: VDC oluşturma, ağ atama, makine oluşturma ve başlatma ile konsoluna bağlanma.