Windows Azure'da SQL Azure Mimarisi

0 dakikada yazıldı

38914 defa okundu

Düzenle

[Aşağıdaki makalenin SDK2.5 ile beraber yeni Azure özelliklerine uygun şekilde güncellenmiş halini burada bulabilirsiniz.]

Bu yazıda SQL Azure'a biraz daha farklı bir bakış açısı ile bakalım istiyorum. SQL Azure ve Windows Azure'un beraber sahneye alındığında eldeki diğer senaryolarla nasıl uyuşabileceğine göz atalım. Sonrasında SQL Azure'un iç mimarisine bir bakış atıp nasıl bir çalışma yapısı olduğunu inceleyelim. Son olarak da ufak bir ipucu ile günü bitirelim ;)

Farklı
yaklaşımlar...Farklı yaklaşımlar...

SQL Azure'un kullanımı noktasında genel olarak üç farklı senaryo düşünebilir. Daha önce bazı etkinliklerde kullandığım yukarıdaki slayta göz atacak olursak, soldan başlayarak ilk senaryomuz tamamen Azure içerisinde var olan bir uygulama yapısı. Uygulamamız bir web sitesi, web role içerisinde yani Azure Datacenter'ında barındırılıyor ve yine aynı yerdeki SQL Azure veritabanını kullanıyor. Bu yapıya "Code Near" yani yakın kod deniyor. Bu yapıda SQL ile veriyi kullanan kodun biribirine süper yakın olması tabi ki performansı ciddi şekilde etkiliyor.

İkinci yapı ise slayt içerisinde tam orada göreceğiniz yapı. Bu yapıda uygulama dediğimiz yazılım uzak bir noktada çalışıyor. Bu Azure DataCenter'ı dışında bir yerlerde çalışan bir sunucu uygulaması olabileceği gibi belki bir masaüstü uygulaması bile olabilir. Uygulama doğrudan Azure ortamındaki SQL Azure'a bağlanarak çalışıyor. Bu yapıya da ilkinin tam tersi olduğu için "Code Far" deniyor. Veriyi kullanan kod ile veritabanının birbirinden en uzak olduğu bu yapıda ciddi latency problemleri ve performans kayıpları olabiliyor.

Üçüncü ve son modelde ise daha hybrid bir senaryo kullanılıyor. Cloud tarafındaki uygulama yine cloud tarafında bulunan ve koda en yakın lokasyonda olan bir veritabanını kullanırken uzak noktada olan bir başka uygulama da aynı şekilde yine kendine yakın bir veritabanı sunucusu kullanıyor. Bu iki veritabanı sunucusu istenirse SQL Azure Data Sync servisi ile senkronize edilebiliyor. Ayrıca tabi ki farklı senaryolar için uzak noktadaki uygulamanın hala doğrudan cloud veritabanına bağlanma şansı da var.

Affinity Groups

Bu üç yapıyı da kullanırken dikkat edilmesi gereken birşey var. İster SQL Azure sunucusu yaratırken ister bir hosted service tanımlarken Azure Yönetim Paneli bize hep servisi hangi bölgeye veya datacenter'a konumlandırmak istediğimizi soruyor. Ama maalesef bu yeterli değil. Azure datacenter'ları malum kocaman arkadaşlar :) koca datacenter içerisinde aynı uygulamanın birer parçası olan web role ile sql'in apayrı uçlarda olmasını istemeyiz. Eğer bu gibi servislerin FC tarafından olabildiğince düşük latency ile birbirlerine ulaşılabilecek şekilde datacenter içerisinde konumlandırılmasını istiyorsanız Affinity Group'lar yaratmalı ve servislerinizi tanımlarken söz konusu Affinity Group'ların içerisine koymalısınız.

Affinity Group
tanımlamak.Affinity Group tanımlamak.

Yukarıdaki ekran görüntüsünde de görebileceğiniz gibi normal bir hosted service yaratırken bölge seçmek yerine direk Affinity Group listesine gidebiliriz. Eğer hiç tanımlanmış Affinity Group yoksa bir bölge seçip orada Affinity Group tanımlayabilirsiniz. Sonra da servislerinizi bu grouplara koymanız gerekecek. Özetle bir anlamda servislerinizi, SQL Azure sunucularınızı aynı datacenter içerisinde bir pakete koymaya çalışıyorsunuz. Bunu anlayan FC'de olabildiğince bu servisler için provision edilecek sanal ve sonrasında da fiziksel sunucuları birbirlerine tabiri caiz ise yakın konumlardan seçecek :)

Arka planda neler
oluyor?Arka planda neler oluyor?

Arka planda neler olduğuna devam edecek olursak :) SQL Azure'da her veritabanı üç kopya olarak tutuluyor. Aslında daha genel de konuşabilirim bu konu ile ilgil, Azure'da her data üç kopya tutuluyor, siz isteyin veya istemeyin fark etmez :) SQL tarafında da durum aynı. İlk veritabanı Single Primary oluyor ve tüm CRUD onun üzerinden ilerliyor. Diğer veritabanların birer replica olarak duruyorlar. Eğer Primary'de herhangi bir sorun olursa replica'lardan biri hemen Primary oluyor ve paralelde de yeni bir replica daha yaratılıyor.

Daha da derinlere
doğru...Daha da derinlere doğru...

Daha da derinlere dalacak olursak :) Genel mimari manzarada en önce tabi ki yine bir TDS Load Balancer var. Load Balancer sonrasında firewall ve içeride de Gateway'ler bulunuyor. Bu Gateway'ler arkadaki bir çok gerçek SQL sunucusunu bize sanal sunucular olarak yansıtıyor. Tüm bunlar olurken en altta da yine FC'nin bu sunucuların sağlığından sorumlu olduğunu unutmamak gerek.

Bize bir SQL sunucusu olarak gözüken sanal SQL Azure sunucusundaki bir veritabanı ile bir diğeri aslında gerçek fiziksel dünyada farklı sunucularda olabiliyorlar. İşte tam da bu nedenle şimdilik cross-db query yok.

Elimdeki DB'yi azure'a nasıl alırım?