Google Cloud Professionals için Azure

  • Makale

Bu makale, Google Cloud uzmanlarının Microsoft Azure hesaplarının, platformlarının ve hizmetlerinin temellerini anlamasına yardımcı olur. Ayrıca Google Cloud ile Azure platformları arasındaki temel benzerlikleri ve farkları da kapsar. (Google Cloud'un daha önce Google Cloud Platform (GCP) olarak adlandırıldığını unutmayın.)

Şunları öğreneceksiniz:

  • Hesap ve kaynaklar Azure’da nasıl düzenlenir?
  • Kullanılabilir çözümler Azure’da nasıl yapılandırılır?
  • Başlıca Azure hizmetlerinin Google Cloud hizmetlerinden farkı.

Azure ve Google Cloud, zaman içinde özelliklerini bağımsız olarak oluşturarak her birinin önemli uygulama ve tasarım farklılıklarına sahip olması için bu özellikleri geliştirmiştir.

Google Cloud için Azure'a genel bakış

Google Cloud gibi Microsoft Azure da temel bir dizi işlem, depolama, veritabanı ve ağ hizmeti etrafında oluşturulur. Çoğu durumda, iki platformu sunduğu ürün ve hizmetler arasındaki temel bir denklik söz konusudur. Hem Google Cloud hem de Azure, Linux veya Windows konaklarını temel alan yüksek oranda kullanılabilir çözümler oluşturmanıza olanak tanır. Bu nedenle, Linux ve OSS teknolojisini kullanarak geliştirme yapmaya alışkınsanız her iki platform da işinizi görür.

İki platformun özellikleri benzer olmakla beraber, bu özellikleri sağlayan kaynaklar genellikle farklı şekilde düzenlenmiştir. Bir çözümün oluşturulması için gereken hizmetler arasındaki bire bir ilişkiler, her zaman net değildir. Diğer durumlarda, belirli bir hizmet yalnızca bir platformda sunulabilir.

Hesapları ve abonelikleri yönetme

Kaynakların verimli bir şekilde yönetilmesi için Azure’da Yönetim grubu ile abonelikler ve kaynak grupları arasında bir hiyerarşi vardır. Bu sistem, Google Cloud’daki Klasörler ve Proje hiyerarşisine benzer.

Diyagram, kök olarak yönetim gruplarının, ardından aboneliklerin ve ardından yaprak düğüm olarak kaynak gruplarının bulunduğu bir ağaç yapısını gösterir.

Yönetim kapsamının Azure düzeyleri

  • Yönetim grupları: Bu gruplar, birden çok abonelik için erişimi, ilkeyi ve uyumluluğu yönetmenize yardımcı olan kapsayıcılardır. Bir yönetim grubundaki aboneliklerin tümü otomatik olarak yönetim grubuna uygulanmış olan koşulları devralır.
  • Abonelikler: Abonelik, kullanıcı hesaplarını ve bu kullanıcı hesapları tarafından oluşturulan kaynakları mantıksal olarak ilişkilendirir. Her abonelik için oluşturabileceğiniz ve kullanabileceğiniz kaynak miktarında sınırlamalar ve kotalar vardır. Kuruluşlarda kullanıcılar, takımlar veya projeler tarafından oluşturulan kaynakları ve maliyetleri yönetmek için abonelikler kullanılabilir.
  • Kaynak grupları: Kaynak grubu, web uygulamaları, veritabanları ve depolama hesapları gibi Azure kaynaklarının dağıtıldığı ve yönetildiği mantıksal bir kapsayıcıdır.
  • Kaynaklar: Kaynaklar, sanal makineler, depolama alanı veya SQL veritabanları gibi oluşturduğunuz hizmetlerin örnekleridir.

Azure hizmetlerini satın alırken kuruluşunuzun büyüklüğü ve gereksinimlerine bağlı olarak çeşitli fiyatlandırma seçenekleri arasından tercihinizi yapabilirsiniz. Ayrıntılı bilgi edinmek için fiyatlandırmaya genel bakış sayfasına göz atın.

Azure aboneliği, faturalama ve izin yönetiminden sorumlu atanmış bir sahibi bulunan bir grup kaynaktır.

Google Cloud projesi faturalama, kotalar ve sınırlar açısından kavramsal olarak Azure aboneliğine benzer. Ancak işlevsel bir bakış açısından bakıldığında, Google Cloud projesi daha çok Azure'daki bir kaynak grubuna benzer. Bulut kaynaklarının dağıtılacağı mantıksal bir birimdir.

Google Cloud'dan farklı olarak maksimum Azure aboneliği sayısı olmadığını unutmayın. Her Azure aboneliği tek bir Microsoft Entra kiracısına (Google Cloud terimleri ile bir hesap) bağlıdır. Microsoft Entra kiracısı sınırsız sayıda abonelik içerebilirken Google Cloud'un hesap başına varsayılan 30 proje sınırı vardır.

Aboneliklere üç tür yönetici hesabı atanır:

  • Hesap Yöneticisi. Aboneliğin sahibidir ve abonelikte kullanılan kaynaklar için bu hesap faturalandırılır. Hesap yöneticisi yalnızca aboneliğin sahipliğini aktarma yoluyla değiştirilebilir.
  • Hizmet Yöneticisi. Bu hesabın abonelikte kaynak oluşturma ve yönetme hakkı vardır, ama bu hesap faturadan sorumlu değildir. Varsayılan olarak, hizmet yöneticiliği ve hesap yöneticiliği aynı hesaba atanır. Hesap yöneticisi, aboneliğin teknik ve operasyonel yönlerinin yönetimi amacıyla hizmet yöneticisi hesabına farklı bir kullanıcı atayabilir. Abonelik başına yalnızca bir hizmet yöneticisi atanır.
  • Ortak Yönetici. Bir aboneliğe birden fazla ortak yönetici hesabı atanabilir. Ortak yöneticiler, hizmet yöneticisini değiştiremez ancak bunun dışında abonelik kaynakları ve kullanıcıları üzerinde tam denetime sahiptir.

Azure kaynaklarına ayrıntılı erişim yönetimi için, 70'in üzerinde yerleşik rol içeren Azure rol tabanlı erişim denetimini (Azure RBAC) kullanabilirsiniz. Kendi özel rollerinizi de oluşturabilirsiniz.

Abonelik düzeyinin altında, belirli kaynaklara kullanıcı rolleri ve bireysel izinler de atanabilir. Azure'da tüm kullanıcı hesapları bir Microsoft Hesabı veya Kuruluş Hesabı (Microsoft Entra Kimliği ile yönetilen bir hesap) ile ilişkilendirilir.

Aboneliklerin de varsayılan hizmet kotaları ve sınırları vardır. Bu sınırların tam listesi için bkz. Azure aboneliği ve hizmet sınırları, kotaları ve kısıtlamaları. Bu sınırlar, yönetim portalında bir destek isteği göndererek maksimum değere kadar artırılabilir.

Ayrıca bkz.

Kaynak yönetimi

Azure’da "kaynak" terimi, platform içinde oluşturabildiğiniz veya yapılandırabildiğiniz herhangi bir işlem örneği, depolama nesnesi, ağ cihazı veya başka varlığı ifade eder.

Azure kaynaklarının dağıtımı ve yönetimi iki modelden biri kullanılarak yapılır: Azure Resource Manager ya da eski Azure klasik dağıtım modeli. Tüm yeni kaynaklar, Resource Manager modeli kullanılarak oluşturulur.

Kaynak grupları

Azure’da VM'ler, depolama alanı ve sanal ağ cihazları gibi kaynakları düzenleyen “kaynak grupları” adlı varlıklar da bulunur. Her Azure kaynağı her zaman bir kaynak grubuyla ilişkilendirilir. Bir kaynak grubunda oluşturulan kaynak başka bir gruba taşınabilir, ancak aynı anda yalnızca tek bir kaynak grubunda yer alabilir. Daha fazla bilgi için bkz . Azure kaynaklarını kaynak grupları, abonelikler veya bölgeler arasında taşıma. Kaynak grupları, Azure Resource Manager tarafından kullanılan temel gruplardır.

Kaynaklar, etiketler kullanılarak da düzenlenebilir. Etiketler, aboneliğinizin genelindeki kaynakları kaynak grubu üyelikleri fark etmeksizin gruplamanıza olanak tanıyan anahtar-değer çiftleridir.

Yönetim arabirimleri

Azure kaynaklarınızı yönetmeniz için çeşitli yöntemler sunar:

  • Web arabirimi. Azure portalında Azure kaynakları için tam olarak web tabanlı bir yönetim arabirimi sunulur.
  • REST API. Azure Resource Manager REST API'si, Azure portalındaki özelliklerin çoğuna programlı erişim sağlar.
  • Komut Satırı. Azure CLI, Azure kaynaklarını oluşturma ve yönetme özelliğine sahip bir komut satırı arabirimi sağlar. Azure CLI, Windows, Linux ve macOS için kullanılabilir.
  • PowerShell. PowerShell için Azure modülleri, bir betik kullanarak otomatik yönetim görevleri yürütmenize olanak sağlar. PowerShell, Windows, Linux ve macOS için kullanılabilir.
  • Şablonlar. Azure Resource Manager şablonları, JSON şablonu tabanlı kaynak yönetimi özellikleri sağlar.
  • SDK. SDK'lar, kullanıcıların Azure hizmetlerini program aracılığıyla yönetmesine ve bunlarla etkileşim kurmasına olanak tanıyan bir kitaplık koleksiyonudur.

Bu arabirimlerin her birinde kaynak grubu, Azure kaynaklarının oluşturulması, dağıtılması ve değiştirilmesinde temel bir rol oynar.

Buna ek olarak, Hashicorp'un sunduğu Terraform ve Netflix Spinnaker gibi çok sayıda üçüncü taraf yönetim aracından Azure’da da yararlanılabilir.

Ayrıca bkz.

Bölgeler ve Kullanılabilirlik Alanları

Hataların etki kapsamı değişiklik gösterebilir. Hatalı disk gibi bazı donanım hataları tek bir konak makineyi etkileyebilir. Hatalı bir ağ anahtarı, bir ağ rafının tamamını etkileyebilir. Bir veri merkezinde güç kaybı yaşanması gibi veri merkezinin tamamında kesintiye yol açan hatalar daha az yaygındır. Nadir durumlarda, bölgenin tamamı kullanılamaz duruma gelebilir.

Bir uygulamayı dayanıklı yapmanın temel yollarından biri yedeklilikten geçer. Ancak, uygulamayı tasarlarken bu yedekliliği planlamanız gerekir. Ayrıca, gereksinim duyduğunuz yedeklilik düzeyi iş gereksinimlerinize bağlıdır. Her uygulama için bölgesel bir kesintiye karşı koruma sağlayan bölgeler arası yedeklilik gerekmez. Genel olarak yedeklilik ve güvenilirliğe karşılık olarak daha yüksek maliyet ve karmaşıklık arasında bir denge kurulur.

Google Cloud'da bir bölgede iki veya daha fazla Kullanılabilirlik Alanları vardır. Kullanılabilirlik Alanı, coğrafi bölgede fiziksel olarak yalıtılmış bir veri merkezine karşılık gelir. Azure, bir uygulamanın her başarısızlık düzeyinde yedeğinin alınması için, kullanılabilirlik kümeleri, kullanılabilirlik alanları ve eşleştirilmiş bölgeler gibi birçok özelliğe sahiptir.

Aşağıdaki tablo her bir seçeneği özetler.

Kullanılabilirlik Kümesi Kullanılabilirlik Alanı Eşleştirilmiş bölge
Hatanın kapsamı Raf Veri merkezi Bölge
İstek yönlendirme Load Balancer Bölgeler arası Yük Dengeleyici Traffic Manager
Ağ gecikme süresi Çok düşük Düşük Orta-yüksek
Sanal ağ Sanal Ağ Sanal Ağ Bölgeler arası sanal ağ eşleştirme

Kullanılabilirlik kümeleri

Hatalı disk veya ağ anahtarı gibi yerel donanım hatalarına karşı koruma sağlamak için bir kullanılabilirlik kümesinde iki veya daha fazla VM dağıtın. Bir kullanılabilirlik kümesi, ortak bir güç kaynağına ve ağ anahtarına sahip iki veya daha fazla hata etki alanından oluşur. Bir donanım hatasının bir hata etki alanını etkilemesi durumunda ağ trafiğinin başka hata etki alanlarındaki VM’lere yönlendirilebilmesi için bir kullanılabilirlik kümesindeki VM’ler farklı hata etki alanlarına dağıtılır. Kullanılabilirlik Kümeleri hakkında daha fazla bilgi edinmek için bkz. Azure’da Windows sanal makinelerinin kullanılabilirliğini yönetme.

VM örnekleri, kullanılabilirlik kümelerine eklendiğinde kendilerine bir güncelleştirme etki alanı da atanır. Güncelleştirme etki alanı, planlı bakım olaylarının aynı anda gerçekleştirilmesi ayarlanmış bir VM grubudur. VM’lerin birden çok güncelleştirme etki alanına dağıtılması, planlı güncelleştirme ve düzeltme eki uygulama olaylarının herhangi bir zamanda bu VM'lerin yalnızca bir bölümünü etkilemesini sağlar.

Kullanılabilirlik kümeleri örneğin uygulamanızdaki rolüne göre düzenlenerek her rolden bir örneğin çalışır durumda olduğundan emin olunmalıdır. Örneğin üç katmanlı web uygulamasında, ön uç, uygulama ve veri katmanlarına yönelik ayrı kullanılabilirlik kümeleri oluşturun.

Web Örnekleri olan bir web katmanına yönelik kullanılabilirlik kümelerini, Uygulama Örnekleri olan bir uygulama katmanını ve Veritabanı Örnekleri olan bir veri kümesini içeren diyagram.

Kullanılabilirlik kümeleri

Kullanılabilirlik Alanları

Google Cloud gibi Azure bölgelerinde de Kullanılabilirlik alanları olabilir. Kullanılabilirlik Alanı, bir Azure bölgesinin içinde fiziksel olarak ayrılmış bir alandır. Her Kullanılabilirlik Alanı farklı bir güç kaynağı, ağ ve soğutma sistemine sahiptir. VM’lerin farklı kullanılabilirlik alanlarına dağıtılması, bir uygulamanın veri merkezi çapındaki hatalara karşı korunmasına yardımcı olur.

Üç alanın tamamını kapsayan bir alt ağ içeren üç alanın bulunduğu bir Bölgenin olduğu, alanlar arası yedekli bir sanal makine dağıtımını gösteren diyagram.

Azure’da bölge yedekli VM dağıtımı

Daha fazla bilgi için bkz. Kullanılabilirlik alanlarını ve bölgeleri kullanmak için Öneriler.

Eşleştirilmiş bölgeler

Bir uygulamayı bölgesel bir kesintiye karşı korumak için Azure Traffic Manager ile İnternet trafiğini farklı bölgelere dağıtarak uygulamayı birden çok bölgeye dağıtabilirsiniz. Her Azure bölgesi başka bir bölgeyle eşleştirilir. Bu ikisi bir araya gelerek bir bölgesel çift oluşturur. Bölgesel çiftler, Güney Brezilya haricinde vergi ve yasal uygulama mevzuatı uyarınca veri yerleşikliğinin karşılanması için aynı coğrafyada yer alır.

Fiziksel olarak ayrı veri merkezleri olan ancak nispeten yakın coğrafi alanlarda yer alabilen Kullanılabilirlik Alanlarının aksine, eşleştirilmiş bölgelerin arasında genellikle en az 300 mil mesafe vardır. Bu tasarım, geniş ölçekli felaketlerin eşleştirilmiş bölgelerin yalnızca birini etkilemesini garantiler. Komşu çiftlerin veritabanı ve depolama hizmeti verilerinin eşitlenmesi ayarlanabilir. Bu çiftler, platform güncelleştirmelerinin aynı anda çiftteki bölgelerin yalnızca birine dağıtılacağı şekilde yapılandırılmıştır.

Azure coğrafi olarak yedekli depolaması, uygun eşleştirilmiş bölgede otomatik olarak yedeklenir. Diğer tüm kaynaklar için, eşleştirilmiş bölgeleri kullanarak tam yedekli bir çözüm oluşturulması her iki bölgede de çözümünüzün tam bir kopyasının oluşturulması demektir.

Diyagram, Azure’da her birinde Veri Merkezi olan iki Bölgenin bulunduğu bir Bölge Çifti içeren Coğrafyanın olduğu bölge çiftlerini gösterir.

Azure’da Bölge Çiftleri

Ayrıca bkz.

Hizmetler

Hizmetlerin platformlar arasında nasıl eşlendiğine ilişkin bir liste için bkz . Google Cloud'dan Azure hizmetlerine karşılaştırma.

Tüm Azure ürün ve hizmetleri her bölgede kullanılamaz. Ayrıntılı bilgi almak için Bölgelere Göre Ürünler sayfasına başvurun. Tüm Azure ürün ve hizmetlerine ilişkin çalışma süresi garantilerini ve kapalı kalma kredisi ilkelerini Hizmet Düzeyi Sözleşmeleri sayfasında bulabilirsiniz.

Sonraki adımlar