Feragatname

Aşağıdaki bilgiler, genel ürün yönelimimizi özetlemeyi amaçlamaktadır. Yalnızca bilgilendirme amaçlıdır ve hiçbir sözleşmeye dahil edilemez. Herhangi bir malzemenin, kodun veya fonksiyonun sunulacağına yönelik bir taahhüt niteliğinde değildir ve satın alma kararları verirken temel alınmamalıdır. Oracle ürünleri için belirtilen herhangi bir özelliğin veya fonksiyonun geliştirilmesi, yayımlanması, zamanlaması ve fiyatlandırması değişebilir ve yalnızca Oracle'ın takdirine bağlıdır.

Bu SSS, Oracle'ın çekirdek altyapı hizmetlerinde ve barındırma platformunda esnekliği ve sürekli erişilebilirliği nasıl sağladığıyla ilgili yaygın olarak sorulan soruları yanıtlamaktadır. Oracle Bulut müşterileri birkaç nedenden ötürü bu yanıtlarla ilgilenebilirler:

  • Yanıtlar, Oracle'ın barındırma platformunu ve hizmetlerini değerlendirirken gerekli özeni gösterme konusunda yardımcı olur.
  • Yanıtların pek çoğu tüm bulut ölçekli sistemlerin temelini oluşturan zorluklardan ve çözümlerden bahsetmektedir, bu nedenle müşterilerin bulutta oluşturmak istediği sistem mimarisi ve tasarımı konusunda onları bilgilendirir.

Oracle Bulut Altyapısı Hizmetleri ve Platformu Esneklik ve Sürekli Erişilebilirlik SSS

Oracle kritik hizmetler, sürekli erişilebilir hizmetler veya tek konumlu hizmetler gibi farklı hizmet sınıfları ayrımı yapıyor mu?

Bu tür ayrımlar yapmıyoruz. Bunun yerine hizmetlerimizi bağımlılık düzeyi, erişilebilirlik kapsamı ve veri düzlemi veya kontrol düzlemi bazında kategorize ediyoruz. Bu kategoriler erişilebilirlik, dayanıklılık, performans ve kolaylık açısından farklılıkları göstermek için tasarlanmıştır.

Bağımlılık Düzeyleri

Bu düzeyler, bir mimari blok diyagramındaki katmanlar veya kademeler olarak düşünülebilir. Her katman yalnızca altındaki katmanlara bağımlı olabilir.

Alttan üste:

  • Çekirdek hizmetler: Bu hizmetler Oracle Bulut Altyapısı'nın temelini oluşturur. Bu katman Kimlik ve Erişim Yönetimi (IAM), Anahtar Yönetimi, Ağ Bağlantısı, Hesaplama, Blok Birimler, Nesne Depolama, Telemetri ve birkaç paylaşılan dahili hizmetten oluşur. Bu hizmetler kendi aralarında dahi en az bağımlılığa sahip olacak şekilde tasarlanmıştır. (Bağımlılıklarla ilgili detaylar için bu dokümanın ilerisindeki bölümlere bakın.)
  • IaaS: Bu katman çekirdeğin üzerinde oluşturulan, daha altyapı düzeyi fonksiyonlar sağlar. Bu katmandaki hizmetler Dosya Depolama, Veritabanı ve Kubernetes için Kapsayıcı Motoru'dur.
  • SaaS: Bu katman, alt katmanların üzerinde oluşturulan zengin bir yazılım hizmeti katmanıdır.
Erişilebilirlik Kapsamı

Bir hizmetin erişilebilirlik ve dayanıklılık hedeflerine ulaşmak amacıyla tüm hizmetler için şu erişilebilirlik katmanlarından biri seçilir:

  • Erişilebilirlik etki alanı yerel: Her bir erişilebilirlik etki alanı, hizmetin bağımsız bir anını içerir. Bu tip hizmetler, aynı erişilebilirlik etki alanındaki replikalar arasında anuyumlu çoğaltma kullanarak depolanan verilere yönelik yüksek dayanıklılık sunar (detaylar için bu dokümanın ilerisindeki hata etki alanı bölümüne bakın). Hizmetin doğasına bağlı olarak bu hizmetler erişilebilirlik etki alanındaki altyapının üçte biri veya daha fazlasının kesintiye uğramasını kaldırabilir. Erişilebilirlik etki alanı yerel hizmetleri, erişilebilirlik etki alanında iki farklı tür mantıksal veri merkezi kullanarak bu hata toleransı düzeyine ulaşır: hata yalıtımı ve performans yalıtımı mantıksal grupları. Detaylar için bu dokümanın ilerisindeki hata etki alanları ve hizmet hücreleri bölümüne bakın. Son olarak bu hizmetler, erişilebilirlik etki alanı diğer hiçbir erişilebilirlik etki alanı ile iletişim kuramazken bile olağan şekilde çalışmaya devam edebilir. Bu sayede diğer erişilebilirlik etki alanlarının kaybını veya bölgedeki geniş iletişim ağının tamamen arızalanmasını kaldırabilir.
  • Çok sayıda erişilebilirlik etki alanı bölgesel: Birden çok erişilebilirlik etki alanına sahip tüm bölgeler, hizmetin bağımsız bir anını içerir ve bölgedeki her bir erişilebilirlik etki alanında bileşenleri bulunur. Bu hizmetler, aynı bölgedeki birden çok erişilebilirlik etki alanında anuyumlu çoğaltma kullanarak depolanan verilere yönelik çok yüksek dayanıklılık sunar. Bu hizmetler bölgede bulunan herhangi bir tek erişilebilirlik etki alanındaki kesintiyi veya iletişim arızasını kaldırabilir.
  • Tek erişilebilirlik etki alanı bölgesel: Bir bölge yalnızca bir erişilebilirlik etki alanı içeriyorsa bölgesel hizmetlerin gözlemlenebilen özellikleri, önceden açıklandığı gibi yerel bir erişilebilirlik etki alanı hizmetinin özellikleriyle eşleşir. Bir erişilebilirlik etki alanı yerel hizmetiyle tek erişilebilirlik etki alanı bölgesel hizmeti arasındaki fark, yalnızca tek erişilebilirlik etki alanı bölgesi bir veya daha fazla erişilebilirlik etki alanı eklenerek genişletildiğinde ortaya çıkar. Bu yapıldığında bölgesel hizmetlerin tümü, hizmetin tek bir anı olarak kalırken yeni erişilebilirlik etki alanlarını düzgün biçimde kullanmak için otomatik olarak genişler. Örneğin Nesne Depolama veri düzlemi, mevcut verilerin dayanıklılığını artırmak için ek erişilebilirlik etki alanlarını kullanmak üzere genişler. Ancak erişilebilirlik etki alanı yerel hizmetlerinde, yeni erişilebilirlik etki alanlarından her biri kendine ait yeni ve ayrı erişilebilirlik etki alanı yerel hizmeti anlarına sahip olur.
  • Bölgelere dağıtılmış: Oracle Bulut Altyapısı'nın temel prensiplerinden biri, her bölgenin operasyonel açıdan diğerlerinden olabildiğince bağımsız olmasıdır. Buradaki olabildiğince ifadesi, bölgelerin örneğin bölgeler arası omurga ağı gibi bir kısım altyapıyı paylaşmak zorunda olduğunu belirtmektedir. Bunun dışında bölgeler arasında, şeffaf yüksek erişilebilirlik veya hata olduğunda adres devri gibi aynı anda birden fazla bölgeyi etkileyen sorunlara yol açabilecek sabit bağlantı mekanizmaları kullanmıyoruz. Bölgelere hizmet dağıtmak için bunun yerine gevşek bağlantılı iki mekanizma sağlıyoruz:
    • Yıkım Onarımı: Müşterilerimizin yıkım onarımı özelliklerine sahip sistemler oluşturmasını sağlamak, bulut yaklaşımımızın ve yatırımımızın temel taşlarından biridir. Blok Birimler bölgeler arası yedekleme ve Nesne Depolama bölgeler arası kopyalama gibi birkaç çekirdek hizmet halihazırda yıkım onarımı mekanizmaları sunmaktadır. Tüm hizmetlerimizin yol haritasında yıkım onarımı fonksiyonu yüksek önceliğe sahiptir.
    • Bölgeler arası abonelikler: Şu anda yalnızca Kimlik ve Erişim Yönetimi verileri için bölgeler arası abonelik sağlıyoruz. Kavramsal açıdan Kimlik ve Erişim Yönetimi verileri global kapsama sahiptir. Müşteriler bir dizi bölgeye abone olabilir (abonelik seçebilir), biz de ilgili Kimlik ve Erişim Yönetimi verileriyle ardından gelen güncellemeleri belirtilen bölgelere çoğaltırız. Çoğaltma, sabit bağlantıyı önlemek amacıyla zamanuyumsuz ancak sonuçta tutarlı olarak yapılır. Müşteriler kendileri belirlediği "ana" bölgede Kimlik ve Erişim Yönetimi verilerinde değişiklik yapabilir. Geçerli ana bölge herhangi bir nedenle erişilemez veya kullanılamaz duruma gelirse farklı bir bölge belirlenebilir.
Kontrol Düzlemi ve Veri Düzlemi Karşılaştırması

Bir hizmetin veri düzlemi, hizmetin uygulamalar tarafından kullanılması amaçlanan fonksiyonelliğini gerçekleştiren, veri işleyen arayüzlerin ve bileşenlerin toplamıdır. Örneğin sanal bulut ağı (VCN) veri düzleminde ağ paketi işleme sistemi, sanallaştırılmış yönlendiriciler ve ağ geçitleri bulunurken Blok Birimler veri düzleminde birim verileri için internet SCSI protokolünün uygulaması ve hata toleranslı çoğaltılmış depolama sistemi bulunur.

Bir hizmetin kontrol düzlemi ise şu görevlerle yükümlü bir dizi uygulama programı arabirimi ve bileşendir:

  • Müşteri taleplerini sağlama aşamasına kadar işlemek; kaynakları yeniden konfigüre etmek, ölçeğini artırmak/azaltmak veya sonlandırmak
  • Büyük filolara otomatik yamaları hızla ve güvenli bir şekilde uygulamak
  • Hatalı, bozulmuş veya yanlış konfigüre edilmiş kaynakları algılamak
  • Otomatik onarım gerçekleştirmek veya yardım için insan operatörleri çağırmak
  • Diğer kontrol düzlemleriyle işbirliği yapmak (yani LaunchInstance sırasında Hesaplama, VCN ve Blok Depolama bağlanır)
  • Kullanılmayan kapasiteyi yönetmek
  • Örneğin yeni ekipman ulaştığında veya fiziksel onarım & bakım durumlarında insanlarla işbirliği yapmak
  • Operasyonel görünürlük ve kontrol sağlamak
 
 

Oracle hizmetlerin esnek ve sürekli erişilebilir kalmasını nasıl sağlıyor?

Tüm hizmet tipleri için esneklik ve erişilebilirlik sağlamak adına aynı mühendislik ilkelerini kullanıyoruz çünkü hata toleranslı, ölçeklenebilir ve dağıtılmış sistemler oluşturmanın mühendislik açısından zorlukları tüm hizmet tiplerinde aynıdır.

Bulut ölçekli sistemlerde esnekliği ve sürekli erişilebilirliği sağlamak için erişilemezlik (düşük performans ve giderilmeyen hatalar) nedenlerini anlayıp ardından bunlarla ilgilenmek gerekir. Bu nedenler çok sayıda olabilir, dolayısıyla bunları temel özelliklerine göre kategorilere ayırıyoruz.

Kurumsal BT sistemlerinin erişilebilirlik analizi geleneksel olarak donanım arızaları kategorisine odaklanır. Ancak bulut sistemlerinde donanım arızaları nispeten önemsiz ve çözümü bilinen bir sorundur. Çoğu tek donanım hatası noktasını önlemek veya azaltmak artık eskisine göre daha kolaydır. Örneğin raflarda çift güç akışı ve bunlarla ilişkili güç dağıtım birimleri olabilir ve pek çok bileşen çalışırken değiştirilebilir nitelikte olabilir. Doğal afetler gibi sebeplerle büyük ölçekli donanım arızası ve kaybı olasılığı tabii ki vardır. Ancak kendi deneyimimize ve diğer bulut satıcılarının herkese açık son durum raporlarına göre bütün bir veri merkezinin arızası veya kaybı, diğer erişilemezlik sebeplerine kıyasla son derece nadir görülmektedir. Büyük ölçekli donanım arızalarının yine de giderilmesi gerekir (örneğin yıkım onarımı ve diğer mekanizmalarla) ancak bu arızalar en yaygın erişilebilirlik sorunu olmaktan çok uzaktır.

Bulut ölçekli sistemlerdeki en yaygın erişilemezlik sorunları şunlardır:

  1. Yazılım hataları
  2. Konfigürasyon hataları
  3. İnsan operatörler tarafından yapılan yanlışlıklar
    Not: Endüstriden çıkardığımız derse göre bu üç insan hatası çeşidi, erişilemezlik sorunlarının açık ara en büyük nedenleridir. Bu hataların sıklığı araçlarla, otomasyonla ve eğitimle azaltılabilse de tamamen ortadan kaldırılması mümkün değildir. Bu nedenle sistemin mimarisinde, tasarımında ve uygulamasında birincil olarak bu hatalarla ilgilenilmelidir.
  4. Performansta (gecikmede veya aktarım hızında), şunlar da dahil olmak üzere çeşitli nedenlerle meydana gelen kabul edilemez oynamalar:
    • Çok sayıda geçici kullanıcı durumunda "gürültülü komşu" sorunu (hizmet kalitesi mekanizmalarında hata)
    • Gerekli işleri yapmaya devam ederken, yanlışlıkla meydana gelen veya kötü amaçlı aşırı yükü etkin bir şekilde reddedememe
    • Yayılmış performans düşüşü, mesaj yağmuru, yeniden deneme yağmuru ve "ortaya çıkan" diğer pahalı etkileşimler
    • Güç döngüsü (özellikle birden fazla sistemin güç döngüsü) sonrasında soğuk şok (boş önbellek)
    • Sistemi ölçeklendirirken (örneğin veritabanını yeniden bölerken) fazla işleme süresi
  5. Yukarıda bahsedilen sorunlardan herhangi birinde "etki alanını" (etkilenen müşteri ve sistem sayısını) kısıtlama hatası

Bunlar genelgeçer zorluklardır ve bulut ölçekli dağıtılmış sistemlerin "fizik kurallarındandır".

Yukarıdaki tüm kategorilere ait sorunları gidermek için kanıtlanmış mühendislik stratejileri kullanıyoruz. Bunlardan en önemlileri şunlardır:

  • Mimari ve sistem tasarımı ilkeleri
  • Yeni mimari kavramlar (genellikle ilkelerin uygulanması sonucu ortaya çıkar)
  • Hizmet mühendisliği prosedürleri
Mimari ve Sistem Tasarımı İlkeleri

Bu tür pek çok ilke mevcut ancak yalnızca esneklik ve erişilebilirlikle ilgili olanlara odaklanacağız.

Kurtarma Tabanlı Hesaplama

Operatörlerden kaynaklı ve nispeten yerel etkileri olan yazılım hatalarını ve yanlışlıklarını gidermek için kurtarma tabanlı hesaplama ilkelerini izliyoruz1. Yüksek düzeyde bu hiçbir sorun yaşamamamızı sağlamak yerine (test edilemez) sorunları dikkat çekmeden, test edilebilir bir şekilde çözmek anlamına gelir. Özellikle, ortalama algılama süresi, ortalama tanı koyma süresi ve ortalama azaltma süresinin birleşimi olan ortalama kurtarma süresini en aza indirmeye çalışıyoruz.

İnsanların sorun yüzünden sıkıntı yaşamaması için hızla kurtarma işlemi yapmayı hedefliyoruz. Şu noktalar bu hedefe ulaşmamıza yardımcı oluyor:

  • Kod içinde yaygın onay kullanımı ile hata ve yanlışlıkları hızla ve otomatik olarak algılama ve tüm düzeylerde etkin izleme ve uyarı.
  • Gevşek bağlantılı, yani bozulabilecek belleği paylaşmayan pek çok detaylı yalıtım birimine (iş parçacıkları, işlemler, fiberler, statü makineleri vb.) ayrılan paket fonksiyonelliği.
  • Hata veya operatör tarafından yapılan bir yanlışlık algılandığında ilgili yalıtım birimini olabildiğince hızlı bir şekilde otomatik olarak yeniden başlatma. Yeniden başlatma, düzgün test edilmiş bir durumu geri getirmeye çalıştığından ve sabitleri geri yüklediğinden rastgele bir arızadan kurtarmanın pratik bir yoludur.
  • Detaylı yalıtım düzeyinde kurtarma işe yaramazsa (örneğin düzeydeki onaylar çok sık harekete geçmeye devam ederek döngüsel çökmeye yol açarsa) bir sonraki en büyük birime (işlem, çalışma zamanı, ana bilgisayar, mantıksal veri merkezi, insan operatör çağırma) geçme.
  • Hatalı kaydetmeleri hızla belirlemek ve geri almak için "sistem çapında geri alma" işlemi gerçekleştirmeye yönelik, tüm kalıcı durum ve konfigürasyonları sürümlendirme de dahil olmak üzere mekanizmalar oluşturma.

Sorunların Etkilerini En Aza İndirme

Daha geniş etkileri olabilecek hatalarla ve yanlışlıklarla ilgilenmek için sorunların "etki alanını" en aza indirmeye yönelik mekanizmalar oluşturuyoruz. Yani herhangi bir sorundan (çok sayıda geçici kullanıcı durumunda "gürültülü komşu", aşırı yük sunma, azaltılan kapasite ve yayılmış performans düşüşü gibi) etkilenebilecek müşteri, sistem veya kaynak sayısını en aza indirmeye odaklanıyoruz. Bunu, çeşitli yalıtım sınırları ve yönetim değiştirme uygulamaları kullanarak yapıyoruz (aşağıdaki bölümlere bakın).

Tasarım İlkelerinden Doğan Mimari Kavramlar

Bu tür pek çok kavram mevcut ancak yalnızca etki alanını sınırlamayla ilgili olanlara odaklanacağız.

Genel uygulama programı arabirimimizdeki En Önemli Yerleşim Kavramları: Bölgeler, Erişilebilirlik Etki Alanları ve Hata Etki Alanları

Hata etki alanları nispeten yeni olduğundan bunları daha detaylı olarak açıklayacağız.

Hata etki alanları dağıtımlar, yama uygulama, hiper yönetici yeniden başlatma ve fiziksel bakım gibi işlemlerle bir sistem etkin olarak değiştirildiğinde sorunların etki alanını sınırlamak için kullanılır.

Buradaki garanti, herhangi bir erişilebilirlik etki alanında belirli bir zamanda en fazla bir hata etki alanındaki kaynakların değiştiriliyor olmasıdır. Değişiklik işleminde bir şeyler ters giderse o hata etki alanındaki kaynaklardan bazısı bir süreliğine erişilemez hale gelebilir ancak erişilebilirlik etki alanındaki diğer hata etki alanları bundan etkilenmez. Oracle Veri Koruyucu gibi yeter sayı tabanlı çoğaltma sistemlerinin tek bir erişilebilirlik etki alanında yüksek erişilebilirlikle barındırılmasını sağlamak için her bir erişilebilirlik etki alanı en az üç hata etki alanından oluşur.

Bunun sonucunda erişilebilirlik etki alanındaki her bir hata etki alanı, bir ana erişilebilirlik sorunu kategorisi (yazılım hataları, konfigürasyon hataları, operatörlerin yaptığı yanlışlıklar ve değişiklik prosedüründe meydana gelen performans sorunları) için ayrı bir mantıksal veri merkezi olarak hareket eder.

Hata etki alanları ayrıca bazı yerel donanım arızası türlerine karşı koruma sağlar. Hata etki alanlarının nitelikleri, farklı hata etki alanlarına yerleştirilen kaynakların erişilebilirlik etki alanında mümkün olduğunca hiçbir olası tek donanım hatası noktasını paylaşmamasını garantiler. Farklı hata etki alanlarındaki kaynaklar örneğin aynı "raf üstü" ağ anahtarını paylaşmaz çünkü bu anahtarların standart tasarımında yedeklilik yoktur.

Ancak hata etki alanlarının donanım veya fiziksel ortam için koruma sağlama imkanı bu yerel düzeyle sınırlı kalır. Erişilebilirlik etki alanlarının ve bölgelerin aksine hata etki alanları büyük ölçekli fiziksel altyapı yalıtımı sağlamaz. Ender görülen bir doğal afet durumunda veya erişilebilirlik etki alanı çapındaki altyapı hatasında birden çok erişilebilirlik etki alanındaki kaynaklar büyük olasılıkla aynı anda etkilenecektir.

Dahili hizmetlerimiz, hata etki alanlarını müşterilerin kullanması gereken şekilde kullanır. Örneğin Blok Birimler, Nesne Depolama ve Dosya Depolama hizmetleri üç ayrı hata etki alanında veri replikaları depolar. Tüm kontrol düzlemlerinin ve veri düzlemlerinin bütün bileşenleri bu üç hata etki alanında (veya çok sayıda erişilebilirlik etki alanı barındıran bölgelerde birden çok erişilebilirlik etki alanında) barındırılır.

Hizmet Hücreleri

Hizmet hücreleri, bir sistem etkin olarak değiştirilmiyorken bile sorunların etki alanını sınırlamak için kullanılır. Çok sayıda geçici kullanıcılı bulut sistemindeki iş yükü herhangi bir anda çok hızlı bir şekilde değişebileceğinden veya büyük ve dağıtılmış bir sistemde herhangi bir anda karmaşık kısmi hatalar meydana gelebileceğinden bu tür sorunlar ortaya çıkabilir. Bu senaryolar belirgin olmayan, gizli hataları veya ortaya çıkmak üzere olan performans sorunlarını tetikleyebilir.

Bunun yanı sıra hizmet hücreleri, sistemin etkin olarak değiştirildiği bazı nadir ancak zorlu senaryolarda da etki alanını sınırlar. Bunun klasik bir örneği şöyledir: Tek bir hata etki alanına yapılan dağıtım başarılı gibi görünür, hiçbir hata veya performans değişikliği yoktur ancak ikinci veya son hata etki alanı güncellenir güncellenmez sistemdeki (üretim iş yükü olan tam bulut ölçekli sistem) yeni etkileşimler bir performans sorununa yol açar.

Hizmet hücreleri kullanımının Oracle Bulut uygulama programı arabiriminde veya SDK'sında açıkça adlandırılan bir kavram değil, mimari bir desen olduğuna dikkat edin. Bu mimari desen tüm çok sayıda geçici kullanıcılı sistem tarafından kullanılabilir, bulut platformundan özel destek gerektirmez.

Hizmet hücreleri şu şekilde çalışır:

  • Hizmetin tüm anları (örneğin erişilebilirlik etki alanı yerel hizmetleri için belirli bir bölgedeki veya belirli bir erişilebilirlik etki alanındaki anlar) hizmetin yazılım yığınının ayrı dağıtımlarından oluşur. Bu bağımsız dağıtımların her birine hücre adı verilir. Tüm hücreler uygun olduğu kadarıyla kendi altyapısında barındırılır. Hücreler asla ana bilgisayarları veya sanal bilgisayarları paylaşmaz.
  • Bir hizmet tüm erişilebilirlik etki alanında veya bölgede birkaç hücreyle başlayabilir. Hizmet, artan talebi karşılamak üzere ölçeklendirildikçe sorunların etki alanı büyüklüğünü sınırlamayı sürdürmek için daha fazla hücre eklenir. Büyük ve popüler bir hizmette pek çok hücre olabilir. Diğer bir deyişle hücreler, n adet müşteri iş yükünü çoklayıp m adet haline getirerek ayrı barındırma ortamlarına dağıtır ve bağımsız kaynak yalıtımı sağlar. Hücreler, hata etki alanlarında olduğu gibi bir kardinaliteye sahip değildir. (Daha önce bahsedildiği gibi, yeter sayı tabanlı çoğaltma sistemlerinin tek bir erişilebilirlik etki alanında yüksek erişilebilirlikle barındırılmasını sağlamak amacıyla hata etki alanlarının kardinalitesi için en olası seçimlerden biri erişilebilirlik etki alanı başına üç hata etki alanıdır.)
  • Bir müşteri iş yükünün her bir "doğal birimi" belirli bir hücreye atanır. "Doğal birim" ifadesinin tanımı, hizmetin doğasına bağlıdır. Örneğin dahili İş Akışı hizmetimiz (daha sonra açıklanacaktır) için doğal birim "belirli bir kontrol düzlemi için bu erişilebilirlik etki alanındaki veya bölgedeki tüm iş akışları" olabilir.
  • Her bir hücre grubunun önünde minimalist bir yönlendirme katmanı veya hücre uç noktalarını bulmaya yönelik bir uygulama programı arabirimi vardır. Örneğin Akış/Mesajlaşma sistemi, belirli bir konunun geçerli veri düzlemi uç noktasını bulmaya yönelik bir uygulama programı arabirimine sahiptir ve dahili Meta Veri deposunun her hücre için ayrı uç noktaları vardır. Ancak diğer hücre tabanlı hizmetler tek bir veri düzlemi uç noktasına ve paylaşılan yönlendirme katmanına sahiptir. Yönlendirme katmanı, birden çok hücrenin birbiriyle ilişkili olarak hata durumuna geçmesinin olası nedenidir ancak bu hata, katmanın son derece basit, öngörülebilir ve üstün performanslı (pahalı işlemler olmadan) şekilde tutulması ve katmana büyük miktarda yedek kapasite payı, çok yönlü hizmet kalitesi ve kısıtlama mekanizmaları sağlanarak bastırılır.
  • Hizmet sahipleri iş yüklerini ihtiyaca göre bir hücreden diğerine taşıyabilirler. Aşağıda bazı örnek senaryolar bulabilirsiniz:
    • Çok sayıda geçici kullanıcı durumunda ortaya çıkabilen "gürültülü komşu" sorununu önlemek için ağır bir iş yükünü taşıyarak hücredeki diğer kullanıcıların etkilenmemesini sağlamak.
    • Dağıtılmış hizmet reddi saldırısından kaynaklanmış olabilecek aşırı yük veya voltaj düşüşü durumlarını kurtarmak. Bu tür saldırılara karşı savunma amaçlı kota ve kısıtlama mekanizmalarımız vardır ancak bazen belirli bir kullanım senaryosunun (uygulama programı arabirimi, erişim deseni) hizmet için kota veya kısıtlama sisteminin anlayabileceğinden daha ağır olduğu uç durumları meydana gelebilir. Hücreler kısa vadeli azaltma mekanizması sağlar.
    • İlişkili hataların olasılığını ciddi oranda azaltmak için kritik iş yüklerini farklı hücrelere ayırmak. Örneğin kontrol düzlemleri için dahili paylaşılan İş Akışımızda "kritik çekirdek" kontrol düzlemlerinin her biri (örneğin Platform, Hesaplama, Ağ Bağlantısı ve Blok Birimler) farklı hücrelere atanır ve böylece hücrelerin kullanılmadığı veya düzlemlerin aynı hücreye atandığı durumlara kıyasla çok daha düşük hata ilişkisine sahip olur.
      Not: Bu şekilde hücre kullanımı, müşterilerin esnek uygulamalar oluşturmak için dahili hizmet bağımlılıkları kullanma ihtiyacını azaltır. Bağımlılık grafiğinin göz önünde bulundurulması hala iyi bir uygulamadır (dokümanın ilerideki bölümlerinde bu konuya daha fazla değinilecektir) ancak ilişki kesme mekanizması etkin olduğunda buna yönelik ihtiyaç azalır.

Sonuçta her bir hizmet hücresi, tek bir erişilebilirlik etki alanındaki veya bölgedeki bir başka "mantıksal veri merkezi" (mantıksal performans yalıtımı ve hata yalıtımı gruplaması) haline gelir.

Özetlemek gerekirse hizmet hücreleri ve hata etki alanları şu yollarla birbirini destekler:

  • Hata etki alanları, etkin olarak değiştiriliyorken bir sistemi sorunlara karşı korur.
  • Hizmet hücreleri ise etkin olarak değiştiriliyor olup olmamasından bağımsız olarak sistem ciddi olası sorunlarla karşılaştığında bunların etki alanını sınırlar.

Dağıtım gerçekleştirir veya yama uygularken hata etki alanlarının ve hizmet hücrelerinin niteliklerini tek bir stratejide birleştiriyoruz.

Hizmet Mühendisliği Prosedürleri

Bulut sistemlerinde test ve işlem konusunda kusursuzluk, güvenilirlik açısından kritik öneme sahip olduğu için çok sayıda mühendislik prosedürümüz vardır. Önceki bölümde açıklanan kavramlardan yararlanan bazı önemli yordamlar şunlardır:

  • Hizmetleri artımlı olarak, adımlar arasında özenli doğrulamalarla ve beklenmedik bir şey yaşandığında dönüşlü geri alma ile birlikte dağıtıyoruz. Daha net açıklamak gerekirse işlem şu şekilde gerçekleşir:
    • Her erişilebilirlik etki alanında tek seferde bir hizmet hücresi dağıtıyoruz. Hücrede bulunan tüm hata etki alanları tamamlanana kadar her hücrede yalnızca bir hata etki alanına dağıtım yapıyoruz. Daha sonra aynı erişilebilirlik etki alanında bir sonraki hücreye geçiyoruz.
    • Dağıtımın her adımından sonra (her hata etki alanından ve hücreden sonra) değişikliğin beklendiği gibi işlediğini, yani performansı düşürmediğimizi veya dahili ya da harici hatalara yol açmadığımızı doğruluyoruz. Yanlış veya beklenmeyen bir durum oluşursa değişikliği dönüşlü olarak geri alıyoruz. Kalıcı durumu veya şemaları etkileyen değişiklikleri de içeren geri alma prosedürlerinin otomatik testler de dahil olmak üzere hazırlık ve test aşamalarına özel önem gösteriyoruz.
    • Bu nedenle her bölgede değişikliği tek seferde bir erişilebilirlik etki alanına dağıtıyoruz. Bir adlandırılmış alandaki tüm bölgelere, müşterinin birincil ve yıkım onarımı siteleri için kullanıyor olabileceği hiçbir bölge çiftini eşzamanlı olarak değiştirmeyecek şekilde dağıtım yapıyoruz.
  • Hata işleme ve diğer azaltma mekanizmalarının beklendiği gibi çalıştığını ve sorunu daha kötü hale getirmediğini düzenli olarak doğruluyoruz. Bu tür testler olmadan yeniden denemeler, çökme kurtarma algoritmaları ve durum makinesi yeniden konfigüre etme algoritmaları gibi hata işleme mekanizmalarının hatalar, fazla maliyet veya şaşırtıcı etkileşimler sonucu yayılmış performans düşüşüne veya ciddi performans sorunlarına yol açması yaygın görülen bir durumdur.
  • Önceden açıklandığı gibi kalıcı durum ve şema da dahil olmak üzere son bilinen iyi durumdaki yazılım ve konfigürasyona hızla ve güvenle geri alma becerimizi doğruluyoruz.
 
 

Birden çok erişilebilirlik etki alanı barındıran Oracle bölgelerinde tüm kritik hizmetler erişilebilirlik etki alanına dağıtılmış durumda mı?

Evet. Tüm erişilebilirlik etki alanları her bölgede aynı hizmetler kümesini sunar.

 
 

Oracle ve müşterileri kritik hizmetlerin tek bir mantıksal veri merkezine bağlı olmasını nasıl önlüyor?

Tek erişilebilirlik etki alanı barındıran bölgelerde müşteriler, ayrı "mantıksal veri merkezlerinin" çoğu niteliğini elde etmek için hata etki alanlarını (arasında bağlantısız hata modları olan mantıksal gruplar) kullanabilirler. Müşteriler ayrıca yıkım onarımı için birden fazla bölge de kullanabilirler.

Çok sayıda erişilebilirlik etki alanı barındıran bölgelerde müşteriler aynı şekilde hata etki alanlarını kullanabilirler. Müşteriler yüksek düzeyli "mantıksal veri merkezlerinde" (erişilebilirlik etki alanları) tam yüksek erişilebilirlik sağlamak için ayrıca erişilebilirlik etki alanı yerel hizmetleri, erişilebilirlik etki alanları arası adres devri özellikleri (Veri Koruyucu ile DBaaS gibi) ve bölgesel hizmetlerin (Nesne Depolama, Akış) bir birleşimini de kullanabilirler. Son olarak müşteriler yıkım onarımı için birden fazla bölge kullanabilirler.

Yukarıdaki tüm durumlarda müşteriler, yayılmış performans düşüşü gibi en ciddi sorunları bile daha fazla yalıtmak için hizmet hücreleri kavramından yararlanabilirler.

 
 

Oracle, kritik hizmetleri müşteriler için geçici olarak erişilemez hale getirmeden hizmetlerin bakım etkinliklerini nasıl yürütüyor?

Bunu hata etki alanları, hizmet hücreleri ve artımlı dağıtım ile doğrulamaya yönelik operasyonel prosedürlerimiz sayesinde yapıyoruz. Bu dokümanın yukarısındaki ilgili bölüme bakın.

 
 

Sunucusuz platform hizmetleri daha yüksek erişilebilirlik için birden fazla mantıksal veri merkezine mi dağıtılıyor?

Evet. Tüm kategorilerdeki hizmetler esneklik ve sürekli erişilebilirlik için birden fazla mantıksal veri merkezine (bağımsız hata yalıtımı ve performans yalıtımı mantıksal grupları) dağıtılıyor.

 
 

Konfigürasyon öndeğeri esneklik değilse müşterilere birden fazla mantıksal veri merkezi dağıtımı (çok sayıda erişilebilirlik etki alanı veya bölgeler arası konfigürasyon gibi) seçeneği sunuluyor mu?

Bu dokümanın başka bir bölümünde anlatıldığı gibi, tek erişilebilirlik etki alanı barındıran bölgelerde "birden çok mantıksal veri merkezi" mekanizması olarak hata etki alanlarını sunuyoruz.

Çok sayıda erişilebilirlik etki alanı barındıran bölgelerde anuyumlu olarak çoğaltılan veriler için daha da yüksek düzeyde fiziksel dayanıklılık (bölgede bulunan erişilebilirlik etki alanları arasındaki uzaklık nedeniyle ortalama performans-maliyet ile ve ışık hızında) sağlayan hizmetler ve özellikler sunuyoruz.

Bölgeler arasında yakın bağlantı ilişkisi oluşturarak birçok bölgenin aynı anda sorun yaşamasına yol açabileceğinden bölgeler arası otomatik yüksek erişilebilirlik veya hata olduğunda adres devri mekanizmaları sunmuyoruz. Bunun yerine bölgeler arasında çeşitli zamanuyumsuz çoğaltma biçimlerine imkan veriyoruz ve bölgelerde Yıkım Onarımını etkinleştirmek için zamanuyumsuz kopyalama & yedekleme gibi sayısı gitgide artan bir grup özellik sunuyoruz.

 
 

Oracle müşterilerin, çeşitli altyapı ve platform hizmetleri arasındaki dahili bağımlılıklardan kaynaklı ilişkili uygulama hatalarından kaçınmasına nasıl yardımcı oluyor?

Bu karmaşık bir soru ve yanıtın yeterince açık olması için bunu birkaç farklı şekilde ifade edeceğiz:

  • Bir müşteri iki farklı Oracle hizmeti (A ve B hizmetleri) kullanmak ve bu hizmetlerden birinde sorun olduğunda esneklik gösterecek bir uygulama oluşturmak istiyorsa müşterinin, A hizmetinin B hizmetine dahili bağımlılığı olup olmadığını bilmesi gerekiyor mu? Dahili bağımlılıklar ciddi ilişkili hatalara yol açıyor mu? Açıyorsa müşterinin uygulama düzeyinde kendi esneklik mekanizmalarını oluştururken A ve B hizmetlerini başka nasıl kullanabileceğine (veya bu gibi ek durumlar için ayrı bir C hizmeti çekip çekmeyeceğine) karar vermek için bu tür dahili bağımlılıkları bilmesi gerekebilir.
  • Müşteri, ilişkili Oracle hizmetleri hatası durumunda kendini en iyi nasıl savunabilir?

Yanıt iki bölümden oluşuyor.

Mimari İlkeler

İlişkili hizmetler arasında bağlantılı hata olasılığını büyük oranda azaltan mimari ilkeler kullanıyoruz. Bazı durumlarda bu teknik, ilişkili hata olasılığını erişilebilirlik hizmet düzeyi anlaşmasını karşılama açısından görmezden gelinebilecek kadar azaltabilir.

Bu dokümanın öncesinde anlatıldığı gibi, özellikle hizmet hücrelerini kullanıyoruz. Hücreler bu soruna yardımcı olur çünkü A hizmeti, bağımlılıklarından biri olan B hizmetinden ötürü bir sorundan etkilenirse B hizmetindeki sorun çok büyük olasılıkla tek bir hücreyle sınırlı kalacaktır. B hizmetini kullanan diğer yüksek düzey hizmetler ve müşterinin kendi uygulamaları ise büyük olasılıkla sorundan etkilenmemiş diğer hücreleri kullanıyor olacaktır. Bu, hücre sayısına göre değişen olasılıksal bir argümandır. Hücre sayısı ise değişen (artan) gizli bir dahili parametredir, bu nedenle A ve B hizmetlerinin bağımsız hizmet düzeyi anlaşmalarının ötesinde hiçbir ölçü veya garanti verilemez. Ancak pratikte bu, hizmetler arasındaki hataların ilişkisini ciddi oranda azaltabilir.

Paylaşılan dahili hizmetlerimizin bir çoğu (örneğin kontrol düzlemleri için İş Akışı ve Meta Veri hizmetleri ve Akış/Mesajlaşma hizmeti) kendisini kullanan yukarı akış hizmetleri için kesintilerin arasındaki ilişkiyi kaldırmak amacıyla hizmet hücrelerini kullanır.

Bağımlılıklar

Bu kılavuz yüksek düzeydir, düşük düzey uygulama ve hizmet detayları değişebilir ve değişir. Ancak önemli hesaplama, depolama, ağ bağlantısı ve kimlik doğrulama/yetkilendirme boyutları için aşağıdaki bağımlılıkları veriyoruz.

Kontrol düzlemleri için yaygın bağımlılıklar şunlardır:

  1. Kimlik doğrulama ve yetkilendirme için Kimlik/Platform veri düzlemi
  2. Denetim izleme hizmeti
  3. İş akışı, meta veri depolama, günlüğe kaydetme vb. sağlayan dahili hizmetler
  4. Çeşitli yük dengeleyiciler

Tabii ki bazı kontrol düzlemlerinde hizmete özgü bağımlılıklar vardır. Örneğin Hesaplama kontrol düzlemi bir yalın donanım veya sanal makine anı başlatırken şunlara bağımlıdır:

  • Nesne Depolama (belirtilen işletim sistemi imajını almak için)
  • Blok Birimler kontrol düzlemi (önyükleme birimini sağlamak ve bağlamak için)
  • Ağ bağlantısı kontrol düzlemi (VNIC sağlamak ve bağlamak için)

Çekirdek hizmet düzlemleri için genel ilke yüksek erişilebilirlik, hızlı hata bulma süresi ve hızlı kurtarma süresi sağlamak için her bir veri düzleminin özellikle minimum bağımlılığa sahip olacak şekilde tasarlanmasıdır. Bu ilkenin sonuçları şunlardır:

  • Ağ Bağlantısı veri düzlemi bağımsızdır.
  • Blok Birimler veri düzlemi bağımsızdır.
  • Hesaplama yalın donanım ve sanal makine anları, Blok Birimler'e (önyükleme birimleri için) ve Ağ Bağlantısı veri düzlemine bağımlıdır.
  • Nesne Depolama veri düzlemi kimlik doğrulama ve yetkilendirme için Kimlik/Platform veri düzlemine bağımlıdır (endüstri beklentilerinden ötürü). Nesne Depolama veri düzlemi Blok Birimler veya Dosya Depolama hizmetlerine bağımlı değildir.
  • Yedekleme ve geri yükleme işlemlerini destekleyen tüm hizmetler bunun için Nesne Depolama veri düzlemine bağımlıdır.

IaaS veri düzlemleri için genel ilke, döngüsel bağımlılıkları önlemek amacıyla yalnızca çekirdek veya düşük düzey veri düzlemlerine bağımlı olunmasıdır.

  • Veritabanı çok düğümlü Gerçek Uygulama Kümeleri, Ağ Bağlantısı veri düzlemine ve Blok Birimler veri düzlemine bağımlıdır.
  • Kubernetes İçin Kapsayıcı Motoru tabii ki Kubernetes'e, onun geçici bağımlılıklarına (örneğin etcd) ve Ağ Bağlantısı veri düzlemine bağımlıdır.
  • Tüm yedekleme ve geri yükleme desteği Nesne Depolama veri düzlemine bağımlıdır.

1Stanford ve Berkeley üniversitelerinden Armando Fox ve Dave Patterson tarafından yürütülen genel bir araştırma programı

 
×
Bizi şimdi arayın
1-800-633-0738 (Birleşik Devletler)

İletişim
×
Bizi şimdi arayın
1-800-633-0738 (Birleşik Devletler)


Oracle Bulut Tartışma Forumları