Category: Infrastructure

Ways for Migrating Azure VM’s to ARM (v2) from ASM (v1)- Part 2

Seçenek 3 – Azure Site Recovery

Öncelikle bilmemiz gereken bir durum var. Bu hizmet Service Management dağıtım modelinden Resource Manager dağıtım modeline geçiş için tasarlanmamıştır. Azure Site Recovery hizmetini kapsamlı bir şekilde blog şu yazımda açıklamıştım. Azure Site Recovery, felaket kurtarma amaçlı şirket içerisinde çalışan workload sunucularının seçtiğiniz Azure Datacenter içerisine replike olmasını sağlar. Felaket anında sunucular hizmet vermeye devam eder. Sanallaştırma platformu Hyper-V,Vmware ve Physical sunucularınızı replike etme yeteneğine sahiptir.



Ways for Migrating Azure VMs from ASM (v1) to ARM (v2)- Part 1

Son zamanlarda hakkında pek çok soru aldığım bir konudan bahsetmek istiyorum. Azure bizlere Virtual Machine hizmetini iki farklı şekilde oluşturmamıza olanak sağlıyor. Bu farklı türlerdeki sanal sunucular Microsoft Azure içerisinde çalıştığı platform farklılıklarından kaynaklanmaktadır. Yazıya devam etmeden önce bu iki farklı terminolojinin ne anlama geldiğini kısaca açıklamanın faydalı olacağını düşünüyorum.



Azure Subscription Environment Report – v1.0

Kendi sorularımın cevaplarıyla harmanladığım, danışmanlık hizmeti verdiğim müşterilerimin çoğunda ihtiyaç duyduğum scripti tanıtmak istiyorum. Şimdilik, geliştirdiğim Powershell Script sadece Azure Service Manager ( Classic deployment) modelinde bulunan kaynaklarınızı HTML olarak raporlamanızı sağlıyor.

030816_2122_AzureSubscr1.png



AZURE SANAL MAKİNELERİNİN 7 DERİN NOKTASI – Part 0:Giriş

Bu yazı Microsoft Azure laaS hizmeti olan ( Sanal Makineler Servisi ) ile başlangıçtan beri dahil olmamış kesime tanıtmak, bunun nasıl çalıştığını hızlıca anlamak isteyenlere ve ikna edilebilirse başlatmaya hatta kullanmayı düşündürmek üzere yazılmıştır. Bu yazıda, Microsoft Azure’ın içerisindeki laaS (Infrastructure as a Service) özellikleriyle ilgili çok şey detaylandırmayacağım, çünkü onlardan yüzlercesine sahip olunan kısımlar var ve Azure temellerini konu alan, tarif eden pek çok kitap ve uzun makaleler var.

030316_2243_AZURESANALM1.gif 



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

Dizayn Husuları (Design Model)

Azure laaS VM (Infrastructure as a Service ) ve organizasyonların kendi alt yapıları için özel sanal makineler kullanmayı planlarken bu bölümde, bazı tasarım konuları ve öneriler anlatacağız. Tasarım çok önemlidir. Hatalı tasarım performans, olumsuz bir bakış ve hatta hatalı maliyet dezavantajları ortaya çıkaracaktır. Azure içerisinde yaratılan sanal makinelerin üç durumu vardır. Bunlar sırasıyla aşağıdaki gibidir.

Virtual Machines ( Sanal Makineler)

  • Running ( Çalışır Durumda ) bu durumda olduğunda Microsoft bizlere Tüm sanal makine kaynakları fatura edilir -> Virtual Machine, Virtual Network ve Storage Account
  • Stopped (Tahsis Edilmiş): Sanal makine işletim sistemi (makine işletim sistemi içinden durdurulur ise) ile durdurulduğunda Bu -> Tüm sanal makine kaynaklar fatura edilir: Virtual Machine, Virtual Network ve Storage Account
  • Stopped (Ayrılmamış) : Sanal makine Azure portal üzerinden kapatma düğmesine veya Azure PowerShell / API kullanarak durdurulduğunda bu -> Virtual Machine ( Sanal Makine) tarafından kullanılan sadece (Storage Account)depolama faturalandırılmış olacaktır.


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

Fiyatlandırma (Pricing)

Bu bölüm Azure içerisindeki laaS (Infrastructure as a Service) bileşenlerinin basit olarak fiyatlandırmasını tarif eder. Azure platformu dizayn ederken fiyatlandırma çok fazla önem taşır. Dizaynınız içerisinde dahil edilen tüm bileşenlerin farkında olmalısınız,böylece oldukça yakın bir şekilde platformun ücretini kestirebilirsiniz. Fiyat hesaplanması için Azure Pricing sayfasını veya Microsoft resmi olarak yayınladığı ve devamlı güncel tutmuş olduğu “Azure Cost Estimator Tool” adında başarılı bulduğum bir araç var. Bu aracın yetenekleri oldukça fazla. Sanallaştırma platformuzu belirtip anlık bir şekilde çalışan workload yapınıza fiyat hesaplamasını gerçekleştirebiliyor. Tabi şunu söylemekte fayda var, hesaplanan fiyatın tutarlılığı yok. Çünkü Azure tarafında, esnek davranmak tamamen sizin elinizdedir.

Fiyatı Hesaplamak

  • Her sanal makine tipine göre bir fiyat biçilir. Fiyat kaynakları hesaplamak içindir. (Depolama ve sanal ağ dahil değil.) ve 3 maddeye göre hesaplanır.(Tier,Seriler,Büyüklük)
  • Azure, Virtual Machine hizmetini sunarken maliyet hesaplaması gizli bir sır barındırıyor. Maliyet kullanıcılara stabil olarak değil, kullandıkları kadar yansıyor. Tüketim dakika başına hesaplanır. Eğer Sanal makineyi 1 saatliğine kullanırsanız, 60 dakika için ücretlendirileceksiniz. Ancak 30 saniye kullanırsanız, 1 dakikadan ücretlendirileceksiniz. Eğer sanal makinelerinizin iş saatleri dışında çalışmamasını ve kestirmeden nirvana erişmek istiyorsanız, Azure Automation hizmetini incelemenizi tavsiye ederim. Blog üzerinde bu sır ile ilgili güzel bir maliyet avantajı hesaplaması yapmıştım. Azure Automation Serisi : http://hasangural.com/azure-automation-part-0giris/



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.



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

Tanıtım (Introduction)

Azure Sanal Makineleri Azure’un laaS (Infrastructure as a Service) kapasitelerinin merkez özelliklerinden biridir. Azure Sanal Makineleri, bir Microsoft Azure datacenter içerisindeki Windows Server veya Linux Sanal Makineleri’nin açılımını destekler. Sanal Makineleri’nin yapılandırılmasındaki toplam kontrol sizdedir. Tüm sunuculardaki yazılım yüklemesinden, yapılandırılmadan, bakımdan ve işletim sistemi yamalarından sorumlu olan sizsinizdir. Tüm kaynaklar Microsoft veri merkezleri içinde çalışır, onlara tek bağlantı da şüphesiz ki ağ olacaktır. Bunu şöyle düşünün, şirketinizden başka bir lokasyonda veya bölgede bir veri merkezine sahipsiniz. Tüm workloadları orada yaratıyorsunuz ve onlara uzaktan ulaşabiliyorsunuz.

Tek farkı ise şu:

  • Veri merkezi Microsoft’a ait oluyor.
  • Bütün altında yatan yönetim, güncellemeler, bakımlar Microsoft’un sorumluluğu oluyor.( Donanım,Ağ,Soğutma,Güç…)
  • Fiziksel güvenlik Microsoft’un sorumluluğunun altında oluyor.

Sonuç ise, Microsoft sizlere bir özellik sunuyor. ( Bir servis ) Bu sizi sanal makine yaratma ve onları özgürce kullanma konusunda yetkinleştiriyor, tıpkı sizinmiş gibi ve zaten sizin. Azure Sanal Makineleri özelliği hakkında tanıtıma devam etmeyi çok isterdim, çünkü bu harika ve oldukça enteresan. Size Bulut Platformları (laaS) hakkında ” Ne ve Neden ” konusunu tartışmak ve yeni konsepte karşı ilerlemenin makul olup olmadığını konuşmak üzere detaylı bir yazı yazıyor olacağım.



Resource Manager vs Service Management

Microsoft Azure Platformu üzerinde çalışıyorsanız ve Azure Ibıza (Yeni) Portal üzerinden bir hizmeti kullanmak istediğiniz zaman deployment süreçlerine başladığınızda karşınıza “Service Management” ve “Resource Management” şeklinde iki farklı model çıkıyor olacaktır. Bu terimlerin, Microsoft Azure bulut hizmetlerine erişimi sağlayan iki farklı REST API olduğunu söylemekte fayda var. “Resource Manager” bizlere Microsoft Azure üzerinde yeni bir deployment modeli sunar. Bu yeni model, Classic ( Service Management) dağıtım modelinden çok önemli farklılıklar içermektedir ve iki model tamamen birbiriyle uyumlu değildir. Kaynakların dağıtımını ve yönetimini basitleştirmek için Microsoft eğer mümkünse “Resource Manager” deployment modelini kullanmanızı tavsiye eder. Resource Manager ile ilgili daha önce blog içerisinde yazı serisine erişebilirsiniz.

Bu dağıtım modellerinden hangi API tercih edilmelidir sorusuna cevap verelim.

  • Azure Service Management (ASM) – “eski” API
  • Azure Resource Manager (ARM) – “yeni” API



Azure Automation – Part 0:Giriş

Azure Automation, Infrastructure as a service (IaaS) ve Platform as a service (PaaS) gibi aldığınız hizmetlerin Azure içerisinde uzun çalışan, hata eğilimi olan ve sık sık tekrarlanan görevleri düzenli olarak gerçekleştiren bir servistir. Bu makale serisi içerisinde Azure Automation hakkında sık sorulan sorulara cevap vermeye ve genel alt yapısını incelemeye çalışacağız. Makale serisine başlamadan önce size Anıl Erduran‘ın “Microsoft Automation Dün Bugün ve Yarın” adlı yazısını okumanızı şiddetle tavsiye ederim. Şimdi ise yarını detaylandırmaya başlayabiliriz.

100515_2057_AzureAutoma1.png