Bulut projelerinde bölge seçimi genellikle bir tasarım kararı gibi ele alınır: gecikme, veri ikametgâhı, maliyet ve hizmet kullanılabilirliği tartışılır, bir bölge seçilir ve mimari o bölgenin üzerine kurulur. Bu yaklaşımın sessiz varsayımı şudur: seçilen bölge, ihtiyaç duyulduğunda kaynak açmaya izin verecektir.
Bu varsayım her zaman doğru değil. Azure’da bir bölgeye erişim, aboneliğin türüne, kiracının o bölgedeki geçmişine ve veri merkezinin o andaki fiziksel doluluğuna bağlı olarak kısıtlanabilir. Aşağıda anlatılan vaka, tam olarak bu üç faktörün birbirine karıştığı bir durumu ve teşhis sürecini konu alıyor. Kurum, kiracı ve abonelik bilgileri anonimleştirildi; teknik akış olduğu gibi korundu.
Problemin Tanımı: Tek Abonelikte Bölge Kapalı
Bir CSP aboneliği üzerinden yürütülen projede, West Europe bölgesine yeni kaynak oluşturulmak istendiğinde dağıtım başarısız oldu. İlk bakışta sıradan bir kapasite hatası gibi görünüyordu, ancak birkaç gözlem tabloyu değiştirdi.
Aynı kiracıya bağlı diğer aboneliklerde West Europe bölgesi sorunsuz çalışıyordu; o abonelikler üzerinden aynı bölgeye kaynak açılabiliyordu. Sorunlu abonelik ise başka bölgelerde tamamen normal davranıyordu; North Europe ve Sweden Central üzerinde aynı kaynak tipleri sorunsuz oluşturuluyordu.
Bu iki gözlem birlikte önemli bir şey söylüyordu: sorun ne kiracı genelinde bir engel, ne de bölgenin tamamen kapalı olması. Kısıt, abonelik ile bölge kesişiminde oluşuyordu. Teşhis açısından bu ayrım kritik, çünkü Azure’da benzer görünen hataların kapsamı birbirinden farklı ve her kapsamın çözümü ayrı.
İlk İnceleme: Hata Kodunu Doğru Okumak
Bu tür durumlarda en sık yapılan hata, portal arayüzündeki genel mesajla yetinmek. Portal çoğu zaman sadeleştirilmiş bir metin gösterir; ARM şablonuyla dağıtım yapılıyorsa hata doğrulama aşamasında yakalanır ve dağıtım geçmişine hiç düşmez. Gerçek hata kodu Activity Log içindedir ve teşhisin başlangıç noktası orasıdır.
Dört kodun ayrımı şöyle işliyor. LocationIneligible bir kapasite hatası değil, bir erişim politikasıdır: Microsoft, bir bölgedeki kaynakları mevcut müşterilere önceliklendirmek için o bölgede henüz kaynağı bulunmayan kiracıların erişimini kısıtlayabiliyor. Resmî dokümantasyon bu politikanın hâlihazırda yürürlükte olduğu tek bölge olarak West Europe’u listeliyor ve hata metni açıkça bölgenin yeni müşteri kabul etmediğini söylüyor.
Ancak bu politika kiracı düzeyinde işler. Aynı kiracıdaki başka abonelikler o bölgede çalışıyorsa, karşılaşılan şey bu politika değildir. Anlatılan vakada durum tam olarak buydu ve bu tespit, aramayı abonelik düzeyindeki kısıtlara yönlendirdi: anlık kapasite eksikliği ya da abonelik teklif tipine bağlı SKU kısıtı.
Doğrulama: Kota mı, Kapasite mi?
Teşhisin ikinci aşaması, aboneliğin gerçekten ne gördüğünü komut satırından kontrol etmekti. Portal görünümü yeterli değil, çünkü kota ekranı kapasite hakkında bilgi vermez.
az vm list-skus --location westeurope \\
--size Standard_D4s_v5 --all --output table
az vm list-usage --location westeurope --output tableİlk komut, SKU’nun o bölgede destekleniyor olup olmadığını ve abonelik düzeyinde bir kısıt bulunup bulunmadığını gösterir. Restriction sütununda NotAvailableForSubscription görülüyorsa, sorun kotayla ilgili değildir: o boyut, o aboneliğin teklif tipi için açık değildir. İkinci komut ise mevcut kota kullanımını verir; burada dikkat edilmesi gereken bir ayrıntı var, durdurulmuş ancak serbest bırakılmamış sanal makineler hesap kotasını tüketmeye devam eder.
Bu iki çıktı birlikte okunduğunda ortaya çıkan tablo, yazının en önemli ayrımına dayanıyor.
Kota, aboneliğin ne kadar kaynak talep edebileceğini belirleyen bir üst sınırdır ve talep üzerine artırılabilir. Kapasite ise o anda veri merkezinde fiilen boşta duran donanımdır ve hiçbir talep formuyla yaratılamaz. Kotanın yeterli olması, o kapasitenin abonelik için ayrıldığı anlamına gelmez. Dahası, Azure’un kaynak SKU’ları sorgulayan arayüzü gerçek zamanlı kapasiteyi göstermez; doğrulama anında müsait görünen bir boyut, dağıtım anında reddedilebilir. Dağıtım öncesinde anlık kapasiteyi gösteren bir arayüz bulunmuyor.
Microsoft Destek Süreci Nasıl İşliyor
Abonelik düzeyinde bir kısıt tespit edildiğinde tek yol destek talebi açmak. Talebin doğru kategoride açılması süreci belirgin biçimde hızlandırıyor: bölge erişimi ve SKU kısıtı talepleri Service and subscription limits (quotas) altında açılır. Bölge erişimi özelinde kota tipi olarak doğrudan ilgili bölgeyi seçen bir seçenek bulunuyor.
Sürecin gerçekçi beklentisi şu: bölgesel ve zone bazlı erişim talepleri otomatik onaylanmaz, Azure mühendislik ekibi tarafından elle değerlendirilir. Onay süresi için garantili bir hizmet seviyesi taahhüdü yoktur. Sıradan bir kota artışı dakikalar içinde sonuçlanabilirken, bölge erişimi veya teklif tipi kısıtı talepleri günlere yayılabilir.
Talebin kabul edilme olasılığını artıran şey, gerekçenin somutluğu. Dokümantasyon iki meşru gerekçe tanımlıyor: kiracıya bağlı aboneliklerden en az birinin o bölgede halihazırda kaynağa sahip olması, ya da ülkeye özgü veri ikametgâhı zorunluluğu bulunması. Bu ikisinden biri yoksa önerilen yol alternatif bölge seçmek.
Talep açarken baştan paylaşılması gereken bilgiler süreci kısaltıyor: abonelik kimliği ve teklif tipi, hedef bölge, tam kaynak tipi ve SKU adı, Activity Log’dan alınan ham hata kodu ve zaman damgası, denenen alternatif bölge ve SKU’ların sonuçları, ve iş gerekçesi. Bu bilgiler olmadan açılan talepler, ilk yanıtta aynı bilgileri istediği için en az bir tur kaybettiriyor.
Teknik Çıkarımlar: Kısıtlar Neden Oluşuyor
Bölge erişim kısıtlarının arkasında tek bir neden yok; birbirinden bağımsız üç mekanizma aynı kullanıcı deneyimini üretiyor.
Birincisi bölge doluluğu. Popüler bölgelerde belirli donanım aileleri dönemsel olarak tükeniyor ve yeni kapasite eklenene kadar dağıtımlar reddediliyor. Bu durum gün içinde dalgalanır; başka müşteriler kaynak serbest bıraktıkça kapasite geri gelebilir.
İkincisi abonelik teklif tipine göre önceliklendirme. Kapasite daraldığında kısıtlar tüm aboneliklere eşit uygulanmıyor. Deneme, öğrenci ve geliştirici abonelikleri en çok kısıtlanan grup; kurumsal sözleşmeler ise en az kısıtlanan grup. CSP ve kullandıkça öde abonelikleri bu skalanın ortasında yer alıyor ve daralma dönemlerinde kurumsal sözleşmelerden önce etkilenebiliyor.
Üçüncüsü yeni kiracı kısıtı, yani yukarıda anlatılan erişim politikası. Bu üçü aynı anda geçerli olabildiği için, tek bir hata mesajına bakarak hangisinin devrede olduğunu anlamak mümkün değil; kapsamı daraltan testler yapmak gerekiyor.
CSP iş ortakları için ek bir pratik sonuç var: kapasite rezervasyonu araçları her abonelik tipinde kullanılamıyor ve yalnızca altyapı hizmetlerini kapsıyor. Platform hizmetlerinde benzer bir garanti mekanizması bulunmuyor.
Kapasite Garantisi: Hangi Araç Ne Sağlar
Bu noktada sık karşılaşılan bir yanılgıyı netleştirmek gerekiyor. Rezervasyon satın almak kapasite garantisi sağlamaz.
| Araç | Kapasite garantisi sağlar mı? |
|---|---|
| On-Demand Capacity Reservation | Evet. Donanımı önceden tutar; kota gerektirir, belirli serilerle sınırlıdır. |
| Reserved VM Instance | Hayır. Yalnızca fatura indirimidir, kapasiteyle ilgisi yoktur. |
| Kota artışı | Hayır. Üst sınırı yükseltir, donanım tahsis etmez. |
| Availability Zone seçimi | Hayır. Kapasite zone bazında ayrı değerlendirilir, kısıtı artırabilir. |
| Spot sanal makineler | Hayır. Ayrı bir kapasite havuzundan beslenir. |
Tablonun özeti şu: üretim açısından kritik bir iş yükü için gerçek bir kapasite taahhüdü isteniyorsa, tek yol talep üzerine kapasite rezervasyonudur. Diğer araçlar maliyet veya esneklik sağlar, kapasite değil.
En İyi Uygulamalar: Bölge Seçimini Doğrulamak
Bu vakadan çıkan en pratik sonuç, bölge seçiminin bir varsayım değil bir doğrulama adımı olması gerektiği. Uygulanabilir birkaç alışkanlık:
- Projeye başlarken hedef bölgede küçük bir kaynak açın. Mimari tamamlanmadan, hedef abonelikle hedef bölgede en ucuz kaynağı oluşturup silmek, erişimi dakikalar içinde doğrular. Bu testi yapmanın maliyeti ihmal edilebilir; yapmamanın maliyeti projenin ortasında ortaya çıkan bir engeldir.
- Doğrulamayı doğru abonelikle yapın. Kısıtlar abonelik bazlı olabildiği için, yönetim aboneliğinde yapılan test hedef abonelik hakkında bilgi vermez.
- Alternatif bölgeyi baştan belirleyin. Veri ikametgâhı kısıtı yoksa, ikinci bir bölge seçeneğini mimari kararla birlikte kayda geçirin. Avrupa iş yükleri için Sweden Central yaygın bir alternatif.
- Kritik iş yüklerinde kapasiteyi önceden tutun. Öngörülebilir ve kesintiye tahammülü olmayan yükler için kapasite rezervasyonunu devreye alın.
- Aboneliği erken kapatmayın. Bir bölgede kazanılmış erişim hakları aboneliğe bağlıdır; iş yükü sonlandırılsa bile aboneliği açık tutmak, aynı destek sürecini tekrar yaşamayı önler.
- Hata kodlarını kaydedin. Activity Log kaydı olmadan açılan destek talepleri, kanıt toplanana kadar ilerlemez.
Sonuç
Bulut ortamlarında karşılaşılan engellerin hepsi yapılandırma kaynaklı değil. Doğru yazılmış bir şablon, yeterli yetki ve uygun kota, tek başına bir kaynağın oluşacağını garanti etmiyor. Bölgesel kapasite durumu ve abonelik politikaları da en az mimari kadar belirleyici olabiliyor ve bunların ikisi de proje ekibinin kontrolü dışında.
Buna rağmen süreç yönetilebilir. Hata kodunun doğru okunması, kapsamın kiracı mı abonelik mi olduğunun testlerle daraltılması, kota ile kapasitenin birbirine karıştırılmaması ve destek talebinin doğru kategoride, gerekçeli biçimde açılması, çözüm süresini belirgin ölçüde kısaltıyor. Bu vakada engel aşıldı; aşılmasını sağlayan şey ise ek bir yetki ya da farklı bir yapılandırma değil, sorunun nerede olmadığını sistematik biçimde göstermek oldu.
Çıkarılan Dersler
- Bölge erişimi bir varsayım değildir. Mimari kararı vermeden önce hedef abonelikle hedef bölgede doğrulama yapın.
- Kota kapasite değildir. Kota artışı kâğıt üzerindeki sınırı yükseltir, veri merkezine donanım eklemez.
- Kapsamı testle daraltın. Aynı kiracıdaki başka abonelik çalışıyorsa sorun kiracı politikası değildir; aynı abonelik başka bölgede çalışıyorsa sorun yetki değildir.
- Portal mesajı yeterli değildir. Teşhis Activity Log’daki ham hata kodundan başlar.
- Rezervasyon indirimi kapasite taahhüdü değildir. Gerçek garanti yalnızca kapasite rezervasyonuyla gelir.
- Destek talebini gerekçeyle açın. Bölge erişimi talepleri elle değerlendirilir ve onay süresi taahhüt edilmez; eksik bilgi en az bir tur kaybettirir.
Kaynaklar
- Resolve location ineligible errors — Bölge erişim politikasının resmî tanımı, hangi bölgede yürürlükte olduğu ve düzeltme talebinin hangi kategoriden açılacağı.
- Azure subscription and service limits, quotas, and constraints — Abonelik ve hizmet limitlerinin kapsamlı referansı; kota konuşurken başvurulacak kaynak.
- Troubleshoot allocation failures — Tahsis hatalarının nedenleri ve kısıtları gevşeterek çözüm yolları.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
