Aracılığıyla paylaş


Azure Red Hat OpenShift için işlem temeli kılavuzu

Azure Red Hat OpenShift, isteğe bağlı olarak yüksek oranda ölçeklenebilir, tam olarak yönetilen OpenShift kümeleri sağlar. Yönetimi ve izlemeyi göz önünde bulundurarak çözümünüzü düzgün bir şekilde tasarlayarak operasyonel mükemmellik ve müşteri başarısı için çalışabilirsiniz.

Tasarım konusunda dikkat edilmesi gerekenler

Aşağıdaki faktörleri göz önünde bulundurun:

  • Kümelerle ilgili sorumlulukların Microsoft, Red Hat ve müşteriler arasında nasıl paylaşıldığından anlamak için Azure Red Hat OpenShift sorumluluk matrisini gözden geçirin.
  • Azure sanal makine sınırlarına ve desteklenen bölgelere dikkat edin. Kaynakları dağıtmak için kullanılabilir kapasite olduğundan emin olun.
  • İş yüklerini bir küme içinde mantıksal olarak ve fiziksel olarak ayrı kümelerde yalıtmanın yollarını unutmayın.
  • Kubernetes'in iş yüklerinizin durumunu anlamasına yardımcı olmanın yollarını unutmayın.
  • Çeşitli sanal makinelerin boyutlarını ve birini veya diğerini kullanmanın etkisini unutmayın.
  • Kaynaklarınızın durumu hakkında içgörüler elde etmek ve olası sorunları öngörmek için Azure Red Hat OpenShift'i izlemenin ve günlüğe kaydetmenin yollarını unutmayın. Hem küme hem de üstte çalışan uygulamalar birçok olay oluşturabilir. Geçmişe dönük amaçlarla günlük girdileri ile anında eylem gerektiren girdiler arasında ayrım yapmaya yardımcı olması için uyarıları kullanın.
  • Önemli sistem güncelleştirmelerine ve yükseltmelerine dikkat edin. Kritik yama güncelleştirmeleri Azure Red Hat OpenShift site güvenilirlik mühendisleri (SRE) tarafından kümelere otomatik olarak uygulanır. Düzeltme eki güncelleştirmelerini önceden yüklemek isteyen müşteriler bunu ücretsiz olarak yapabilir.
  • Kümenin kaynak sınırlamalarına ve tek tek iş yüklerine dikkat edin.
  • Yatay pod otomatik ölçeklendiricisi ile küme otomatik ölçeklendirmesi arasındaki farkları unutmayın.
  • Destek yaşam döngüsünü gözden geçirin ve sürüm destek ilkesini anlayın. Azure Red Hat OpenShift yalnızca Red Hat OpenShift Container Platform'un geçerli ve önceki genel kullanıma açık küçük sürümlerini destekler. Destek istekleri, kümenin desteklenen bir sürümde olmasını gerektirir.
  • Küme desteklenebilirliğini korumak için küme yapılandırma gereksinimlerini gözden geçirin.
  • Ağ ilkesini kullanarak küme içindeki trafiğin güvenliğini sağlamak için ad alanları arası ağı gözden geçirin.

Tasarım önerileri

  • Azure Red Hat OpenShift zengin bir operatör ekosistemine sahiptir ve operasyonel etkinlikleri verimlilik ve doğrulukla gerçekleştirmek ve otomatikleştirmek için kullanılmalıdır.
  • Uygulama durumunu izlemek için podlarınıza sistem durumu yoklamaları ekleyin. Podların canlılıkProbe ve hazır olmaProbe içerdiğine emin olun. Uygulamanın başlatıldığı noktayı belirlemek için Başlangıç yoklamalarını kullanın.
  • Birden çok kapsayıcı örneği içerecek kadar büyük olan sanal makine boyutlarını kullanarak artan yoğunluk avantajlarından yararlanabilirsiniz, ancak kümeniz başarısız bir düğümün iş yükünü işleyemeyecek kadar büyük değildir.
  • Güvenlik ilkesini, kaynak sınırlamalarını veya yapılandırma gereksinimlerini zorunlu kılmak için yaygın olarak kullanılan erişim eklentilerini kullanarak küme işlevlerini düzenleyin.
  • Küme içindeki işlem kaynaklarını yönetmek için pod isteklerini ve sınırlarını kullanın. Pod istekleri ve sınırları, işlem kaynaklarını bir pod'a atayan Kubernetes zamanlayıcısını bilgilendirir. Sınır aralıklarını kullanarak projedeki kaynak tüketimini kısıtlayın.
  • CPU ve bellek isteği değerlerini iyileştirin ve dikey pod otomatik ölçeklendiricisini kullanarak küme kaynaklarının verimliliğini en üst düzeye çıkarın.
  • OpenShift web konsolu düğüm düzeyindeki tüm ölçümleri içerir. Yerleşik Prometheus veya Container Insights tümleştirmesini kullanarak bir izleme işlemi oluşturun.
    • Prometheus, Azure Red Hat OpenShift 4.x kümeleri için önceden yüklenmiş ve yapılandırılmış olarak gelir.
    • Kapsayıcı İçgörüleri, küme Azure Arc özellikli Kubernetes'e eklenerek etkinleştirilebilir.
    • OpenShift günlüğü günlük toplayıcıları, depolama ve görselleştirme bileşenlerini dağıtır.
  • DevOps uygulamaları ve OpenShift Container Platform tarafından sağlanan Pipelines/GitOps gibi CI/CD çözümleri aracılığıyla uygulama teslim sürecini otomatikleştirin.
  • Kümenizin daha fazla dağıtımı desteklemek için kaynakları bittiğinde makineleri ölçeklendirmek için ClusterAutoScaler ve MachineAutoScaler'ı tanımlayın.
  • Makine havuzundaki hasarlı makineleri otomatik olarak onarmak için makine durumu denetimlerini dağıtın.
  • Yatay pod otomatik ölçeklendiricisini kullanarak podları talebi karşılayacak şekilde ölçeklendirin.
  • Doğrudan eyleme ihtiyaç duyulduğunda bildirim sağlamak için bir uyarı sistemi kullanın: Container Insights ölçüm uyarıları veya yerleşik Uyarı Kullanıcı Arabirimi.

İş sürekliliği ve olağanüstü durum kurtarma (BCDR)

Kuruluşunuzun belirli gereksinimlerini karşılamak için uygun Azure Red Hat OpenShift platform düzeyinde özellikler tasarlaması gerekiyor. Bu uygulama hizmetlerinin kurtarma süresi hedefi (RTO) ve kurtarma noktası hedefi (RPO) ile ilgili gereksinimleri vardır. Olağanüstü durum kurtarma için dikkat edilmesi gereken birçok nokta vardır. İlk adımınız, altyapınız ve uygulamanız için bir hizmet düzeyi sözleşmesi (SLA) tanımlamaktır. Azure Red Hat OpenShift için SLA hakkında bilgi edinin. Aylık çalışma süresi hesaplamaları hakkında bilgi için SLA ayrıntıları bölümüne bakın.

BCDR için tasarım konuları

Aşağıdaki faktörleri göz önünde bulundurun:

  • Azure Red Hat OpenShift kümesi, uygulamanız için en düşük kullanılabilirlik düzeyini sağlamak için birden çok makine kümesi kullanmalıdır.
  • Pod isteklerini ve sınırlarını ayarlayın. Bu sınırların ayarlanması Kubernetes'e şunları sağlar:
    • Cpu ve bellek kaynaklarını podlara verimli bir şekilde atayın.
    • Bir düğümde daha yüksek kapsayıcı yoğunluğuna sahip olmak.
    • Donanımın daha iyi kullanılması nedeniyle düşük maliyetlerle güvenilirliği artırın.
  • Daha yüksek kullanılabilirlik için düğümleri tüm kullanılabilir bölgelere yayma.
    • Kullanılabilirlik Alanları destekleyen bir bölge seçin.
    • Tam bölge avantajı için tüm hizmet bağımlılıklarının bölgeleri de desteklemesi gerekir. Bağımlı bir hizmet bölgeleri desteklemiyorsa, bölge hatası bu hizmetin başarısız olmasına neden olabilir. İş yükünü bölgelere dağıtırken kullanılan disk türlerini gözden geçirin.
    • Kullanılabilirlik Alanları elde edilebileceklerin ötesinde daha yüksek kullanılabilirlik için, farklı eşleştirilmiş bölgelerde birden çok küme çalıştırın. Azure kaynağı coğrafi olarak yedekliliği destekliyorsa, yedekli hizmetin ikincil bölgesine sahip olacağı konumu belirtin.
  • Uygulamalar ve veriler için sürekli yedeklemeler oluşturun.
    • Durum bilgisi olmayan bir hizmet verimli bir şekilde çoğaltılabilir.
    • Kümede durum depolamanız gerekiyorsa, eşleştirilmiş bölgede verileri sık sık yedekleyin.
  • Kümelerinizi yükseltin ve koruyun.
  • Yük devretme gerçekleşirse ağ bağlantısı için:
    • Trafiği bölgeler arasında dağıtmanız gerekiyorsa Azure Front Door kullanmayı göz önünde bulundurun.
  • Planlı ve planlanmamış yük devretme işlemleri için:
    • Her Azure hizmetini ayarlarken olağanüstü durum kurtarmayı destekleyen özellikleri seçin. Örneğin, Azure Container Registry seçilirse coğrafi çoğaltma için etkinleştirin. Bir bölge kapanırsa yine de çoğaltılan bölgeden görüntü çekebilirsiniz.
  • Hizmet düzeyi hedeflerine ulaşmak için mühendislik DevOps özelliklerini koruyun.

BCDR için tasarım önerileri

Tasarımınız için en iyi yöntemler şunlardır:

  • Azure Red Hat OpenShift kümeleri üç denetim düzlemi düğümü ve üç veya daha fazla çalışan düğümü ile sağlanır. Düğümlerin bölgelere yayılması için kümenin Kullanılabilirlik Alanları destekleyen bir bölgede oluşturulduğundan emin olun.
  • Yüksek kullanılabilirlik için bu düğümleri farklı Kullanılabilirlik Alanları dağıtın. Her Kullanılabilirlik Alanı için farklı makine kümelerine ihtiyacınız olduğundan en az üç makine kümesi oluşturun.
  • Denetim düzlemi düğümlerinde ek iş yükleri çalıştırmayın. Bunlar denetim düzlemi düğümlerinde zamanlanabilir ancak kümenin tamamını etkileyebilecek ek kaynak kullanımı ve kararlılık sorunlarına neden olur.
  • Altyapı bileşenlerini barındıracak altyapı makine kümeleri oluşturun. Bu makinelere belirli Kubernetes etiketlerini uygulayın ve ardından altyapı bileşenlerini yalnızca bu makinelerde çalışacak şekilde güncelleştirin.
  • Mümkün olduğunda kapsayıcıların içinden hizmet durumunu kaldırın. Bunun yerine, çok bölgeli çoğaltmayı destekleyen bir Hizmet olarak Azure platformu (PaaS) kullanın.
  • Dağıtımlar pod kaynak gereksinimlerini belirtmelidir. Zamanlayıcı daha sonra podu uygun şekilde zamanlayabilir. Podlar zamanlanmayan güvenilirlik önemli ölçüde kullanım dışıdır.
  • Donanım hataları gibi kesintileri işlemek için dağıtımda birden çok çoğaltma ayarlayın. Güncelleştirmeler ve yükseltmeler gibi planlı olaylar için kesinti bütçesi, beklenen uygulama yükünü işlemek için gerekli pod çoğaltması sayısının mevcut olmasını sağlayabilir.
  • Küme genelindeki düğümlerde podları otomatik olarak zamanlamak için pod topolojisi kısıtlamalarını kullanın.
  • Uygulamalarınız verileri için depolama kullanabilir ve gerekirse bölgeler arasında kullanılabilirlik sağlamalıdır:
  • Uygulama yedeklemesi oluşturun ve geri yüklemeyi planlayın:
  • Pod kaynak sınırlarını tahmin edin. Bir taban çizgisi sınayın ve oluşturun. İstekler ve sınırlar için eşit değerlerle başlayın. Ardından, kümede dengesizlik oluşturabilecek bir eşik oluşturana kadar bu değerleri aşamalı olarak ayarlayın. Pod sınırları dağıtım bildirimlerinizde belirtilebilir. Dikey pod otomatik ölçeklendiricisi CPU ve bellek isteği değerlerini iyileştirir ve küme kaynaklarının verimliliğini en üst düzeye çıkarabilir.
    • Yerleşik özellikler, hizmet mimarisindeki hataları ve kesintileri işleyebilir. Bu yapılandırmalar hem tasarım hem de dağıtım otomasyonlarını basitleştirmeye yardımcı olur. Bir kuruluş SLA, RTO ve RPO için bir standart tanımladığında, iş hedeflerine ulaşmak için Kubernetes ve Azure'da yerleşik olarak bulunan hizmetleri kullanabilir.
  • Uygulamanın yeni sürümlerini dağıtmak için mavi/yeşil veya kanarya stratejilerini göz önünde bulundurun.
  • Kümenin bakım işlemleri için kaldırmasına izin verilen pod çoğaltmalarının sayısını sınırlandırmak için pod önceliği/pod kesintisi bütçelerini ayarlayın ve böylece kullanılabilirliği sağlayın.
  • Hizmet ad alanları üzerinde kaynak kotalarını zorunlu kılma. Ad alanı üzerindeki kaynak kotası, pod isteklerinin ve sınırlarının dağıtımda düzgün şekilde ayarlanmasını sağlar.
    • Kaynak kotalarının küme düzeyinde ayarlanması, doğru isteklere ve sınırlara sahip olmayan iş ortağı hizmetleri dağıtılırken sorunlara neden olabilir.
  • Kapsayıcı görüntülerinizi Azure Container Registry depolayın ve kayıt defterini her bölgeye coğrafi olarak çoğaltın.
  • Azure ExpressRoute bağlantısı için birden çok bölge ve eşleme konumu kullanın. Bir Azure bölgesini veya eşleme sağlayıcısı konumunu etkileyen bir kesinti oluşursa, yedekli karma ağ mimarisi kesintisiz şirket içi bağlantılar sağlanmasına yardımcı olabilir.
  • Küresel sanal ağ eşlemesi ile bölgeler arasında bağlantı kurma. Kümelerin birbiriyle konuşması gerekiyorsa, her iki sanal ağı birbirine bağlamak sanal ağ eşlemesi aracılığıyla gerçekleştirilebilir. Bu teknoloji, farklı coğrafi bölgelerde bile Microsoft'un omurga ağı genelinde yüksek bant genişliği sağlamak için sanal ağları birbirine bağlı hale getirir.
  • Son kullanıcılarınızı en yakın Front Door POP'a (iletişim noktası) hemen bağlamak için bölünmüş TCP tabanlı herhangi bir noktaya yayın protokolü olan Azure Front Door'u kullanın. Azure Front Door'un diğer özellikleri şunlardır:
    • TLS sonlandırma
    • Özel etki alanı
    • Web Uygulaması Güvenlik Duvarı
    • URL yeniden yazma
    • Oturum benzeşimi

Sonraki adımlar

Azure giriş bölgelerinizde platform otomasyonu ve DevOps için tasarımla ilgili önemli noktalar ve öneriler hakkında bilgi edinin.