Çok kafa karıştıran bir isimlendirme olduğu
için hızlı bir şekilde açıklama gereği duydum. Öncelikle Microsoft’ un Public
Cloud hizmeti olan Azure servislerinin bir kısmını yerleşik veri
merkezlerinizde ve yine size ait ama Microsoft tarafından onaylanmış
(sertifikalandırılmış) donanımlar üzerinde çalıştırmak istiyorsanız Azure Stack
kullanabilirsiniz. Buraya kadar konu aslında çok basit.
Bu konuda aşağıdaki yazıma hızlıca göz
atabilirsiniz.
Peki Azure Stack HCI nedir? Aslında aşağıdaki
mevcut teknolojilerin bir arada kullanılmasına verilen isimdir. Hatta bazı
uzmanlar yeniden isimlendirme, markalaşma olarak bile özetleyebilirler.
Azure Stack alt yapısında olduğu gibi yine
Microsoft tarafından onaylanmış donanımların üzerine Windows Server 2019
temelli yüksek erişilebilir ve en yeni nesil teknolojilerin (Storage Spaces
Direct ve SDN gibi) kullanıldığı sistemlere Azure Stack HCI denmektedir.
Azure Stack için kullanılan teknolojiler
aşağıdaki gibidir;
Hardware from an OEM partner
Windows Server 2019 Datacenter
edition
Windows Admin Center
Azure services (optional)
Temel olarak satın alacağınız donanımlar,
Server 2019 işletim sistemi ve Windows Admin Center’ dan oluşmaktadır. Azure
kullanmanız şart olmayıp sistemi özellikle bulut temelli yedeklemek veya Azure
Site Recovery (DRaaS) gibi felaket senaryoları için kullanabilirsiniz. Burada
tabiki şirketlerin iş ihtiyaçlarına göre aslında Azure File Sync, Azure Monitor,
Azure Update Manager, Cloud Witness gibi pek çok bulutun katma değerli
hizmetlerini VPN ile mevcut HCI alt yapınıza kazandırabilirsiniz.
Temelde Azure Stack HCI için en az iki node
sunucu parkuru gerekmektedir. Her iki sunucu parkurunda da Hyper-V ve storage
katmanı olarak Storage Spaces Direct kullanılmaktadır. Bu sayede bir sunucu
üzerindeki tüm değişiklikler anında diğer sunucu üzerine replike
edilebilmektedir.
Tabiki böyle bir yapı kurmak için öncelikle
aşağıdaki katalog ürünlerinden birini seçmeniz gerekmektedir.
Windows Virtual Desktop özellikle yüksek lisans ve donanım maliyetleri nedeni ile VDI alt yapılarına geçemeyen pek çok müşterimde büyük ilgi uyandırdı. Bu konudaki yazımı tekrar paylaşmak istiyorum.
Tabi durum böyle olunca herkes ürünü bir görmek ve denemek istiyor. Bu konuda Microsoft Mechanics harika bir eğitim serisi hazırlamış. Sakın benim İngilizcem yok diye üzülmeyin video gerçekten çok sade ve anlaşılır. Eğer bu konuda kendisini geliştirmek veya şirket ortamında kullanmak, denemek isteyen var ise aşağıdaki 4 bölümlük eğitim serisini mutlaka izlemeli.
Global bulut oyuncuları öncelikle bizim veri merkezinde çalışan iş yüklerini kendi veri merkezlerinde çalıştırma vaatleri ile hayatımıza girmişti. İlk bakıldığında aslında yerel bir hizmet sağlayıcısından farklı değildi. Tabiki Microsoft gibi, Amazon veya Google, IBM gibi büyük bir marka imajı dışında. Ancak süreç çok hızlı bir şekilde gelişti, öncelikle sunulan platform inanılmaz bir hızda güncellendi. Sadece sunucu açma kapatma noktasında network, firewall, storage yönetmeye kadar geldik. Evet bu inanılmaz bir gelişim gibi dursa da konsept hala IaaS katmanında ilerliyordu. Ancak bunun uzun vadede istenilen dönüşümü sağlamayacağı çok kesindi ve bunun yanında hızla gelişen PaaS ve SaaS platformları ile bulut asıl gücünü göstermeye başladı. Bu gün en basit örnek office 365. Regülasyon kaynaklı dahi olsa platformu terk etmek isteyen bir müşterim sırası ile aşağıdaki aşamalarda tavsiye istiyor;
Mail için ne kurmalı? Ya da bir ISP ye gideriz
ama active sync, room mailbox, MAPI – Outlook deneyimi derken konu uzadı.
Sanmayın bu kadar, peki dedi onedrive ve SharePoint altyapımız ne olacak,
şirkette insanlar inanılmaz alışmış ve yetkilendirme, kırılımlar tanımlanmıştı.
Teams ve Skype’ ı çok aktif kullanıyoruz onu ne yapmalıyız derken iş çığırından
çıktı. Özetle bulutun gerçek gücü aslında sadece bizim veri merkezinde çalışan
iş yüklerini alıp kendilerinin sunmasından öte sunduğu pek çok yeni nesil
teknolojide gizli. Bu yazıya içerisinde de tam bu noktaya dikkat çekmek
istiyorum.
Microsoft 2017 yılında AMD EPYC işlemci temelli sanal makineler sunacağını açıklamıştı. 7 Ağustos itibari ile ise bu geçen sürenin sonucunda gerçekleştirilen iş birliktelilerinin son meyvesini görebiliyoruz. İkinci jenerasyon HB serisi sanal makinelerde (HBv2) AMD EPYC 7002 işlemcileri görebiliyoruz.
Bu alanda gelen müşteri memnuniyeti sonucunda yakın zamanda Dav3 ve Eav3 serisi sanal makinelerde de AMD EPYC 7452 işlemcileri görebileceğiz. Şu anda bu sanal makineler “preview” olarak sunulmakta olup prod ortamları için genel erişime açılması bekleniyor.
Bundan önceki yazılarımızda temel olarak Azure
Stack mimarisinden bahsetmiştik. Hızlıca hatırlatmak gerekir ise Azure Stack, bir
Public Cloud hizmeti olan Microsoft Azure’ un kendi veri merkezinizde ve kendi
donanımlarınız ile çalıştırabileceğiniz sürümü diyebiliriz. Aslen pek çok
alanda Azure ile birebir özellik ve kullanıcı deneyimi sunmak ile beraber temel
bazı farklılıkları da vardır.
Bu yazımda ise özellikle Türkiye de son
dönemde üzerinde durulan servis sağlayıcı modeli;
Malum son günlerde KVKK kaynaklı bilgilerin
nerede saklandığı, işlendiği gibi konularda pek çok BT yöneticisinin kafası
karışmış durumda. Durum böyle olunca da ister istemez alıştıkları teknolojileri
kullanmaya devam etmek istedikleri kadar kanun veya regülasyonlara da uymak
istiyorlar. Veya global pazarda rekabetten geri kalmamak için özellikle
rakiplerin bu tarz teknolojileri kullanırken kendi şirketi içinde uygun bir alternatif
araştırıyorlar. Tam bu noktada Azure Stack çok mantıklı bir alternatif. Peki
Azure Stack için gerekli olan ilk yatırım maliyetini düşünürsek şirketler bu
noktada nasıl bir çıkış yakalayabilir?
Tam bu noktada yerel servis sağlayıcıların
yukarıdaki gibi bir model için çalıştığını görüyoruz. Özellikle donanım
üreticileri ve bir servis sağlayıcının üzerinden alınacak Azure Stack hizmeti,
hem katma değerli hizmetlerini sunacakken hem de verilerin Türkiye merkezli bir
veri merkezinde saklanmasına izin verecektir.
Peki bunu nasıl yapacağız? Azure stack aynı genel
Azure mantığı ile çalıştığı için bir şirket olarak alıp kendi veri merkezinize
kurup kullanabileceğiniz gibi bir servis sağlayıcı Azure Stack alt yapısını
aynı Microsoft gibi birden çok müşteri işi eş zamanlı kullanabilir.
Hatta bu iş o kadar kolay ki aşağıdaki iki
komut ile süreci başlatabiliyoruz;
Import-Module
.\Connect\AzureStack.Connect.psm1
Import-Module
.\Identity\AzureStack.Identity.psm1
Not: Bu işlemler için mutlaka bilgisayarınızda
PowerShell for Azure Stack yüklü olmalıdır.
Daha sonra ise aşağıdaki makalede gösterildiği
gibi süreci ilerletebilirsiniz.
Şirketlerin iş ihtiyaçları her geçen gün değişen ve gelişen teknoloji ile beraber farklılaşıyor. Ülkemizde bu değişim Avrupa ve Amerika kıtasına göre daha uzun sürse bile sonuçta birleştiği nokta genelde aynı veya yakın oluyor. Bu noktada tabiki herkesin bir tecrübesi vardır ancak ben bu konuda kendi tecrübemi paylaşmak istiyorum. Üniversiteden mezun olup ilk profesyonel iş hayatıma başladığım 2002 yılında sunucu sanallaştırma kavramı ülkemiz için yeni bir teknoloji idi. Ancak her dönemde yeniliğe direnç gösteren bir kitle, “sunucu dediğin fiziksel olur, ellemek lazım, görmek lazım” gibi garip tabirler ile bu sanallaştırmaya karşı direnç gösteriyordu. O zamanlar anlattığım gibi bunu kabul etseniz de etmeseniz de bu dönüşüm gerçekleşecek ve öylede oldu. Yıl 2019 ve şu anda bir şirkete gidip sıfır sanallaştırma bulmanız çok mümkün değil. Tabiki çok eski ve küçük işletmelerde belki olsa bile artık sanallaştırma günümüzün endüstri standartı haline gelmiş durumda. Hatta sunucu sanallaştırması ile başlayan sanallaştırma bugün masa üstü, uygulama, oturum gibi pek çok farklı alanda yaygın kullanılıyor. Yine kariyerimin belki de ikinci büyük dönüşümü bulut ile oldu. 2010 yılında Office 365 nedir makalesi yazmışım. Yani 9 yıl sonra bile hala ülkemizde bu teknoloji istenilen seviyeye gelmemiş olsa da bununda sonucu bence şimdiden belli. Tabiki sanallaştırmaya göre bulutun işi biraz daha zor, çünkü regülasyon, kvkk ve benzeri nedenlerden gelişimi ülkemizde yurt dışına göre biraz daha uzun süreceğe benziyor.
Windows Virtual Desktop, masa üstü veya
uygulama sanallaştırma servislerinin bulut üzerinde çalışan halidir. Şirketinizin
ihtiyacı olan sanal masa üstü iş gücünü bulut üzerinden kullanarak ilk yatırım
maliyetlerinizi azaltabilirsiniz. Özellikle uygun lisanslama modellerine
sahipseniz Azure üzerinde sadece sanal makine ve depolama maliyetlerine sanal
masa üstü kullanmanız mümkün.
Windows Virtual Desktop senaryosunda multi-session Windows 10 ve Office 365 için optimize
edilmiş bir işletim sistemi kullanabiliyorsunuz. Eğer Windows 7 işletim sistemi
kullanma ihtiyacınız var ise ücretsiz olarak 2023 yılına kadar uzatılmış
güvenlik güncellemelerinden yararlanabilirsiniz.
Sistemin çalışma yapısı da çok basit aslında. Masa
üstü sanallaştırma yani VDI olarak isterseniz uygulama sanallaştırma yani
Application Virtualization olarak kullanabilirsiniz. Yani Azure üzerinde
çalışan Office gibi uygulamaları herhangi bir windows istemci üzerinden aynı yerel
bilgisayarda çalışıyormuş gibi açabilirsiniz. Aslında gerek masa üstü
sanallaştırma gerekse uygulama sanallaştırma yeni bir teknoloji değil. Burada
Microsoft bu son derece zahmetli alt yapıları size hazır ve ekonomik olarak
sunuyor. Bu gün VDI ortamları için gerekli olan alt
yapı giderlerini ortalama hepimiz biliyoruz. Veya uygulama sanallaştırma için benzer
şekilde RDS Farm kurulumları ve bunların gereksinimleri ortada. Özellikle
belirli iş yükleri veya belirli ekipler için dinamik iş ihtiyaçları için çok
başarılı bir çözüm. Bu aslında bulut için yeni bir şey değil. Örneğin bir
müşterim aktif olarak reklam işlerini dışarıya veriyordu. Bunun en temel sebebi
video render için kullanılan yazılım ve donanım
maliyetlerinin yatırımlarının yüksek olması. Bunun yerine iş oldukça bir firmaya
bunu yaptırıp faturasını alırdı. Ama tabiki kendi imkanlarınız ile
yapabileceğiniz kadar esnek bir çalışma olmuyordu. Özellikle ilgili firmanın
yoğun takvimine denk gelmesi durumunda bazen zaman sorunları yaşanabiliyordu.
Bu programı ve kaynağı Azure üzerinden kiralayabileceklerini ilettim, yani hem
lisans hem de Workstation gibi GPU kullanabilen güçlü makineler ama Azure
üzerinde çalışıyor. Öncelikle tabiki denediler ve çok memnun kaldılar. Artık
benzer işleri kendileri yapıyorlar. İhtiyaç duyduklarında Azure kaynağını
açıyor, bağlanıp çalışıp sonra kapatıyorlar. Bu sayede hem dışa bağımlılık kalmadığı
gibi hem de toplamda ödedikleri para çok daha uygun rakamlara düştü.
Özetle buna benzer bir senaryo olan Windows Virtual
Desktop sayesinde de pek çok şirketin istediği VDI ortamlarına ulaşmak çok daha
ekonomik bir hal alıyor.
Peki ekonomi demişken işin biraz lisans
kısmından bahsedelim;
Kullanacağınız işletim sistemine göre sahip
olmanız gereken lisansları görüyoruz. Eğer Sunucu OS istiyorsak tabiki RDS CAL
ihtiyacımız olacaktır.
Windows Sanal Masaüstü ’nün esnekliği
sayesinde, sanal makine (VM) ve depolama alanı ücretleri hesaplanırken yalnızca
kullanıcılarınızın hizmeti kullandığı zamanlar dikkate alınır. Kullanım
örneklerinize uygun olarak dilediğiniz VM ve depolama seçeneğini tercih
edebilirsiniz. Aşağıdaki örneklerde, dikkate alınması gerekenleri ana
hatlarıyla açıklamak için, sıkça karşılaşılan birkaç senaryonun ayrıntıları
verilmiştir. Ortamınıza uygun dağıtımları seçerken bunlardan
faydalanabilirsiniz.
Doğu ABD bölgesinde çoklu oturum özellikli ve
100 kullanıcılı bir dağıtım için senaryo örnekleri:
Yukarıdaki örnek için 8 saatlik kullanım
yaparsak bir ayda 240 saat kullanırız, bu da ayda sadece 8,9 yaklaşık 9$ tutar.
Buna bir de 20$ disk eklersek toplam 30$’ a bir kullanıcı için sanal makineye
sahip olabilirsiniz.
Microsoft Nisan ayında mevcut Vmware iş
yüklerinizin artık Azure ortamında da sorunsuz çalıştırabileceğinizi duyurmuştu.
Burada nested virtualization değil yani bir sanal
katman üstüne ESX kurulumu değil de doğrudan “native support”
yani fiziksel Azure sunucuları üzerinde çalışan ESX platformlarını
kullanabileceğimizi öğrenmiştik. Azure Vmware Solutions başka bir adı ile AWS
artık yerleşik vmware iş yüklerinizin “Lift
and shift” metodolojisi ile kolay bir şekilde Azure
üzerine taşınmasını sağlayan bir alt yapıdır.
Temel olarak baktığımız zaman yerleşik Vmware
ortamımız ile Azure arasında bir bağlantı kurup daha sonra Azure üzerinde CloudSimple platformu sayesinde Vmware iş yüklerimizi çalıştırabiliyoruz.
Sadece çalıştırmak değil aynı Microsoft Azure sanal makinelerini yönettiğimiz
gibi Azure Portal üzerinden Vmware alt yapısı üzerindeki sanal makineleri yönetebildiğimiz
gibi bu platform için yeni sanal makinede açabiliyoruz. Yani tek değişen
aslında Azure sanallaştırma katmanı yerine Vmware sanallaştırma katmanız
kullanıyor olmamız.
Öncelikle kesintisiz ve kullanıcı deneyimi
yüksek böyle bir servis sunmak için tabiki iyi bir network alt yapısına sahip
olmamız gerekmektedir. Bu noktada öncelikle network katmanına bir göz atalım.
Yukarıdaki şekilde de görebileceğiniz gibi
yerleşik sistemler ile Azure arasında bir network trafiği kuruyor olmamız
gerekiyor. Burada eğer özellikle network katmanında L2 extend işlemi istiyorsak
Azure Express Route önerilmektedir. Eğer Site-To-Site VPN yaparsanız aslında
yapınız benzersiz bir şekilde Azure üzerine genişlemiş olmuyor. Yani daha basit
bir örnek ile açıklamak istiyorum. Yerleşik Vmware ortamınızda çalışan bir
sunucu 192.168.150.12 nolu ip ile çalışırken bunu bir tıklama ile Azure üzerine
gönderdiğinizde aynı ip yi almaz ise bunun bir anlamı olmaz, yani ip
değiştirdiğiniz ancak servis kesintisi olur, oysaki VPN temel mantığında farklı
network havuzlarını bağlamak olduğu için burada hem büyük veriler ile uğraşıyor
olmamızdan kaynaklı hem de network extend yani genişletmek adına doğru yöntem
Azure Express Route kullanmak olacaktır. Tabiki bu ülkemizde ne yazık ki çok ucuz
bir bağlantı yöntemi değildir. Network katmanını bu şekilde kurguladıktan sonrası
aslında son derece basit.
Bundan önce Azure Dedicated host anlattığım
makaleleri incelemişseniz eğer aynı mantık ile bir kurgu yapıyoruz. Yani önce
servis oluşturuyoruz, sonra host sonra ise sanal makine.
Bu konuda ayrı bir makale yazdığım için daha
fazla detaya girmiyorum. Konuyu merak edenler için buraya güzel bir video
bırakıyorum
Makalemin bir önceki bölümünde Azure tarafından sunulan bu yeni hizmetin ne olduğunu ve şirketlerin neden böyle bir iş ihtiyacının olabileceğini detaylandırmıştım. Bu bölümde ise nasıl bir özel sunucu tanımlaması yapacağımızı göstereceğim.
Bir önceki makaleyi incelediyseniz eğer ilk
olarak bir host group açmamız gerektiğiniz biliyoruz.
Azure portal üzerinden yeni bir kaynak ve
buradan “host group” bölümüne geçiyoruz,
Create linkine tıklıyoruz,
İlk olarak Subscription bölümünden faturalama
yapılacak hesabı seçiyoruz.
Daha sonra ben bu fiziksel sunucu için yeni
bir Resource group oluşturuyorum.
Resource group sonrasında ise bu fiziksel
sunucu üzerinde kullanacağım sanal makinelerin kritikliğine göre bir önceki
makalemde anlattığım Availability zone ve Fault domain için Yedeklilik
seçeneklerini tanımlıyorum.
Ardından review +
create linkine tıklıyoruz
Validation geçtikten sonra aşağıdaki gibi bir ekran
karşılayacak bizleri,
Şimdi sıra Dedicated
host oluşturmaya geldi. Bunun için yine “Create a resource” linki üzerinden “Dedicated host” oluşturuyoruz.
Daha sonra create butonuna basarak ilerliyoruz
Yukarıdaki gibi iş ihtiyaçlarınıza göre ilgili
alanları dolduruyoruz. Daha önceden açtığım CozumParkHosted
Resource group’ u seçiyorum. Ardından host için bir isim veriyorum. Daha sonra host
için size belirliyorum. Bu fiziksel host üzerine sanal kuracağımızı unutmayalım,
ona uygun bir size seçebilirsiniz.
Yine bu bölümün altında aşağıdaki gibi iki
seçenek var
Eğer sahip olduğunuz lisanslarınız için
yazılım güvencesi hakkınız var ise yukarıdaki sorulara Yes yanıtı vermeniz
durumunda azure üzerindeki faturanız daha düşük
olarak yansıyacaktır.
Eğer böyle bir hakkınız yok ise bu bölümü
geçebilirsiniz. Daha sonra yine Review + Create
diyerek ilk sunucumuzu oluşturuyoruz.
Son olarak ise bu fiziksel host için sanal
makine oluşturuyoruz.
Yine kaynak üretme bölümünden bir Windows
Server 2016 kuralım
Daha sonra aşağıdaki
gibi temel tanımları yapın
Benzer şekilde yönetici hesabı, şifre ve port
bilgisini tanımlıyoruz.
Aslında buraya kadar normal bir sanal makine açmak’
tan hiçbir farkı yok, buradaki kritik nokta üst bölümden Advanced tabına
geliyoruz
Buradan önce host group sonra host yani biraz
önce oluşturduğumuz fiziksel sunucumuzu seçiyoruz ve sanal makine oluşturma
işlemini tamamlıyoruz. Artık bize özel bir fiziksel sunucu üstüne ilk sanal
makinemizi oluşturmuş olduk.
Umarım faydalı bir makale olmuştur. Bir
sonraki makalemde görüşmek üzere.
Malum bulut üzerinde ortak sunucu ve depolama alt yapıları ile hizmet verilmektedir. Her ne kadar tenant yani kiracı, müşteri bazlı izolasyon olsa dahi bazı durumlarda size ait özel host ihtiyacınız olabilir. Normal şartlarda verinizin yerleşik sistemleriniz üzerinden Azure üzerine taşınması veya yine Azure üzerinde saklanırken güvenliği için şirketinizin veya sizlerin belirleyeceği şifreleme anahtarlarını kullanarak hali hazırda Microsoft’ un sunmuş olduğu güvenlik katmanına ek olarak sizde bir katman ekleyebiliyorsunuz. Ancak bazı şirket organizasyonlarının içinde bulunduğu sektör gereksinimleri verilerin tamamen o şirkete özel bir sunucu üzerinde tutulmasını gerektirebilir. Eğer sizin de böyle bir iş ihtiyacınız var ise Azure kısa bir süre içerisinde size bu hizmeti sunmayı amaçlıyor.
Public Preview sürümü pek çok ülkede kullanıma
hazır olan bu hizmet sayesinde Azure üzerinde tamamen size ayrılmış
donanımlarda hizmet alabileceksiniz.
Azure portal üzerinden yeni bir servis ve
arama bölümüne “dedicated host” yazmanız yeterlidir;
Karşınıza aşağıdaki gibi bir ekran çıkacaktır;
Bu host üzerinde bir veya daha fazla sanal
makine açabilirsiniz. Yine bu fiziksel sunucuyu region bazlı seçebilirsiniz.
Unutmayın ki ürün henüz public preview olduğu
için herhangi bir SLA sunmuyor, bu nedenle prod ortamlarınızı bu hizmet üzerine
konumlandırmamanızı tavsiye ederim. Ama muhtemel bu yazıyı bir ay sonra
okuyanlar için bu uyarı önemli olmayacaktır.
Peki bulutun en büyük nimeti aslında esnek,
alt yapının ne olduğu ile ilgilenmediğimiz, havuz kaynak kullanımı sayesinde donanımlardan
daha iyi verim alarak daha ucuza bilgisayar gücü üretmek veya doğaya daha az
karbon ayak izi bırakmak ise neden bize özel bir sunucu ihtiyacımız olabilir?
Öncelikle fiziksel olarak ayrı bir sunucu yani
izolasyon ihtiyacınız var ise kullanabilirsiniz. Ancak unutmayın ki bu
sunucular diğer sanal makineler ile aynı network ve storage alt yapısını
kullanmaktadır.
İkinci konu ise Azure bakım işlemleri kaynaklı
kesintilerden etkilenmemek. Doğru bir mimari ile deploy edilen azure üzerindeki
sanal makine yapınız normal şartlarda bu tür bakımlardan etkilenmez. Ancak
saniyelerin dahi çok önemli olduğu kritik sistemler için bakım zamanlarını
kendiniz ayarlamak istiyorsanız bu durumda fiziksel ayrı bir sunucu işinizi
görecektir.
Azure hybrid avantajından yararlanmak. Eğer
yerleşik sistemler için satın alınmış Windows Server ve SQL lisanslarınız var
ise bu sunucu üzerinde ek lisans almanıza gerek kalmadan bu ürünleri kullanabilirsiniz.
Tabi Azure karma lisans avantajından yararlanmak için yazılım güvensi hakkınız
olmalıdır (Software Assurance)
Peki birazda kavramları görelim.
Bir host grup oluşturup daha sonra içerisine
fiziksel makine ekleyip en son üstünde sanal makine çalıştırabilirsiniz.
Yüksek erişilebilirlik için kuşkusuz birden
çok fiziksel host ve sanal makineleri bunlara dağıtacak şekilde kurulum
yapmamız gerekmektedir.
Örneğin mevcut sanal makineler için
kullandığımız teknolojileri burada da kullanabiliriz. Örneğin availability
zone.
Availability Zones
Bir veri merkezi içerisinde ayrılmış bölgeleri
ifade eder. Her bir bölgenin elektrik, network, soğutma gibi donanımları
birbirinden ayrılmıştır. Bu sayede basit manası ile bir availability zone’ da
elektrik kesilmesi diğerlerini etkilemez. Her bir host grup bir availability
zone içerisinde oluşturabilir. Bu da yüksek erişilebilirlik için birden çok
host group oluşturmanız gerekli. Host group bir Availability Zones ile
işaretlendiğinde onun içerisinde atanan fiziksel sunucu ve o fiziksel sunucu
üzerinde açılan sanal makineler aynı zone ile işaretlenir.
Benzer şekilde yine yüksek erişilebilirlik
için Fault Domains kullanabiliriz. FD bildiğiniz gibi sunucuları aynı veri
merkezinde ayrı fiziksel kabinlere konulmasını sağlar.
Bir host oluşturur ve onu bir host grup’ a
bağlarken mutlaka fault domain sayısını belirtmemiz gereklidir.
Ya da en iyi yöntem bu iki özelliği aynı anda
kullanmak olacaktır. Bu konuda aşağıdaki link üzerinden güzel bir örnek
deployment şablonuna ulaşabilirsiniz
Peki kendimize özel bir sunucu aldık ve Azure
için sunucu bakım zamanı geldi ne olacak? Eğer özel sunucu kiralama nedenimiz
bu tarz bakımlarda saniye değerinden de olsa kesintilere tahammülümüzün
olmaması ya da daha doğru bir örnek bizim belirleyemediğimiz bir zamanda olması
sizin için sorun ise bu kontrol bizde oluyor. Olası bir bakım periyodu geldiği
zaman bunu 35 gün erteleyebiliyoruz.
Hizmetin fiyatları için aşağıdaki linki
inceleyebilirsiniz
Buradaki temel mantık fiziksel makinenin
fiyatlandırılması olup üzerinde sanal makineler fiyatlandırılmaz. Faturanızda
yine fiziksel makineniz üzerindeki sanal makineleriniz görüşecektir ancak
yanlarında fiyat olarak “sıfır” yazdığınız göreceksiniz.
