AZURE SANAL MAKİNELERİNİN 7 DERİN NOKTASI – Part 2

Sanal Ağ (Virtual Network)

Virtual Networks (Sanal Ağlar)

Servislerinizin güvenliğin ve izolasyonun katmanını sağlamak için Azure içerisinde sanal ağlar (VNet) kullanılabilir. Herhangi bir Virtual Network (VNet) yapılandırılması olmadığı zaman Service Management(Eski Portal) Deployment modelinde yaratılan sanal makinelere Azure üzerinden bir ip adresi atamasını Cloud Service gerçekleşecektir. Ancak siz Virtual Network ( Sanal Ağ) yapılandırarak dışarıdan gelen servislerin ulaşmasına izin verebilirsiniz. Varsayılan olarak, Azure Datacenter dışındaki hizmetler Virtual Network içerisinde bulunan hizmetlere bağlanmak isterse Site to Site VPN veya Point to Site VPN gibi yöntemler tercih edilir. Herhangi bir Virtual Network(Sanal Ağ) yapınız olmadan VPN yöntemlerini kullanamazsınız. (Şirketiniz ile Azure Datacenter aynı network içerisindeymiş gibi)

  • Aynı sanal ağın içindeki tüm trafik varsayılan olarak izin verilmiştir ancak Azure sanal makineler veya subnet arasında ACLs’in (Erişim Listeleri) yapılandırılmasına izin verecek bir güvenlik katmanı sağlar.
  • Aynı Azure Datacenter içinde olsalar bile iki sanal ağ doğrudan iletişim içerisinde olamaz. Bir sanal ağdan sanal ağa ileti gönderilebilmesi için bağlantının yapılandırılması gereklidir.(VNet to VNet VPN Kullanmak )
  • VLAN sanal ağlar tarafından ne desteklenmiştir ne de anlaşılmıştır, aslında Azure sanal ağlar 3 ağa kiracı perspektifi için katman görevi görüyor.
  • Sadece tcp,udp, ve icmp protokolleri Azure sanal ağları içinde desteklenir.
  • Sanal ağlar diğer ofisleriniz ile aynı network içerisindeymişsiniz gibi bağlantı yapmanızı destekler. ( Site to Site VPN ) Bir sanal makineye ulaşmak için on-premises ağına bağlanmak için uygun durumda olacaksınız.

Subnets (Alt Ağlar)

Bir sanal ağ oluştururken aşağıdaki bilgiler verilmelidir.

  • Location [Zorunlu] : Azure Datacenter bölgesinde Virtual Network(sanal ağ) oluşturulacak.
  • DNS Server [Opsiyonel]: Azure sizin Sanal Makinelerinize IP adreslerini atamaktan sorumlu olacak. (Tabi ki sizin vermiş olduğunuz bir IP adresi havuzundan). Dolayısıyla bunu Virtual Network(sanal ağ) detayları için yapılandırılacaktı. Eğer herhangi bir DNS sunucusu belirtmez iseniz Azure kendi DNS Sunucu adreslerini dağıtacaktır.
  • Address Space [Zorunlu]: Her oluşturulan sanal ağ, en az bir ağ adres alanı ile yapılandırılması gerekir.
  • Subnets [Zorunlu]: Adres alanı aralığı Azure tarafından doğrudan kullanılamaz. En az bir alt ağ adres alanı tanımlanmalıdır. Birkaç alt ağa adres alanına bölmek tercih edilebilir. Bunu tercih etmenizin diğer bir sebebi ise firmaların Azure üzerinde DMZ network yapısına ihtiyaç duymalarıdır.Bu yöntem ile alt ağlar arasında Access List ( Erişim Listeleri yazarak) DMZ Network oluşturabilirsiniz.

Notlar : Azure Virtual Network ( Sanal Ağlar) public ve private olarak IP aralıkları (CIDR gösterim) destekler. CIDR nedir dediğiniz duyar gibiyim, hemen açıklayalım. CIDR (Classless Inter-Domain Routing), IP adreslerinin daha etkin kullanımını sağlayarak IPv4 adreslerinin tükenmesini yavaşlatmayı ve İnternet üzerindeki yönlendiricilerin kullandığı yönlendirme tablolarının aşırı kalabalıklaşmasını önlemeyi amaçlamaktadır.

Depolama (Azure Storage)

Azure Storage IaaS hizmetleri içerisinde önem verdiğimiz diğer noktalardan biridir. Müşterilerimize giderken en çok önem verdiğimiz konuların başında yerel veri merkezlerimizdeki en büyük maliyet kalemi depolama çözümleri iken Microsoft Azure bulut çözümü içerisindeki en ucuz kalemlerin başında depolama gelmektedir. Aynı zamanda bulut teknolojisinin en önemli avantajlarından birisi olan Pay As You Go ( “Kullandıkça Öde” ) yöntemi depolama çözümleri için de geçerlidir. Eğer dilenirse şirketler “CAPEX VE OPEX” yöntemleriyle inceleme yaparak maliyet/bütçe hesaplamaları sonucunda genel bir ilk yatırım yapmak yerine yalnızca ilgili depolama alanının kullanıldığı kadarı ödenir ve esnek bir biçimde aşağı veya yukarı bu değerler değiştirilebilir. Azurere Storage içerisinde barındırılabilinirken aynı zamanda big data senaryolarını destekleyecek bilimsel, finansal analiz, medya uygulamaları gibi gereksinimleri de rahatlıkla karşılayabilir. İçerisinde terabyte’larca veri rahatlıkla barındırılabilir ve işlenebilir. Azure Storage kendi içerisinde servislere ayrılmaktadır. Bunların Virtual Machine (Sanal Makine) ile ilgili olan kısımlarını tanıyalım.

Blob Storage

Azure Blob Storage genellikle yapılandırılmamış verileri barındıran ve HTTP/HTTPS protokolü üzerinden erişim imkanı veren bir hizmettir. Büyük miktarda yapısal olmayan verileri tutmak için tasarlanmış bir hizmettir.

  • Streaming için kullanılan Video ve Ses dosyalarını
  • Text Dosyaları, Resim, text, binary, veritabanı yedekleri, loglar vs.
  • Güvenli yedekleme ve felaket kurtarma gerçekleştirme için ( Azure Recovery Services & Backup Vault )

Yukarıda listelenen dosya türleri için gibi birçok dosya türü birçok amaç için ‘Blob Storage’de depolanabilmektedir. Ancak bir Storage Account toplamda en fazla 500 TB olabilir. Blob Storage kendi için iki farklı bölüme ayrılmaktadır.

  • Block blob Storage : Belgeler, videolar, resimler, yedekleme ve diğer yapılandırılmamış metin veya binary veri depolamak için kullanılır.
  • Page Blob Storage: Random olarak Read(okuma) ve write(yazma) işlemleri için optimize edilmiş, sanal makinelerinizin VHD formatları için idealdir. Page Blog Storage sanal makine depolama için kullanılır.

Page Blob Storage yaygın olarak işletim sistemi diskleri ve veri diskleri dahil olmak üzere Azure sanal makine dosyalarını depolamak için kullanılır. Bir sanal makine provisioning edilmeye başlandığı zaman karşımıza iki tür Storage modeli çıkmaktadır. Bunlar Standart Storage ve Premium Storage olarak gözükmektedir. Bu iki modelin birbirlerinden farkı performans üzerinedir.

  • Bir Azure Subscription içerisinde oluşturulacak Storage Account ( Depolama Hesabı ) default limit 100 olarak belirlenmiştir. Dilenirse, Microsoft tarafına case açarak bu limit aşılabilir.
  • Storage Account kendi içerisinde Redundancy sağlayabilmesi için farklı replikasyon model olarak ayrılmaktadır. 4 yöntem olarak bizlere bu seçenekleri sunan Azure’ın en temel modeli olan LRS’i hızlıca açalım. Locally Redundant Storage (LRS) replikasyon yönteminin size sağladığı temel fayda storage hesabınız içerisinde tutulan verinin 3 farklı kopyasının aynı bölgedeki veri merkezinde tutulmasıdır. Yani hesabınızı oluşturduğunuz bölgeye göre oluşturulan tüm verilerin 3 farklı kopyası yine aynı meri merkezi içerisinde tutulacaktır. Bu repikasyon modelleri dışındakileri anlamak için Geo-Redundant Storage (GRS), Read-Access Geo-Redundant Storage (RA-GRS), Zone-Redundant Storage (ZRS) bu link sizlere yol gösterecektir.
  • Standart Storage : Depolama performansı IOPS değeri ile sınırlıdır. Disk (VHD) başına maksimum IOPS standart tier için 500 IOPS disk başına, Basic Tier sanal makineler için ise 300 IOPS disk başına ve el edilecek maksimum verimlilik saniyede 60 MB olarak gösterilir. Tabii ki daha yüksek IOPS ve verimlilik diski toplanmasıyla yani (stripping) kullanılarak elde edilebilir. Bu şekilde seçilen yöntem IOPS ve Azure depolama için verimi bizlere açıklar. Sanal makinelere göre ulaşabilecek IOPS değerlerine bu link sizlere yol gösterecektir.
  • Premium Storage : Premium gibi bir hizmetle depolama hizmetinde üst seviye bir hizmet vermek isteyen Microsoft, son teknoloji SSD (Solid State Drives) sunmaktadır. Sanal makineler için varsayılanda kullanılan HDD (Hard Disk Drives) performansının yetersiz olduğu durumlarda Premium hesap ile birlikte gelen SSD disklere sahip sanal makineler kullanılabilir. Yüksek performanslı diskler ile beraber Azure Sanal makineleri kullanabilirsiniz. DS ve GS Serisi Sanal Makineler Premium Storage desteklemektedir. Premium Storage ile uygulamalar VM başına 64 TB kapasite ve 80000 IOPS, VM başına okuma işlemleri 2000 Mb Seviyesindedir. Premium Storage Exchange Server ,SQL Server ,SAP vb veritabanı üzerinde çalışan uygulamalarda kullanılması önerilmektedir.

File Storage

 Azure File Storage, On-Premises veya Cloud üzerinde çalışan uygulamalar arasında paylaşılan bir depolama alanı sunulabilmesi için tasarlanmıştır. Örneğin konfigürasyon dosyalarını, logları depolamak için bu hizmeti tercih etmek isteyebilirsiniz. İletişim için standart “Server Message Block (SMB 2.1)” protokolü kullanılmaktadır. Azure üzerindeki uygulamalar File I/O API’lar yardımıyla bu paylaşıma erişebilirler. Dolayısıyla lokalde dosya paylaşımı gerektiren bir uygulamanız ve bu paylaşımın yüksek erişebilir olmasını gerektiren bir durum varsa kodlarda çok fazla değişiklik yapmadan bu uygulamayı buluta taşıyabilirsiniz. Buna en temel örnek Cluster yapısında “Witness Server / quorum ” olarak belirtmiş olduğumuz paylaşımları gösterebiliriz. Artık Cluster organizasyonunda Azure File Storage servisini gösterebilir durumdayız. Aklınıza bu hizmet On-Premises kullanılan geleneksel file server paylaşımları \\serveradı\paylasimadi” olarak gelebilir.