Exchange Server kurulumunun yaptığınız işletim
sistemi bölgesel ayarların Türkiye olması kurulum sonrasında mail gönderme
sorununa neden olmaktadır. Bunun en bilinen davranışı OWA için maillerin draft
klasöründe kalması, outlook için ise giden kutusunda kalmasıdır. Kuyruğu
kontrol ettiğinizde ise aşağıdaki gibi bir hata görürsünüz
Bu hataların sebebi Exchange Server kurduğunuz
işletim sisteminin İngilizce olmasına rağmen bölgesel ayarlarını Türkiye
olmasıdır. Bu ayarları aşağıdaki gibi değiştirip transport servisini yeniden
başlatmanız durumunda sorun çözülecektir.
Ş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.
Bir makine eğer domain join ise login olurken domain controller üzerinde çalışan Kerberos Key Distribution Center (KDC) servisinden ticket-granting tickets (TGTs) istemektedir. Bu kerberos ticket güvenlik amacı ile istemci makinenin hesabının domain şifresi ile şifrelenir. Bilgisayar hesapları da aynı kullanıcılar gibi birer password kullanır, fakat kullanıcılardan farkı bunu biz bilemeyiz ve varsayılan olarak 30 günde bir otomatik olarak güncellenir. Eğer bilgisayar hesabına ait bu şifre değişir ve kimlik doğrulama olmaz ise bu ticket da açılamaz.
Güzel bir hafta
diliyorum, muhtemel pek çoğunuz tatil yapıyorsunuzdur, ancak yoğun iş
temposundan henüz bu yıl tatile fırsat bulamayan birisi olarak bu haftaya da
bir bilgilendirme ile başlamak istiyorum.
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.
Bildiğiniz gibi yerleşik sistemler veya Azure
üzerindeki sunucular içine security center üzerinden toplanan logların bir
sonucu olarak pek çok iyileştirme, sıkılaştırma önerileri yapılmaktadır.
29 Temmuz itibari ile özellikle CIS gereksinimleri
konusunda yeni kontrol noktaları eklenmesi sonucunda artık SQL ortamlarınızın
güvenli konusunda çok daha iyi bir öneri, raporlama özelliğine sahip
olacaksınız.
Bu yeni özellikler aşağıdaki gibidir;
Advanced data security should be enabled on
your SQL servers
Vulnerability assessment should be enabled on
your SQL servers
SQL servers should be configured with auditing
retention days greater than 90 days
Email notifications to admins and subscription
owners should be enabled in SQL server advanced data security settings
All advanced threat protection types should be
enabled in SQL server advanced data security settings
SQL server TDE protector should be encrypted
with your own key
Daha fazla bilgi için aşağıdaki linki
inceleyebilirsiniz
