Azure Operatör Nexus, yığının tüm düzeylerinde fiziksel yedeklilik sağlar.
Operatör Nexus dağıtımını planlamaya yardımcı olmak için aşağıdaki adımları izleyin.
Dağıtımın barındırılacak şekilde boyutlandırılması gereken ilk iş yükü kümesini (Ağ İşlevleri) belirleyin.
Bu iş yüklerinin her biri için kapasite gereksinimlerini belirleyerek her biri için yedeklilik sağlar.
İş yükleriniz denetim düzlemi ve veri düzlemi öğeleri arasında bir bölmeyi destekliyorsa, daha fazla sayıda daha geniş dağıtılmış veri düzlemi sitelerini denetleyebilen denetim düzlemi sitelerini ayrı ayrı tasarlayıp tasarlamayabileceğinizi göz önünde bulundurun. Bu seçenek büyük olasılıkla daha büyük dağıtımlar için cazip olacaktır. Daha küçük dağıtımlar veya denetim düzlemi ile veri düzleminin ayrılmasını desteklemeyen iş yüklerine sahip dağıtımlar için, tüm sitelerin aynı olduğu homojen bir site mimarisi kullanmanız daha olasıdır.
Her site türünde gereken raf sayısını belirlemek için iş yükü örneklerinin dağıtımını planlayarak her bir rafın bir Operatör Nexus bölgesi olmasına olanak tanır. Platform, iş yükü örneklerinin tek tek sunucuların veya rafların hatalarına dayanıklı olacak şekilde dağıtılmasını sağlamak için bu bölgelerin kapsamında benzeşim/benzeşim karşıtı kurallar uygulayabilir. Benzeşim/benzeşim karşıtı kurallar hakkında daha fazla bilgi için bu makaleye bakın. Operatör Nexus Azure Kubernetes Service (NAKS) denetleyicisi, küme içindeki düğümleri diğer kısıtlamalar dahilinde mümkün olduğunca düzgün bir şekilde bir bölgedeki kullanılabilir sunucular arasında otomatik olarak dağıtır. Sonuç olarak, tek bir sunucunun başarısız olması kalan toplam kapasite üzerinde en düşük etkiye sahiptir.
Yükseltmedeki her site içinde gerekli olan eşik yedekliliğini dikkate alın. Bu yapılandırma seçeneği, bir platform yükseltmesinin başarılı olarak kabul edilmesi ve devam etmesi için kullanılabilir olması gereken en az çalışan düğümü sayısını düzenleme altyapısına gösterir. Bu düğümleri ayırmak herhangi bir kapasite odasında yer alır. Daha yüksek bir çubuk ayarlamak, dağıtımın tek tek düğümlerin başarısız olmasına dayanıklılığını azaltır, ancak kullanılabilir kapasitenin kullanım verimliliğini artırır.
Operatör Nexus, her raf 4, 8, 12 veya 16 sunucu içeren site başına dahil olmak üzere 1 ile 8 arasında raf destekler. Sunucu sayısı açısından tüm raflar aynı olmalıdır. İş yükleri için kullanılabilen kaynağın ayrıntıları için buraya bakın. Etkileyebilecek diğer sınırlar ve kotalar için aşağıdaki diyagrama ve bu makaleye bakın.
Operatör Nexus bir veya iki depolama aletini destekler. Şu anda bu diziler Kubernetes düğümleri olarak çalışan iş yükü NF'leri tarafından kullanılabilir. VM olarak çalışan iş yükleri, örnekledikleri sunucudan yerel depolama kullanır.
Dikkate alınması gereken diğer faktörler, kullanılabilir fiziksel sitelerin sayısı ve bant genişliği veya güç gibi site başına sınırlamalardır.
Şekil 1 - Tek bir sitedeki İşleç Nexus öğeleri
Çoğu durumda kapasite planlaması yinelemeli bir süreçtir. Bu süreci daha anlaşılır hale getirmek için araçları olan Microsoft hesabı ekibinizle birlikte çalışın.
Abone büyümesi veya platforma geçirilen iş yükleri nedeniyle altyapıya olan talep zaman içinde arttıkça Operatör Nexus dağıtımı, tek bir sitenin sınırlamaları (güç, alan, bant genişliği vb.) gibi ölçütlere bağlı olarak mevcut sitelere daha fazla raf eklenerek veya yeni siteler eklenerek ölçeklendirilebilir.
İş Yükü Yedekliliği Gereksinimlerini Dikkate Alma
Her iş yükünü, bir raftaki tek bir sunucunun arızasını, rafın tamamının arızasını ve sitenin tamamının arızasını karşılayacak şekilde boyutlandırmanızı öneririz.
Örneğin, her sitede 4 raf ve her rafta 12 sunucu içeren 3 site dağıtımı düşünün. Yoğun yükteki ağ talebini karşılamak için dağıtımın tamamında 400 düğüm gerektiren bir iş yükü düşünün. Bu iş yükü kritik altyapınızın bir parçasıysa, yoğun yük zamanlarında hataları işlemek için "ölçeği artırma" özelliğine geçiş yapmak istemeyebilirsiniz. Yedek kapasitenin her zaman hazır olmasını istiyorsanız kullanılmayan, boşta kalan kapasiteyi ayırmanız gerekir.
Site, raf ve tek tek sunucu hatalarına karşı yedeklilik elde etmek istiyorsanız hesaplamalarınız şöyle görünür:
İş yükü, yoğun yükteki ağ talebini karşılamak için dağıtımın tamamında toplam 400 düğüm gerektirir.
Üç siteye yayılmış 400 düğümün olması için site başına 134 düğüm gerekir (sabit maliyetleri yoksayma). Bir sitenin başarısız olması site başına 200 düğüme çıkar (bu nedenle tek bir sitenin başarısız olması 400 düğümü çalışır durumda bırakır).
Bir sitede dört rafa yayılmış 200 düğüme sahip olmak için raf düzeyinde yedeklilik olmadan raf başına 50 düğüm gerekir. Bir rafın arızalanması gereksinimini raf başına 67 düğüme yükseltir.
Raf başına 12 sunucuya yayılmış 67 düğüme sahip olmak için, raftaki bir sunucunun başarısız olmasını sağlamak için sunucu başına altı düğüm gerekir ve iki sunucu yedi sunucuya ihtiyaç duyar.
İlk gereksinim dağıtım genelinde 400 düğüm için olsa da, tasarım aslında 888 düğümle sona erer. Diyagram, her düzeyden sunucu başına düğüm sayısına katkıyı gösterir.
Başka bir iş yükü için birden çok yedeklilik düzeyini "katmanlamamayı" seçebilirsiniz. Bu, bir sitenin eş zamanlı başarısızlığını, başka bir sitedeki bir rafın ve aynı sitedeki başka bir raftaki sunucunun aşırı yüklendiğini gösterir. Sonuçta en uygun tasarım, iş yükü tarafından sunulan hizmete ve iş yükünün ayrıntılarına, özellikle de yük dengeleme işlevine bağlıdır. Çeşitli hata modlarını tanımlamak için markov zincirlerini kullanarak hizmeti modellemek, hangi hataların aynı anda gerçek zamanlı olarak gerçekleşebileceğini belirlemeye de yardımcı olabilir. Örneğin, sunucu hatası nedeniyle belirli bir sitenin kapasitesi azaldığında geri baskı uygulayabilen bir iş yükü, trafiği hala tam yedekliliğe sahip kalan sitelerden birine yönlendirebilir.
Site Dağıtımı ve Bağlantısı
Her Operatör Nexus sitesi, Küme Yöneticisi, Operatör Nexus Doku Denetleyicisi gibi Azure içi kaynakları barındıran bir Azure bölgesine bağlanır. İdeal olarak, Operatör Nexus dağıtımının Azure bölgelerindeki herhangi bir kesintiye dayanıklılığı en üst düzeye çıkarmak için her Operatör Nexus sitesini farklı bir Azure bölgesine bağlayın. Coğrafyaya bağlı olarak, dağıtımın bağımlılık aldığı farklı Azure bölgelerinin sayısını en üst düzeye çıkarmakla veri yerleşimi veya egemenliği ile ilgili diğer kısıtlamalar arasında büyük olasılıkla bir denge vardır. Ayrıca, şirket içi örneklerle Küme Yöneticisi arasındaki ilişkinin 1:1 olması gerekmeyebilir. Tek bir Küme Yöneticisi birden çok sitedeki örnekleri yönetebilir.
Sanal Ağ İşlevleri (VNF' ler) ve Operatör Nexus Azure Kubernetes Service (AKS) dahil olmak üzere sanal makineler ve Operatör Nexus içinde şirket içinde barındırılan hizmetler, bunlar ile ağ dokusu arasında yüksek oranda kullanılabilir bağlantılar aracılığıyla bağlantı ile sağlanır. Bu gelişmiş bağlantı, Sanal İşlev Bağlantısı Toplama (VF-Lag) teknolojisini kullanan Tek Kök Giriş/Çıkış Sanallaştırma (SR-IOV) arabirimleri tarafından sorunsuz bir şekilde kolaylaştırılan yedekli fiziksel bağlantıların kullanılmasıyla sağlanır.
VF-Lag teknolojisi, sanal işlevlerin (VFS) fiziksel ağ arabirim kartındaki (NIC) bir bağlantı noktası çifti arasında mantıksal bir Bağlantı Toplama Grubuna (LAG) toplanmalarını sağlar. Bu özellik, yüksek oranda kullanılabilir tek bir sanal işlevi kullanıma sunarak güçlü ve güvenilir ağ performansı sağlar. Bu teknoloji, kullanıcıların avantajlarından yararlanması için yapılandırma gerektirmez, dağıtım sürecini basitleştirir ve genel kullanıcı deneyimini geliştirir.
Kullanılabilirlik için Diğer Ağ Konuları
Operatör Nexus altyapısı ve iş yükleri, Etki Alanı Adı Sistemi'ni (DNS) kapsamlı bir şekilde kullanır. Operatör Nexus platformunda yetkili DNS yanıtlayıcısı olmadığından, Operatör Nexus sitesinin Azure bağlantısı kesilirse DNS isteklerine yanıt verecek bir şey yoktur. Bu nedenle, tüm DNS girişlerinin istenen maksimum bağlantı kesme süresiyle (genellikle şu anda 72 saat) tutarlı bir Yaşam Süresi (TTL) olduğundan emin olun.
İşleç Nexus yönlendirme tablolarında, yönlendirme tablolarını ağ hatalarına uyum sağlayacak şekilde değiştirebilmek yerine önceden yapılandırılmış yedekli yollar olduğundan emin olun. Bu yapılandırma genel olarak iyi bir uygulama olsa da, İşleç Nexus sitesinin Azure bölgesiyle bağlantısı kesilirse Operator Nexus Network Fabric Controller'a ulaşılamayacak olması işleç Nexus için daha önemlidir. Bu durumda, Azure bağlantısı geri yüklenene kadar ağ yapılandırması etkin bir şekilde dondurulur (cam kesme işlevinin kullanılması önlenmiş olur). Ayrıca, ihtiyaç duyulana kadar algılanmayan bu yolların "sessiz hatalarından" kaçınmak için arka plan trafiğinin sürekli olarak geçişini sağlamak en iyi yöntemdir.
Kimlik ve Kimlik doğrulaması
Bağlantı kesilmesi olayı sırasında, şirket içi altyapı ve iş yükleri kullanıcı kimlik doğrulaması gerçekleştirmek için Entra'ya ulaşamaz. Bağlantı kesilmesine hazırlanmak için tüm gerekli kimliklerin ve bunların ilişkili izinlerinin ve kullanıcı anahtarlarının önceden yapılandırıldığından emin olabilirsiniz. Operatör Nexus, operatörün bu işlemi otomatikleştirmek için kullanabileceği bir API sağlar. Bu bilgilerin önceden yapılandırılması, Altyapıya kimliği doğrulanmış yönetim erişiminin Entra bağlantısı kaybıyla engellenmeden devam etmesini sağlar.
Platform Yükseltmesini Yönetme
Operatör Nexus yükseltmesi müşteri tarafından başlatılır, ancak ardından platformun kendisi tarafından yönetilir. Kullanılabilirlik açısından aşağıdaki noktalar önemlidir:
Müşteri yükseltmede tam denetime sahiptir. Örneğin, yükseltmeyi bir bakım penceresinde başlatmayı tercih edebilir ve kendi Güvenli Dağıtım İşlemlerini uygulayabilir. Örneğin, yeni bir sürüm aşamalı olarak bir laboratuvar sitesine, küçük bir üretim sitesine, daha büyük üretim sitelerine dağıtılabilir ve teste olanak tanıyabilir ve gerekirse geri alabilir.
İşlem, seçilen sitede aynı anda yalnızca bir rafta etkindir. Yükseltme yerinde yapılmış olsa da, yükseltme sırasında raftaki çalışan düğümleri üzerinde hala bazı etkiler vardır.
Yükseltme işlemi hakkında daha fazla bilgi için bu makaleye bakın. Kontrol düzlemi dayanıklılığını sağlama hakkında daha fazla bilgi için buna bakın.
Operatör Nexus için Yüksek Kullanılabilirlik İş Yüklerini Tasarlama ve Çalıştırma
İş yükleri, operatör Nexus bölge kavramı kullanılarak bir sitedeki birden çok düğüm ve rafa dağıtılabilir N+k kümeleri ile bulutta yerel bir tasarıma uygun olmalıdır.
Azure'da görev açısından kritik ve operatör sınıfı iş yükleriyle ilgili İyi Tasarlanmış Çerçeve kılavuzu, Operatör Nexus'ta iş yükleri için de geçerlidir.
Herhangi bir platformda yüksek oranda kullanılabilir iş yükleri tasarlamak ve uygulamak için yukarıdan aşağıya bir yaklaşım gerekir. Bir bütün olarak çözümden gerekli kullanılabilirliği anlamakla başlayın. Çözümün temel öğelerini ve bunların tahmin edilen kullanılabilirliğini göz önünde bulundurun. Ardından, çözüm düzeyi hedeflerine ulaşmak için bu özniteliklerin nasıl birleştirilmesi gerektiğini belirleyin.
İş Yükü Yerleştirme
Operatör Nexus, kullanılabilir çalışan düğümleri arasında iş yüklerinin nasıl dağıtıldığını denetlemek için Kubernetes düzenleyiciye ipuçları sağlamaya yönelik kapsamlı destek sunar. Tüm ayrıntılar için bu makaleye bakın.
Yapılandırma Güncelleştirmeleri
Operatör Nexus platformu, tüm yapılandırma güncelleştirmelerini işlemek için Azure Resource Manager'ı kullanır. Bu, platform kaynaklarının diğer Azure kaynaklarıyla aynı şekilde yönetilmesine olanak sağlayarak kullanıcıya tutarlılık sağlar.
Operatör Nexus üzerinde çalışan iş yükleri, Resource Manager'ın sunduğu her şeyden yararlanmak için kendi Kaynak Sağlayıcılarını (RP) oluşturarak benzer bir modeli izleyebilir. Resource Manager güncelleştirmeleri yalnızca Şirket içi NF'lere, Operatör Nexus sitesi Azure Bulut'a bağlıyken uygulayabilir. Disconnect olayı sırasında bu yapılandırma güncelleştirmeleri uygulanamaz. Üretimdeyken yapılandırmalarını güncelleştirmek yaygın olmadığından bu, Operatör Nexus IP'leri için kabul edilebilir olarak kabul edilir. Bu nedenle iş yükleri yalnızca aynı varsayım geçerliyse Resource Manager kullanmalıdır.
İş Yükü Yükseltme
Genel Bulut ortamından farklı olarak, Hibrit Bulut platformu olarak Operatör Nexus kullanılabilir kapasite açısından daha kısıtlıdır. Telco müşterisi ile iş yükü sağlayıcısı arasındaki düzenlemenin ayrıntılarına bağlı olarak müşteri veya potansiyel olarak iş yükü sağlayıcısı tarafından yönetilmesi gereken iş yükü örneklerini yükseltme işlemini tasarlarken bu kısıtlamanın dikkate alınması gerekir.
İş yükü yükseltmesi için çeşitli seçenekler vardır. Kapasite açısından en verimli ve en az etkili olan, naks tarafından desteklenen standart Kubernetes işlemlerini kullanarak her iş yükü kümesinin sıralı yükseltmesini "yerinde" uygulamaktır. Bu, Operatör Nexus undercloud tarafından benimsenen işlemdir. Müşterinin laboratuvar ve hazırlama ortamlarına sahip olması önerilir; böylece üst düzey iş yükü yazılımı, laboratuvar trafiği için müşterinin hassas ağında doğrulanabilir ve ardından üretim varlığının tamamında kullanıma sunulmadan önce sınırlı ölçekte doğrulanabilir.
Alternatif bir seçenek, üst düzey yazılım sürümünü "yeşil alan" kümesi olarak dağıtmak ve trafiği belirli bir süre boyunca bu kümeye geçiş yapmaktır. Bu, uç durumlara neden olabilecek "karma düzeyli" bir kümenin herhangi bir döneminden kaçınma avantajına sahiptir. Ayrıca, trafiğin alt düzeyden üst düzey yazılıma ihtiyatlı bir şekilde aktarılmasına ve herhangi bir sorun bulunması durumunda basit ve güvenilir bir geri alma işlemine olanak tanır. Ancak, paralel çalışan iki kümeyi desteklemek için yeterli kapasite gerektirir. Bu, alt düzey kümenin ölçeği azaltılarak, işlemdeki en yüksek yükler için yedeklilik ve izinlerin bir kısmını veya tümünü kaldırarak gerçekleştirilebilir.
Az Azure HPC a HPC & AI számítási feladatok célhoz kötött felhőalapú képessége, amely élvonalbeli processzorokat és HPC-osztályú InfiniBand-összekapcsolásokat használ, így a legjobb alkalmazásteljesítményt, méretezhetőséget és értéket nyújtja. Az Azure HPC lehetővé teszi a felhasználók számára az innovációt, a termelékenységet és az üzleti rugalmasságot a magas rendelkezésre állású HPC & AI-technológiák révén, amelyek az üzleti és technikai igények változásával dinamikusan lefoglalhatók. Ez a képzési terv o
