25 Temmuz 2017 Salı

AWS Lambda ile “Serverless Architectures” – Sunucusuz çok katmanlı uygulama mimarisi.

Genelde AWS(amazon web services) bulut yapısının git gide etki ve kullanım alanını artırması ve özelde bu yazının konusu olan AWS Lambda servisinin 2014 de yayınlandığı tarihden itibaren “çok ciddi kullanım” oranlarına ulaşması ve “ciddi anlamda başarılı” örneklerin artmasıyla birlikte muhtemelen sizinde çok ca duymaya başladığınız  ;
“Serverless  Architectures” yada genel olarak “Sunucusuz uygulama mimarisi” 
diye türkçeye çevirebileceğimiz kavramı AWS Lambda alt yapısı ile genel olarak tanımaya çalışacağız.
“Serverless Architectures / Sunucusuz Mimariler” konusunu teorik olarak çok konuşmadan pratikde AWS Lamda ile tanımaya çalışacağımız bu yazıda, aşağıdaki konulara beraberce  bakarak AWS Lamda yı tanıyalım.
Yazının genel başlıklarını şu şekilde sıralayabiliriz;
  1. Genel olarak Serverless Multi-Tier Architectures – Sunucusuz mimari nedir?
  2. AWS Lambda nedir?
  3. Genel Olarak, AWS Lambda ile  “Serverless  Architectures” in bize getirdiği kazanımlar nelerdir?
  4. AWS Console üzerinde Lambdaya Bakış
  5. Örnek geliştirme ortamı ve yardımcı araçlar
  6. Örnek uygulama
  7. AWS Lambda alternatifleri (IBM OpenWhisk , Azure Functions ve Google Cloud Functions)

Serverless Architectures – Sunucusuz mimari nedir?

Sunucumuzun tüm hatlarıyla gizli kaldığı, bize sadece run-time/çalışma zamanı alt yapısının gözükdüğü ( .NET, Node.js Java vs. gibi. Bunlarıda kurmak yada yönetmek zorunluluğumuzun olmadığı) etki tepki diyebileceğimiz (event / handler) bir yapı ile, belirli şartlarlada çalışacak fonksiyonları yazmamıza imkan veren yapıya genel olarak Serverless Architechure / Sunucusuz Mimari diyebiliriz.
Buradaki en önemli nokta, “bir event/olayın gerçekleşmesi ile çalışacak fonksiyonlar” kısmı diyebiliriz. Böylece tüm bir uygulamayı host etmek yerine, sadece iligli iş yükünü yerine getirecek fonksiyonlar yazma imkanımızın olması bize ciddi kazanımlar ve kolaylıklar getirmekte. Aşağıdaki örnek senaryoya bakarak devam edelim;
Kullanıcımızın bir formu doldurması gereken bir senaryomuz olsun;
  1. Kullanıcı, ilgili formu talep eder (yada biz kullanıcıdan doldurmasını isteriz.)
    1. Bu ilk olayımız için, bir fonksiyonumuz çalışır, kullanıcıya formu sunar
  2. Kullanıcı formu doldurur ve gönder tuşuna basar
    1. Bu olayımız için , yazdığımız diğer fonksiyonumuz, formu alır ve DB ye kaydeder
  3. DB ye kaydolan her form girdisi için “otomatik çalışmasını ” istediğimiz diğer fonksiyon otomatik olarak  tetiklenir
    1. Otomatik olarak tetiklenen fonksiyon, db den bu girdiyi alır ve örneğin “ilgili departmana” email yollar
    2. Aynı zamanda formu dolduran kullancıyada onay e-maili yollar
Yukarıdaki senaryoda dikkat ettiyseniz, aşağıdaki kavramlardan hiç biri yok;
  1. Runtime yada framework kurulumu.(.NET/MVC yada Node/Express gibi)
  2. Sunucu ayarlama, konfigürasyon, ölçeklendirme vs. gibi çetrefilli işler  yok
  3. Fonksiyonlarımız için “çalışmadıkları sürece” sistem kaynakları için ücret ödeme durumumuz yok. (teknik olarak, bir server olsada ve bu server sürekli RAM ve işlemci kullanımı yapsada, biz sadece fonksiyonlarımızın çalışmaları durumun da bu kaynakları kullanmış sayılacagız.)
Gördüğünüz gibi yaşam döngüleri çok basit bir yapıda, bir olay olur yada siz tetiklersiniz bir fonksiyon çalışır ve gerekli iş yükü yerine getirilir. Arada “bizim yazdığımız yada yönettiğimiz” bir middleware, server yada application layer katmanı bulunmaz.  Genel olarak hepsi bu  diyebiliriz.
Daha şematik ve tarihi gelişim açısından ve Cloud/bulut bilişim içndeki yerini anlamak adına aşağıdaki resime bakarak devam edecek olursak;

Related image

IAAS(Sanallaştırılmış donanım), PAAS (Uygulama yada run-time), serverless (sunucusuz mimari) şeklinde bir süreçten geçtiğimizi söyleyebiliriz.
  • Data Centre (Fiziki sunucu kiralama)  : En klasik ve bilinen yol. Bir data centre içinde bir sunucu kiralama. Bu yöntemle, kabaca “Fiziki network alt yapısı ile olan ilişkimizi” soyutlamıştık. Ama donanım(kısmen soyutlanmış) , işletim sistemi, çalışan run-time lar ve uygulamalar soyutlanmamış ve ölçeklenme birimi olarak hala hardware in baz alındığı yapı.
  • IAAS (Infrastructure as a Service) ilk donanım bazlı soyutlamaya geçtiğimiz nokta. hem network, hem donanım ın sanallaştırıldığı alt yapılar.
  • PAAS (Platform-as-a-Service) Sanallaştırmanın bir sonraki noktası Uygulama bazında ölçeklendirme. İşletim sistemininde soyutlandığı yapı.
  •  Serverless , sadece çalışacak fonksiyonların yazıldığı, yukarıdakilere ek oalrak “run-time” ın da soyutlandığı yeni mimari.
Son olarak muhtemelen ; “fonksiyonlarımızı nasıl ve hangi dili kullanarak yazacağımızı” merak etmişsinizdir, bu süreç kullandığınız servise göre değişmekte, örneğin AWS Lambda için , şuan itibariyle “Java, JavaScript ve Python  ile fonksiyonlarımızı yazabilmekteyiz. Bu dillerin dışında diğer alternatifleri (PHP, Ruby, Go vs.) kullanmakta mümkün olsada, bu 3 dil resmi olarak desteklenmekte. İleride muhtemelen daha fazla runtime ekleneip daha fazla dil seçeneği oluşacaktır. Azure functions ise daha fazla dili desteklemekte.Biz Örneklerimizi, “Javascript” ile yazacağız.

AWS Lambda Nedir?

Aws altında sunulan Lambda servisi, genel olarak sunucular, büyük frameworkler , uygulama alt yapısı vs gibi konularla uğraşmak yerine (bunları AWS bizim için otomatik olarak yapacak) iş yükümüz için gerekli işlemleri yerine getirecek “fonksiyonlar” yazmamıza imkan veren bir alt yapı sunmakta.
Execute your code to response an event. and it does fast, it scales millions parallel of your functions
Yazacağımız fonksiyonların belirli şartlar altında otomatik olarak çalışmasını sağlayıp , uygulamamızın iş ve mantık yükünü bu fonksiyonlarla çözmemize imkan veren bu alt yapı sayesinde, sadece kod yazarak(kurulumlara, frameworklere, uygulamanın ölçeklendirilmesine vs. zaman harcamadan) uygulamamızı geliştirme imkanına kavuşmuş olmaktayız.
Başka bir deyişle, uygulamamızda “event-based / etki-tepki” diyebileceğimiz bir döngü ile, her olay için otomatik tetiklenecek yada kendi kendimize çağırabileceğimiz fonksiyonlar yazacağız. Bu fonksiyonlar işlerini yapacak , bizde sadece fonksiyonları yazmaya yani “tek bir sorunu çözmeye” ve “tek bir şeyle uğraşamaya(kodlama)” odaklanabileceğiz. Başta “ölçeklenebilirlik / Scaling” olmak üzere bir çok “zor kısım” bizim için AWS Lambda serivisi tarafından otomatik olarak karşılanacak.
Fonksiyonlar yazacağımız için, uygulamalarımızı istersek iç içe geçmiş mikro servis benzeri bir yapı ile isterseniz bir birlerinden tamamen bağımsız tekil iş üniteleri olarak yazma imkanımız da söz konusu. Ayrıca, uygulamamızın sadece bir kısmını yada bir kısım iş yükünü Lambdaya taşıma imkanınıda kullanabiliriz. Buradaki en önemli nokta olarak ;
İş yükünü alt parçalara “otomatikleştirerek” atamak veya dilerseniz uygulamanızı tamamını yada uygulamanın ana iş yükü dışındaki herşeyi bu şekilde fonksiyonlara taşımak diyebiliriz.
Bu arada son günlerde çokca duyulan “Micro Services” kavramyla Lambda yı karıştırmamak lazım. Biri (Micros Services) Bir tasarım yada uygulama geliştirme düzenini/yaklaşımını ifade ederken, Lambda servisinin kendisi “Micro service ” ler de oluşturabileceğiniz bir iş kanalı yada başka bir değişle pratikde karşılığı olan ,  sorun çözme birimleri diyebiliriz. Lambda ile fonksiyonlarımızı, Micro Service mimariye uygun olarak da yapılandırabileceğimiz gibi, hiç bir tasarım kalıbına uymayacak şekilde sadece “fonksiyonlar ” olarakda  kullanabilmekteyiz.
AWS Lambdanın getirdiği en önemli kolaylıklardan biride şüpesiz AWS üzerindeki diğer servislerle çok kolay bir entegrasyon imkanı diyebiliriz. Örneğin, S3 ye yüklediğiniz her dosyadan sonra otomatik olarak çalışacak fonksiyonlar yazıp, yüklenen her dosyayı otomatik olarak bir işleme tabi tutmaktan tutunda, DynamoDB ye eklenen bir kayıttan sonra otamatik bir başka işlem yapmaya kadar çok geniş bir yelpazede bir entegrasyon imkanı vermekte.
Bir başka avantajda, her bir fonksiyon hem “stateless-durum takipsiz” hemde “izole” olduğu için otomatik olarak ihtiyaca göre kendi kendisini ölçekleyebilmesi diyebiliriz.

Diğer Kazanımlar

Maliyet/Tasarruf: Şüphesiz ilk akla geleni maliyet adına bize kazandırdıkları, Pay-Per-Use Pricing – Kullanım başına ödeme diyebiliriz. Yukarıda kısaca bahsetmeye çalıştım tekrar edecek olursak, sunucunun RAM ve İşlemci kullanımına göre ödeme yaptığımız modelden, sadece foksiyonlarınız çalıştığı zaman ücret ödeme modeline geçmiş olacağız.
Operasyon Kolaylığı: Lambda fonksiyonları stateless ve izole oldukları için istediğiniz gibi organize etme kolaylığı sunmaktalar. Örneğin monolithic(tüm bir uygulama), microservices, yada nanoservices gibi bir çok “süslü” tasarım kalıbıyla çalışmaya uygunlar. Yada hiç birini kullanmayıp, yaz ve çalıştır kolaylığına. Ayrıca Yönetecek, server vb. bir alt yapı da olmadığı için çok daha hızlı bir geliştirme süreci sunmaktalar.
AWS Lambda yazdığımız kodların ihtiyacı olan alt yapıyı bizim yerimize oluşturacak, bakım, güncelleme, güvenlik yamaları, dahili loglama vs bir çok ihtiyacı bizim yerimize gerçekleştirecek.
Ölçeklenebilirlik ve Kararlılık: Aws lambda ihtiyaç duyulması durumunda otomatik olarak kendi kendini ölçeklendirme yeteneğine sahip. Bu yapı syesinde, en az fonksyion çalışma sayısından, günde 1 milyon kere çalışan çok yoğun kullanımlı bir fonksiyona kadar ihtiyacınız ne ise ona göre kendi kendini trafiğe/yoğunluğa adapte edecektir.
Lambda, dahili olarak “high availability / yüksek erişilebilirlik”  ve “ built-in fault tolerance / hata-çökme telafi edicisi ” dediğimiz ve genel olarak AWS in en önemli iki artısı olan yapı ile kararlı bir sisteme sahip olma imkanı vermekte. Örneğin, siz kodunuzu “x” bölgesinde ki “y” data center da bulunan bir bilgisayara yüklediğinizde, AWS Lambda otomatik olarak farklı noktalarda sizin için “her hangi bir sorun olması halinde” çalışacak kopyalarını hazır tutacaktır. Bir servis kullanılamaz olursa hemen diğeri çlaışmaya başlayacaktır.
Dahili Güvenlik Sistemi:  AWS Identity and Access Management (IAM) sayesinde,  diğer AWS servisleri ile iletişimi güvenli bir şekilde yönetmek ve hemen hemen diğer her ihtiyaca cevap verecek bir alt yapı sunmakta.
Yukarıdaki listeye başka maddelerde ekleyebiliriz şüphesiz ama bukadarı yeterli deyip, AWS Lambda yı nasıl kullanabileceğimize geçelelim.

AWS Console üzerinde Lambdaya Bakış

Lambda servisini , diğer AWS servisleri gibi AWS Console üzerinden yada AWS CLI ile kendi bilgisayarımızdan(komut satırından yönetebilmekteyiz.) Öncelikle ilk ve daha kolay alternatif olan AWS Console ile başlayalım.
Tüm AWS servislerini yönetebileceğimiz ve bir yönüyle “AWS yönetici paneli” diyebileceğimiz web arayüzü olan “AWS Console” üzerinden Lamdaya bakarak devam edelim;
Image result for aws lambda consoleImage result for aws lambda console
AWS console üzerinde, “Compute” bölümü altında bulabileceğimiz Lambda servisini çalıştırdığımızda aşağıdakine benzer bir görüntüyle karşılaşmaktayız;
Related image
Bu ekranda bizim için AWS Lambda servisi tarafından önceden hazırlanmış kullanmaya hazır “template” diyebileceğimiz bir çok Lambda Function örneği mevcut. Bu templatelerden birini seçecerek hemen fonksiyonumuzu yazmaya başlayabileceğimiz gibi, sıfırdan kendi fonksiyonlarımızı yazmakda mümkün. Şimdilik “microservice http-endpoint” template ini seçelim ve devam edelim.
İsmindende anlaşılacağı gibi, bu template “http-endpoint” bize yazdığımız fonksiyonu bir http end point olarak çalıştırma imkanı vermekte. Başka bir değişle,  bir URL ile tetikleme yapmamıza imkanı vermekte. 
Sonraki ekranda, fonksiyonumuzu yazıp bazı ayarlamaları yapabileceğimiz aşağıdaki ekranla karşılacağız;
Image result for aws configure lambda

Bu ekran biraz büyük olduğu için iki parça olarak üzerinde konuşalım. Yukarıdaki ilk kısımda, Fonksiyonumuz için bir isim , açıklama, Runtime, fonksiyonu yazım şeklimiz ve son olarakfonksiyonumuzun kendisi gelmekte.
  1. isim ve açıklama kısmı ile lambda fonksiyonumuza bir isim ve dilersek bir açıklama veriyoruz
  2. Runtime seçimi (bizim örneğimizde, Node.js, dolayısıyla Javscript ile yazacağımızı belirtiyoruz)
  3. Code entry type ile fonksiyonu inline mı (hemen bu ekranda) yazacağız, yada önceden yazdığımız bir fonksiyonumu yükleyeceğiz onu belirtiyoruz.
    1. inline : fonksiyonu hemen bu ekranda yazmak için kullanacağımız seçenek. Bu seçeneğin bir dez avantajı eğer fonksiyonunuz büyükse veya kodu yazarken daha fazla editör desteği istiyorsanız(Visual studio veya Webstorm gibi yetenekli bir editör ile yazmak gibi) inline yerine diğer seçenekleri düşünebilirsiniz. Birde, eğer fonksiyonunuz AWS servislerinin dışında başka SDK ler yada NPM paketlerine ihtiyaç duyuyorsa, inline editör bunları eklemenize izin vermemekte.
    2. Upload zip ve Upload file from S3 ise inline seçeneğinin ihtiyacınızı karşılayamadığı durumlarda kullanılacak iki seçenek. Örneğin fonksiyonlarınızı kendi bilgisayarınızda yazıp, ihtiyacı olan diğer sdk ler paket vs i ekleyip Lamdaya yükleyebilmek gibi.
  4. Lambda Function Code ise tahmin edebilecğeiniz gibi, fonksiyonumuzun kendisini temsil etmekte.
Ekranın ikinci kısmı ise şu şekilde bir görnüme sahip;
lambdaSecondCode
Bu kısımda, fonksiyonumuzun nelere(hangi AWS servislerine) erişebileceğine dair güvenlik ve yetki ayarlamasını yapabileceğimiz bir kısım (Role) ve eğer fonksiyonumuzda, birden fazla `entry point`export.* varsa hangisinin çalışacağını beliritiyoruz. (bu kısım biraz node.js e özel, örnekde daha iyi anlaşılacaktır.) Diğer önemli iki kısım ise , fonksiyonumuzun ne kadar RAM kullanacabileceğini seçeceğimiz alan(Memory) ve Azami çalışma süresini ayarlayabileceğimiz “Timeout” kısmı gelmekte.  Bir örnek yazacağımız için, burada daha fazla detaya girmeden next ile bir sonraki ekrana geçelim;
Biz fonksiyonumuzu oluştururken http-endpoint template ini seçtğimiz için, bir sonraki ekranımızda, Configure endpoints seçeneklerini göreceğiz. Kısacası bu Lambda Function, bir url i çağırmamızla tetiklenecek. Örnek de bu kısımı daha rahat anlaşılacaktır.
lambdarevıw
Şimdilik varsayılan ayarları kabul edip devam edelim ve fonksiyonumuzuz hazır hale getirelim. Bir sonraki ekranımız özet ekranımız olacak; Bu ekranda Create Function butonu ile işlemimizi tamamladıktan sonra fonksiyonumuz çalışmaya hazır hale gelecek ve aşağıdaki ekranla karşılaşacağız;
lambdaCrea

Fonksiyonumuz oluşturuldu ve kullanıma hazır, ” API endpoint URL” altındaki adres ise bizim için oluşturulan tetikleme adresimiz. Bu ekran üzerinden fonksiyonumuzu yönetebileceğiz (düzenleme, silme, raporlama vs.).
Buraya kadar genel olarak Lambda Function oluşturma süreci için gerekli olan adımlara baktık.(Lambda Console kullanarak)  Şimdilik fonksiyonumuz herhangi bir şey yapmamakta.
Bir sonraki yazı ile gerçekten çalışan bir kaç örnek yapalım. Örneklerimizden biri API end point olarak çalışsın diğeri ise Otomatik olarak harekete geçsin. Birini Console üzerinden yazalım, diğerinide kendi bilgisayarımızda yazıp Lambda ya yükleyelim.
Bir sonraki yazıda görüşmek üzre.
Kolay Gele.

Kaynaklar.

http://docs.serverless.com/
https://d0.awsstatic.com/whitepapers/AWS_Serverless_Multi-Tier_Architectures.pdf
http://muhammetarslan.com.tr/aws-lambda-nedir-aws-lambda-nasil-kullanilir/
https://aws.amazon.com/blogs/compute/the-squirrelbin-architecture-a-serverless-microservice-using-aws-lambda/
https://yazilimgunlugu.org/a

3 Mart 2017 Cuma

On-Prem Sanallaştırma "VMware Cloud on Amazon Web Servicess"

2016 yılının başlarında Vmware "SDDC" ve Amazon web servis "AWS" mimarisini ve yetkinliklerini birleştirerek, hibrit bulut modeli için stratejik bir anlaşma duyuruldu.

Diğer platformlardaki operasyonel verimlilik, maliyet ve zaman kazanımlarını bu mimaride görebiliyoruz. 

Bu ürün, saatlik, isteğe bağlı olarak veya abonelik formunda erişilebilen, AWS Cloud'da yerleşik ve tamamen yönetilen bir VMware ortamıdır. 

  • VMware vCloud müşterileri için  AWS servislerinden faydalanabilme,
  • Vmware SDDC konseptindeki vSphere, Virtual SAN ve NSX çözümlerindeki uzmanlığınızı kullanabilme,
  • VMware "on-demand" esnek, ölçeklenebilir bir servis olarak açılacak olması. 
  • Flexible Scalability kaynakları daha esnek ve kullandığınız kadarıyla tüketmeyi otomatize edebiliyor.


Söylentilere göre AWS dedike bare-metal sunucular üzerinde çalışan VMware hipervizörleri,ile VMware’in kendi sistemini AWS altyapısı üzerinde nested virtualization (iç içe sanallaştırma) yapmasına gerek kalmadan çalıştırabilmesine olanak tanıdığı anlaşılıyor.

AWS bu ürünün on-prem sanallaştırma ile bulut’a yönelmek isteyen müşteriler için ideal senaryo olduğunu belirtiyor.

Ayrıca müşteri mevcut VMware lisanslarını ve, ESXi, vSAN, and NSX tecrübelerini kullanmaya devam edebilecek.

On-prem’de bulunan tüm VMware ortamlarınızı mevcut vCenter server ile API’lerinden faydalanan tool’larınız ve script’lerinizide yönetebileceksiniz.


Diğer bir göz alıcı özellik ise aynı cluster içerisindeki ESXI hostlar arasında yük dağılımı yapan DRS (Distributed Resource Scheduler) teknolojisi mevcut.

Elastic DRS kaynak havuzunda kapasiteniz dolduğunda DRS’in altındaki esnek AWS altyapısında yeni bir VM açılıyor ve bu fazla gelmeye başlayan yükler otomatik olarak bu VM’e aktarıyor. On-Prem ortamlarda haftalar aylar süren bir operasyonu dakikalar içerisinde hayata geçirebiliyoruz.

Stratejik ortaklık  olarak VMware, AWS’in “Primary Public Cloud Partner” iş ortağı olurken, VMware de AWS’nin yeni “Primary Private Cloud Partner” iş ortağı oldu.

VMware, pek çok büyük şirketin on-prem veri merkezindeki hakim oyunculardan biri iken son yıllarda kullanıcıların talep ettiği
hybrid opsiyonlar için yeterli bir public cloud hizmeti sunamamıştı. Bunun temel nedeni olarak Amazon kanadındaki (IAAS) Infrastructure as a servicess gücünün olduğu söyleniyor.




14 Şubat 2017 Salı

Veri Yedekleme ve Kurtarma Sistemleri

Kurumlar için artık veriler her geçen gün artmanın ötesinde sanallaştırma, bulut bilişim gibi kavramların da ortaya çıkması ile bunları yönetmesi ve koruması da ayrı bir iş yükü ve çok daha büyük riskler haline gelmiş durumda,


Veri merkezinde, bulutta veya kişisel bilgisayarlarda depolanan verilerin, herhangi bir sebepten ötürü zarar görmesi hem çalışma sürelerini etkileyecek hem de veri kaybından doğan maddi zararlar verecektir. Yapılan araştırmalar sonucu kaybolan verilerin geri dönülememesi birçok şirketin kapanmasına kadar çok büyük zararlara sebep verebiliyor.


Temel olarak bilgi kayıplarının 4 temel sebebi vardır; bunlardan ilk olarak insandan kaynaklanan hatalar gelir, bunları donanım arızaları, yazılım hataları ve doğal afetler takip eder. İnsanlar her ne kadar sistemin bir parçası da olsa güvenilmezdir, bilerek veyahut bilmeyerek hata yapabilirler ve sisteme zarar verebilirler. Yeni sistemler her ne kadar çok daha gelişmiş ve hata oranları azalmış olmasına rağmen, halen arızalar çıkarabilir hatta tamamen bozulabiliyorlar. Modern yazılımlar artık birçok testlerden geçtikten sonra bizlere sunulsa da hala hatalar çıkabilmekte ve veri kayıplarına sebep verebilmektedir. Doğal afetler ise ne yazık ki bizim kontrolümüzde olmayan, deprem, sel, yangın gibi olaylardan ötürü yaşanabilecek kayıplar ise çok daha büyük problemlere yol açabilmektedir.


Bu nedenle kurumlarda çalışma süreçlerine bağlı olarak, yedekleme sistemlerin kurulması ve bu işlemlerin günlük olarak takip edilmesi ve geri dönüş senaryolarının oluşturulması gerekmektedir.

Veri yedekleme işlemleri, mühendislik standartlarına uygun olarak, doğru bir yedekleme politikasına ihtiyacı vardır. Yedekleme politikasının yerine getirilebilmesi için ise, detaylı bir belge yönetimine ihtiyaç duymaktadır.

Tüm bu sorunları göz önünde bulundurarak yedekleme ve felaket çözümleri oluşturmamız bilgi yatırımımızı korumanın bir yolu olacaktır. Verilerimizi her senaryoyu göz önünde bulundurarak birer kopyasına sahip olursak, her hangi bir kopyanın bozulması anında problemleri ve veri kayıplarını azami sürelere çekmiş oluruz.

Yedekleme ve Geri Alma 


Yedekleme programları sizlere birçok yedekleme ve geri alma çözümleri sunmakta sistemlerinizin en üst sevide koruması için tasarlanmış durumdadır aşağıda bunları başlıklar halinde bulabilirsiniz;


  • Yerel ve geniş ağ üzerinden merkezi yedekleme 
  • SAN / NAS mimarileri üzerinde yedekleme 
  • Sunucu bağımsız yedekleme 
  • Uygulamaların eş zamanlı olarak yedeklenmesi 
  • Değişken tabanlı ve sentetik yedekleme 
  • Sanal Teyp Kütüphanesi 
  • Teyp tabanlı yedekleme 
  • Disk tabanlı yedekleme 
  • Bulutta yedekleme 
  • Disk kütüphaneleri  
  • Kademeli yedekleme 
  • Anlık geri yükleme 
  • Sistem kurtarımı 
  • Masaüstü ve mobil cihazların yedeklenmesi


Felaket Kurtarma Çözümleri 


Kurumlar, var olan sistemlerin kritikliğine göre bu sistemlerin güvenilirliğini, servis seviyesini ve ayakta kalma süresini mümkün olduğunca ayakta tutmak ve olası felaketlere karşı önlem almak zorundadır. Bu yöntemlerle sistemin korunmasını sağlayarak iş sürekliliğini garanti etmek ve kritik sistemlerde veri kayıplarının engellenmesi hedefenmektedir.


Geri Dönüş Noktası (RPO) ve Geri Dönüş Süresi (RTO) felaket senaryoları tasarlanırken ilk dikkate alınması ve hesaplanası gereken değerlerdir. Bu değerlere göre kendi ihtiyacınızı belirleyip size uygun olan çözümleri seçmelisiniz. Felaket kurtarımına yönelik çözümleri aşağıda bulabilirsiniz;


  • Sunucu tabanlı senkron ve asenkron replikasyon 
  • Disk sistemi bazlı senkron ve asenkron replikasyon 
  • Bulut depolama 
  • Kartuş kasa yönetimi 
  • Mantıksal disk aynalama 
  • Felaket kurtarma planlaması 
  • İş sürekliliği planlaması


Kullanacağınız bu işlemlerin otomatikleştirilmesi sonucu sistemlerinizin korunmasını azami sürelere indirerek veri kaybını ve geri dönüş sürelerini en alt düzeye indirip ve kesinti sürelerini de azaltmış olacaksınız.

RPO/RTO  

Var olan yapının diğer bölgedeki yapıyla arasında geçen eşleşme süresine yani potansiyel bir felaket sırasında kaybolabilir veri miktarını yansıtan süreye RPO deriz.

RTO ise sizin olası bir felaket durumunda sistemi ne kadar sürede tekrar devreye aldığınız zamandır.




Belge Yönetimi 


Kurumlarda ki veriler hızla büyürken, bir yandan da verileri doğru şekilde değerlendirmek gerekmektedir. Bu süreçte verilerin önemine göre sınıflandırmak ve saklamak büyük bir önem kazanmaktadır. Bunları hizmet seviye anlaşmaları, yedekleme stratejileri ve geri dönüş senaryoları ile belirlemek gerekmektedir.





Arşivleme Çözümleri 


Kurumların kuruluş sürelerine göre tüm verilerini aktif kullanma oranları da zamanla azalmaktadır. Bu verileri arşivleyip ihtiyaç anında kullanarak hem eskiyen verilerin gereksiz olarak yer kaplamasını engelleyip hem de sistemlerinin daha hızlı olarak çalışmasını sağlamaktadır.

Arşivleme çözümleri kurumlara etkin saklama ve saklanmış verinin hızlı bir şekilde geri kullanma çözümü sunmakla beraber, içerik arama seçenekleri de sunmaktadır. Ayrıca kullanıcıya hede៯�i biçimde otomatik arşivleme de(gün, ay, yıllık) sağlar.

Kurumlar arşivleme çözümlerini isterlerse şirket politikaları gereği uzun süreli korumalara da olanak sağlayarak, güçlü arama ve keşif özellikleri ile şirket idaresi, risk yönetimi ve yasal korumaya yönelik çözümlerde sunmaktadır.

Teyp tabanlı yedekleme 


Teyp tabanlı yedekleme çok eski ve halen vaz geçilmez bir yedekleme yöntemidir. Her ne kadar bu yedekleme yöntemi diske yedek almaktan çok daha uzun sürse de teyp tabanlı yedekleme maliyetinin aynı kapasiteye sahip disk tabanlı yedekleme maliyetinden daha düşük olması ve saklama olanaklarının daha fazla ve daha dayanıklı olduğu için tercih sebebidir. Ayrıca teyp tabanlı yedeklemeler uzun süreli saklanacak veriler için de tercih edilen sebeplerden biridir.


Sanal Teyp Kütüphanesi 


Teyp tabanlı yedeklemeye alternatif olarak çıkan tek bir noktadan yönetimini sağlamak için tasarlanmış olan bu yedekleme yöntemi, günlük teyp kartuşlarının maliyetini azaltmak için kullanılmaktadır. Çalışma prensibi olarak teyp tabanlı yedekleme sistemine benzemesine rağmen aslında veri disklerinden oluşan sanal bir teyp ünitesiymiş gibi çalışan bir disk sistemidir. Ayrıca yedekleme ve geri dönüm süresi olarak teyp tabanlı yedekleme sistemine oranla çok daha hızlı çözüm sunmaktadır.


Veri Tekilleştirme


Tekilleştirme günümüzde bizi hem yedeklemedeki gereksiz veri depolamalarından hem de bunlar için kullandığımız fazla kaynaklardan kurtaran en iyi çözümdür demek yanlış olmayacaktır. Sağlamış olduğu teknoloji sayesinde veri yedeklemesi yaparken alınmış olan yedeklerin içerisinden tekrarlananlar olursa bunları yedeklemeyip sadece işaretleyerek bizleri gereksiz veri depolamasından kurtaracaktır. Böylece depolama alanlarının da daha az kullanımını sağlayacaktır.


Tekilleştirme, yedekleme programları dosya tabanlı veya blok tabanlı olarak çalışmaktadır. İkisinin de kullanım alanı farklı olmakla beraber blok tabanlı olarak alınan tekilleştirmenin dosya tabanlı olarak alınan tekilleştirmeye oranla çok daha iyi sonuçlar vermektedir.


Veri Yedekleme Yöneticisi



Veri yedekleme yöneticisi yukarıda bahsettiğim ve bahsedemediğim daha birçok yedekleme yöntemlerine hâkim olmakla beraber, belge yönetimini de detaylı olarak yaparak, tüm sistemlerinin yedeklerini düzenli olarak alması, felaket senaryolarını, geri dönüş senaryolarını oluşturması ve bunların periyodik olarak uygulamasını sağlamakla beraber bir sorun halinde hemen müdahale etmekle yükümlüdür. Veri yedekleme yöneticisinin sorumlu olduğu sistemlerin yedekleri almanın yanında o sistemlerin çalışma prensiplerini de bilmek zorundadır. Veri yedekleme yöneticisinin görev ve faaliyetlerini ise aşağıdaki listeleyebiliriz;


  • Mühendislik standartlarına uygun belge yönetiminin hazırlanması 
  • İhtiyaç olan RPO/RTO sürelerinin belirlenmesi 
  • Yedekleme metotlarının belirlenmesi 
  • Yedekleme ömürlerinin belirlenmesi 
  • Arşivlenecek sistemlerin belirlenmesi ve arşivlenmesi 
  • Var olan sistemlerin yedeklemesi
  • Geri alma testlerinin periyodik olarak yapılması 
  • Felaket anında sistemlerin azami sürede çalışmasını sağlamak 
  • Veri kaybı yaşandığında geri dönüşlerini sağlamak 
  • Düzenli yedekleme ve geri alma raporlarının oluşturulması

Veri yedekleme ve kurtarma sistemleri konusunda sizlerde uzmanlaşmak, var olan veya yeni kurulan yedekleme, arşivleme programlarınızı ve felaket kurtarma merkezinizi hatasız aynı zamanda sorunsuz yönetmek istiyorsanız Bilge Adam yedekleme ve arşivleme eğitimlerimize katılabilirsiniz. 






Genel Storage Özellikleri Bölüm2(Replication DRS BusinessContinuity)

Makalemin 2. Bölümünde özellikle felaket senaryoları için vazgeçilmez olan Replication’ı anlatmaya çalışacağım. Tabi makaleye başlamadan önce birkaç felaket durumu ve yanlışlıkları ile ilgili birkaç bilgi vermek istiyorum. Felaket durumu deyince aklımıza ilk deprem, sel, yangın gibi olaylar geliyor. Bu gibi durumlarda yakında bulunan her şeyi kapsayacağından felaket senaryolarında mutlaka farklı bir bölge de sistemlerimizin yedeklerinin tutulması gerekiyor. Bizlerde yapılan yanlışlıklar ise bunları maliyetini düşürmek için yakın lokasyonlar seçerek yapınca ortaya çıkıyor. Sanki yangın çıkınca veya deprem olunca yakın lokasyonada da olmayacakmış gibi düşünüyoruz. Bazılarınızı duyar gibiyim deprem olmuş ben ölmüşün ne sistemi, ne yedeği der gibi. İşin acı gerçeği bizler ölsek de o sistemler yaşamalı.



Replication


Storage tarafında replication; var olan storage üzerindeki önemli volumelerimizin bir başka bölgede bulunan diğer storage üzerine o volumelerin birebir eşlenme işlemine denir. Replication’da önemli olan konulardan biri zamandır. Çünkü sizin için verilerin ne kadar kritik olmasına göre seçeceğiniz replication türü de değişecektir. Zaman kavramları için Recovery Point Objective/ Recovery Time Objective diye adlandırdığımız iki faktör devreye girecektir. Bu iki kavramı backuplarda da duymuş olabilirsiniz mantık olarak aynı sadece işlev olarak biraz farklılık gösteriyorlar.


RPO/RTO



Var olan yapının diğer bölgedeki yapıyla arasında geçen eşleşme süresine yani potansiyel bir felaket sırasında kaybolabilir veri miktarını yansıtan süreye RPO deriz. Şöyle bir örnekle açıklamaya çalışayım; diyelim ki saat 16:00’da storage’ınız arızalandı ve sizin replica sitenız ise 4 Saat’te bir güncelleme yapıyor. En son güncelleme ise saat 13:00’de yapılmış olsun. Arada 3 saatlik bir kayıp var demektir. Fakat siz 4 saat günceleme zamanı koyduğunuzdan ötürü 4 saatinizi riske edebilmişsiniz demektir. İşte bu 4 saatlik süre sizin maximum RPO sürecinizdir. Eğer RPO’nuz sıfır olsun istiyorsanız Synchronous Replication tek çözümdür.

RTO ise sizin olası bir felaket durumunda sistemi ne kadar sürede tekrar devreye aldığınız zamandır. Tabi bu da sizin diğer lokasyonda birincil lokasyonuzda ki server’a eşdeğer bir sunucu bulundurma ve bağlanma süreniz ve kullanmış olduğunuz storage marka ve modeline göre eleman bulundurup bulundurmadığınıza göre değişkenlik gösterebilmektedir.






Synchronous Replication


Synchronous Replication’da ilk olarak sunucudan gelen veri kaynak volume’e yazılır fakat acknowledge paketi sunucuya geri iletilmez. İkinci adımda veri hedefteki volume’e yazılır ve hedef volume acknowledge paketini kaynağa gönderir. Son adımda kaynak volume server’a acknowledge paketini gönderir ve veri yazılmış olur. Bu süreç bitene kadar veri sunucuya yazılmaz. Burada RPO süresi 0 olarak RTO süreside kullandığınız teknolojiye göre değişkenlik gösterebilir. O yüzdendir ki aradaki bağlantı çok önemlidir. Çünkü diğer lokasyona erişim sırasında bir sorun olursa sizin tarafınızda da verinin bozulmasına sebep verebilir. Düzgün bir alt yapınız yoksa bu yöntemi seçmeniz tavsiye edilmez. Hatta ve hatta yedekli hatlar ile gitmeniz tavsiye edilir. O yüzdendir ki bu Synchronous Replication’da Fiber altyapılı hatlar kullanılması tavsiye edilir. Eğer hat fiber ise fiberde Km başına 0,005 ms kayıp vardır. Storagelar arası Synchronous Replication’da tavsiye edilen ms değeri (verinin yazılması ve bilgi paketinin geri gelme süreside hesaplandığında) 1ms’yi geçmemelidir. O yüzden iki storage arası en fazla 100 km uzaklıkta olması tavsiye edilir. Maximum destek ise 5ms’dir bu da 500 km’ye ulaşan bir destek var diyebiliriz ama o kadar uzak lokasyon seçilmemesi daha çok tavsiye edilir. Lakin böyle bir altyapı hem çok pahalı hem de her yerde fiber bir altyapı bulmak mümkün olmayacağından daha ucuz ve alternatif çözümler bulmak gerekebilir. Bu alternatiflerden biride Asynchronous Replication’dır.






Asynchronous Replication 


Bu yöntem Synchronous Replication’a göre daha az maliyetli ve daha az bandwitdh ihtiyacı bulunmaktadır. Asynchronous Replication’da ilk olarak sunucudan gelen veri kaynak volume’e yazılır ve acknowledge paketi sunucuya geri iletilir ve veri yazılmış olur. Üçüncü adımda sizin belirtmiş olduğunuz synchronize süresinde veri hedefteki volume’e yazılır ve hedef volume acknowledge paketini kaynağa göndererek işlem tamamlanmış olur. Burada RPO süresini siz belirliyorsunuz ve buna göre synchronize süresini storage’ta ayarlıyorsunuz. Peki, bunu neye göre belirlemeliyiz bir örnekle açıklamaya çalışayım.

Diyelim ki 5 TB’lık bir volume’ünüz var ve her gün değişen 40GB’lık veriniz var. En fazla da 4 saatlik bir kayıp göz ardı edilebiliyor olalım. O zaman bizim RPO süremiz 4 saat demektir ve 4 saatte bir veri diğer lokasyonda bulunan storage’a veriler synchronize edilmelidir. Ama ilk önce 5TB’lık ilk volume verisi diğer lokasyonda bulunan storage’a geçmeli ve bunun için diğer storage’ı aynı lokasyona getirip ilk synchronize işlemini aynı yerde yapmanız tavsiye edilir. Ondan sonra sadece değişen verileri göndererek çok yüksek bandwitdh ihtiyacımız olmasına gerek kalmaz. Burada altyapımız değişen verinin 4 saatte bir gidecek kadar bandwitdh’e sahip olması gerekir. Değişen verimiz 4 saatte 40GB’tı. O zaman bunu şu şekilde hesaplayabiliriz; Bandwitdh = bit/sn ise byte’ı bit’e çeviremek için 8 ile çarpmamız gerekir.

40GB/4Saat *8= 40960MB/14400Saniye *8= 2,8777MB/Sn*8= 22,8Mbit/sn’lik bir bandwitdh olmalıdır.

Kısacası elinizde ki bandwitdh değerine göre bunu kendinizde hesaplayabilirsiniz. Değişen verilerin boyutunu değiştirmek sizin elinizde olmayacağından10Mb/sn’lik bir bandwitdh’niz varsa süreyi uzatarak bu problemi çözebilirsiniz ya da bandwitdh değerinizi arttırmaya çalışabilirsiniz.



Umarım Replication konusunda fikri olmayanlar veya süre hesaplamayı bilmeyenler için yaralı olmuştur. Biz sonraki makalemde görüşmek üzere.



Genel Storage Özellikleri– Bölüm1(Snapshot ve Clone)

Bu makalede marka marka değilde genel olarak storage özelliklerine bir bakış yapalım istedim. Çünkü bu anlatacaklarım, tüm storagelarda üç aşağı beş yukarı birbirine benzeyen özelliklerdir. Bundan sonraki storage makalelerimde, tüm hâkim olduğum ürünlerin yapılandırılmasından da teker teker bahsetmeye çalışacağım. İçerik olarak; Snapshot(Copy-on-Write, Redirect-on-Write), Clone, Thin-Clone, Replication(RTO/RPO, Synchronous Replication, Asynchronous Replication), ALUA, Thin Provisioning, Cache, SSD Read Cache, Virtualization Storage, Dynamic Pool, Automatic Tiering, Deduplication, Compression, VAAI, ODX gibi konularını her bir bölümde işliyor olacağım. NOT: Daha önceki makalemde genel bir IOPS hesaplamasından bahsetmiştim. Burada kısa da olsa RAID yapılandırılmasından ve penaltı değerlerinden bahsettiğim için tekrar RAID konusunu daha sonra detaylı olarak anlatacağım. Ama genel bilgi olarak aşağıdaki adresden inceleyebilirsiniz.
https://ilkeratasoy.blogspot.com.tr/2017/02/bir-storage-ihtiyacmz-dogdugunda-hangi.html


Snapshot Nedir? 

Snapshot (Anlık Görüntü) varolan yapınızın o andaki bilgilerinin pointerını oluşturup bunları koruyarak tekrar o ana geri dönmenizi sağlayan bir teknolojidir. Ama sakın yanlış anlaşılmasın bu bir backup değildir. Çünkü bir yapının backup’ının olabilmesi için birebir aynısının bir başka yerde olması demektir. Snapshot’da böyle bir durum söz konusu değildir. Aslında birçok sistemci snapshot kavramını Vmware veya Hyper-V’de kullanmıştır ya da en azından duymuştur. Sanallaştırma platformlarında snapshot teknolojisini copy-on-write diye adlandırdığımız bir metot ile kullanıyoruz. Birçok storage’da bu teknolojiyi kullanarak snapshot alıyor fakat çalışma prensipleri biraz farklılık gösteriyor. Bunun dışında şuan daha çok tercih edilen diğer bir metodun adı da Redirect-on-Write’tır. Gelin snapshot modelleri üzerinden bunları sizlere anlatmaya çalışayım.

Copy-on-Write Modeli 

Bu method çalışırken snapshot alındıktan sonra ilk önce yapının pointerlarını alır ve LUN’un bir block’u değişecekse önce bu block’u Snapshot volume’ne kopyalayıp pointer bilgisini değiştirir. Daha sonra da LUN’daki block’un üzerine değişen block yazılır. Kısacası önce kopyalayıp sonra yazıldığından bu modele copy-on-write modeli diyoruz. Öncelikle bu tip snapshot metodlarını kullanabilmek için snapshot için storage üzerinde ekstra bir volume oluşturmanız gerekmektedir. Bunu da ortalama LUN’unuzun %20 değişimi gibi düşünürseniz; 100GB’lık bir LUN için 20GB’lık bir volume ayırmanız lazım. Aşağıdaki şekilde de bunu açıklamaya çalıştım. Gördüğünüz gibi snapshotlara backup diyemiyoruz. Çünkü Volume’u kaybedersek verilerimizi kurtarabilecek kadar bilgiye snapshot alanında sahip değiliz. 


Ayrıca bu metotta önce kopyalama yapıldığından snapshot alınmış bir volumede yazma işlemi yapıldığında bir performans kaybı oluşacaktır. O yüzdendir ki birçok storage markası bu yöntemden Redirect-on-Write modelini kullanmaya başlamıştır. Ama halen Copy-on-Write modeli de geçerliliğini korumaktadır.


Redirect-on-Write 


Copy-on-Write modelinde hatırlarsanız bir snapshot alanı oluşturuyorduk ve snapshotlar bu bölgelere yazılıyordu. Bu metotta da bu şekilde çalışan storage markaları bulunmakta biz bu tip storagelara geleneksel storagelar diyoruz. Fakat artık storage markaları virtualization storage olarak adlandırdığımız bir yapıya geçiyorlar burada snapshot alınırken zaten sadece RedirectonWrite modelini kullanıyoruz. Çünkü burada blocklar yazılırken belli bir disk grubuna değilde bir disk havuzuna yazılıyorlar. Ama burada da snapshot için belirli block alanlarını rezerve etmeniz gerekiyor. Makalemin ilerleyen bölümlerinde virtualization storage kavramıyla ilgili detayları veriyor olacağım. 

Bu yöntem çalışırken yine önce blockların pointerları kaydelir ve değişen block’u geleneksel storagelarda direk olarak snapshot alanına kopyalayıp pointer bilgisini de değiştirmemiş olur. Virtualization storagelarda da zaten bir havuz mantığı olduğu için direk olarak havuzdaki rezerve edilmiş olan block alanına yazılıyorlar ve burada da pointer bilgisi değişmemiş oluyor. Ayrıca burada Copy-on-Write modelinde ki kopyalama sürecini de beklememiş oluyorsunuz.



Clone Nedir? 


Clone bir Volume’mün T zamanında ki birebir kopyasını oluşturma işlemine verilen addır. Burada da yine geleneksel ve Virtualization storage kavramları devreye giriyor. Geleneksel Storagelarda volume bilgisi clone volume’me geçerken clone olan volume’mün içeriğinin kopyalaması bittikten sonra kullanılmaya başlanıyor. Fakat Virtualization storagelarda önce var olan volume’mün pointerları alınıyor ve clone volume bilgileri buraya kopyalana kadar burada ki pointerları kullanıp Clone oluşmadan kullanabilmesi sağlanıyor. Kopyalama işi bittikten sonra iki adet Volume oluşmuş oluyor ve Clone olan volume pointerları değişmiş oluyor. Her iki modelde de bir volume’mün kapladığı yer kadar yer kaplıyorlar. O yüzden clonelara backup diye adlandırabiliriz. Genelde kullanım alanlarına örnekler vermek gerekirse var olan volume korumak için, varolan volumeden bir tane daha ihtiyacınız olduğunda veya volume üzerinde test yapmak istediğinizde gerçek volume yerine clone üzerinde test etmek için kullanılabilir.




Thin-Clone Nedir?


Thin-Clone; bir volume’mü template haline sokup, sonra burayı read-only hale getirip bu volume’e bağlı olarak oluşturulan volumelere Thin-Clone diyoruz. ThinClonelar Template volume üzerinde ki bilgileri ortak olarak kullanırlar ve Template olan volume read-only olduğu için bir thin-clone buradaki bir block’u değiştirmek istediğinde veya farklı bir block yazmak istediğinde kendi alanında ki yere yazarlar. Böylece diğer thin-clonelar için ortak olan bilgiler template’ten kullanılacağından storage’da yer tasarrufu da yapmış oluruz. Eğer template volume bir işletim sistemi ise ve üzerinde belli başlı uygulamalar varsa thin-clonelarıda boot from SAN yaparak tekrar tekrar kurulum yapmanın da önüne geçmiş oluruz. Bu yöntem desktop sanallaştırma için de tercih edilebilir. Bazı sanallaştırma firmaları (Vmware View, Citrix ZenDesktop, vb.) için storage firmaları kendi plug-inlerini yazarak sanallaştırma platformlarının üzerinden storage yönetimi yapıp buradaki thin-cloneları da yönetebiliyorlar. Böylece bir kullanıcı için ayrı ayrı kurulum yapmak yerine tek bir kurulum yapıp buradan kullanıcılara thin-client gibi cihazlarla dağıtım yapılarak storage ve bilgisayar masrafını azaltmış oluyorlar. Tabi ister sanallaştırma da isterseniz de direk olarak storage üzerinden thin-clone kullanın, böyle bir yapı için mutlaka iyi bir IOPS hesaplanması yapmak zorundasınız. Çünkü yer tasarrufu yapmaya çalışırken aynı anda 100 kullanıcı buraya veri yazmaya çalışması ister istemez bir performans kaybına sebep verebilir. Kısacası yararları olduğu kadar dikkat edilmezse çok fazla kullanıcı problemiyle de karşılaşabilirsiniz.




Bir sonraki makalemde storagelarda yine önemli bir yeri olan Replication konusunu anlatıyor olacağım. Görüşmek üzere…

Doğru Storage yatırımı nasıl yapılmalı. How to invest in the right storage ?

Bir storage ihtiyacımız doğduğunda hangi donanım bizim için daha uygundur demek yerine benim nasıl bir donanıma ihtiyacım var demek daha doğrudur. Fakat bunu diyebilmek için birçok değerleri iyi bilmek ve bunları hesaplamak gerekmektedir. Bu makalede tüm bu değerlerin ne olduğundan ve nasıl hesaplanması gerektiğinden bahsediyor olacağım.

IOPS Nedir? 


  • Açılımı Input/Output Operation per second olan IOPS aslında disk yapılarında performans ölçümü için kullanılan bir parametredir diyebiliriz. Ama disk markaların vermiş olduğu bu parametreler olabilecek en iyi koşullara göre hazırlanmış olduğundan gerçek dünya için tam bir değer sayılamazlar. IOPS değerleri sizin işletim sisteminize, o an yazmakta veya okumakta olduğunuz oranlara, sıralı mı yoksa rastgele mi yazma okuma yaptığınıza, erişim süresine (latency), raid levelına ve raid yapısından doğan penaltı değerlerine kadar değişen birçok faktör bulunmaktadır. 
  • O yüzden bir kurulum esnasından storage veya sunucu üzerinde disk seçimi yapmadan önce yardımcı bir program kullanmak en iyisidir(Iometer, IOzone, FIO). Tabi bu programlarda çıkan IOPS değerleri sizin sunucuda oluşturmuş olduğunuz IOPS değerleri olacağından bir storage’a geçiş veya yeni bir sunucuda disk seçimi yapılacaksa burada kullanacağınız değerlere raid penaltı değerlerini de ekleyip tekrar bir IOPS değeri çıkartmanız en doğrusu olacaktır. Bunun için her vendorun mutlaka bir IOPS tool’u vardır onlardan yararlanabilirsiniz ya da biz nasıl hesaplarız diye merak ediyorsanız makalenin ilerleyen bölümlerinde detaylı bir şekilde anlatacağım. İlk defa kurulum yapılacak ise daha önceden sizin yapınıza benzer bir yapı örnek alarak seçim yapılmasında yarar vardır. 


Block 
Veri transferinde veri akışının kullanımını kolaylaştırmak için verinin belli bölümlere ayrılması işlemine block denir. Disk yapılarında bilgileri aktarmak için verileri gerek işletim sistemi düzeyinde gerek storage tarafında sabit uzunluklarda bloklara ayırma işlemine ise block size denir.

Disk Tipleri 

SATA 

  • Serial ATA (SATA) diskler Paralel ATA (PATA) disk sürücülerin yeni halidir. 
  • Disk sürücü mekanizmaları benzer fakat arayüzü çok farklı iki mekanizmadır. 
  • Ortalama IOPS değerleri ise 40 ile 90 arasında değişkenlik gösterebilir. 


NL-SAS  

  • SATA disklerin SAS bağlantısı ile tasarlanmış haline NLSAS diye adlandırıyoruz. 
  • Ortalama IOPS değerleri ise 70 ile 110 arasında değişkenlik gösterebiliyor. 
SAS
  • (Serial Attached SCSI) Paralel SCSI yerine gelen bir disk yapısıdır ve verileri paralel yazma yerine seri olarak yazan bir teknolojidir. 
  • İki tip disk yapısı vardır; 10,000 RPM ve 15,000 RPM Ortalama IOPS değerleri 10k için 120 ile 140 arası, 15k için 160 ile 180 arasındadır. 
SSD 
  • NAND ash tabanlı bir depolama çözümü olan SSD bir disk dönmesi gibi problemleri olmadığından ve veri erişim esnasında daha az latency oluşturduğundan artık birçok uygulama için tercih haline gelmeye başladı. 
  • Ortalama IOPS değerleri bağlantı tipine göre çok fazla değişkenlik gösterebiliyor; 400 ile başlayıp Fusion-io ioDrive2 kullanıldığında 9,608,000 gibi değerlere ulaşılabiliyor. 

RAID Levellarının performans ve RAID penaltı değerleri 


RAID 0 Striping

  • Gelişmiş bir performans sunan fakat hata toleransı bulunmayan bir disk dizisidir. 
  • Aslında bir gerçek bir RAID olmamasına rağmen RAID ile çok fazla benzer özellik gösterdiğinden RAID levelları arasında sayılıyor. 



Mininum    : 2 Disk


Maksimum : Raid kontrollerine göre değişkenlik gösterebiliyor.

Boyut          : Toplam disk sayısı kadar

Yedeklilik    : 0

Penaltı Değeri : Aslında 0 ama değişkenler hesaplanırken 1 olarak kullanıyoruz.



RAID 1 Mirroring 

  • Bir diskin bire bir diğer diske de yazma(aynalama) metodudur. 
  • Elimizde iki diskede aynı veriyi yazdığımızdan ötürü burada bir performans kaybımız bulunmakta. 
  • Kısacası veri yazıldığı zaman bir değer kaybederiz işte bu kaybettiğimiz değere raid penaltı deriz. 
  • Burada 2 diske aynı anda yazılma yapıldığından kaybımız 2’dir. 


Mininum             : 2 

Disk Maksimum : 2 

Disk Boyut          : Toplam disk sayısının yarısı kadar

Yedeklilik            : 1 Disk

Penaltı Değeri      : 2 




RAID 5 Stripe with parity


  • Veri güvenliğini sağlarken performansta sunan bir teknoloji olup en az 3 disk ile oluşması gerekmektedir. 
  • Veriler yazılmaya başlanırken ilk adımda kaç adet disk ile oluşturulmuşsa; disklere veri yazılırken sonuncu diske de bu verilerin algoritması yani parity değeri yazılır. 
  • İkinci adımda en son yazılan parity değeri okunur ve diske veri yazılırken, bu verilerin parity değeri en son yazılmış olan parity değerinin bulunmadığı sırada ki diske yazar ve işlem bitene kadar bu döngü tekrar eder. 
  • Bu yapıdan daha önce denenmiş olan RAID 3 ve RAID 4’teki tek disk parity olarak kullanma mantığına sahipti. 
  • Fakat bu sistem parityi yazarken daha iyi performans vermesine rağmen parity dışında bir disk bozulduğunda algoritmaları hesaplayıp sürekli eksik veriyi tamamlamaya çalıştığı için daha çabuk disklerin bozulmasına ve daha çok veri kaybedilmesine sebep vermiştir. 
  • Bundan dolayı farklı disklere parity değeri yazılmaktadırlar. 
  • Bu da ister istemez ilk başta bir performans kaybına sebep vermektedir. 3 adet yazma ve yazma sırasında 1’de okuma yapıldığından buradaki raid penaltı değerimiz 4’tür.

Mininum             : 3

Disk Maksimum : Raid kontrollerine göre değişkenlik gösterebiliyor.

Boyut                  : Toplam disk sayısının 1 eksiği disk kadar

Yedeklilik           : 1 Disk Penaltı

Değeri                 : 4




RAID 6 Stripe with double parity 


  • RAID 5’e ek olarak bir tane daha parity değeri ekliyor ve böylece 2 disk yedekliliğine kadar çıkıyor. 
  • Fakat bu seferde hem yazma hem de okuma işlemi 1 tane daha artmış oluyor. 
  • Toplamda 4 yazma ve yazma sırasında 2 adette okuma yapıldığından raid penaltı değeri 6 olarak çıkıyor. 

Mininum    : 4 Disk

Maksimum : Raid kontrollerine göre değişkenlik gösterebiliyor.

Boyut          : Toplam disk sayısının 2 eksiği disk kadar

Yedeklilik   : 2

Disk Penaltı Değeri : 6




RAID 10 


  • En az iki tane RAID 1’in RAID 0 ile birleştirilmiş halidir. 
  • Veri yazılırken ilk başta RAID 0 gibi hareket edip ikinci kısımda ise RAID 1 gibi hareket ediyorlar. 
  • Burada penaltı hesaplanırken RAID’lerin penaltı değerlerinin çarpımlarından oluşuyor yani burada da penaltı bu yüzden ikidir diyoruz. 


Mininum    : 4 Disk

Maksimum : Raid kontrollerine göre değişkenlik gösterebiliyor.

Boyut         : Toplam disk sayısının yarısı kadar

Yedeklilik  : 1

Disk Penaltı Değeri : 2




RAID 50

  • En az iki tane RAID 5’in RAID 0 ile birleştirilmiş halidir. 
  • Veri yazılırken ilk başta RAID 0 gibi hareket edip ikinci kısımda ise RAID 5 gibi hareket ediyorlar.
  • Burada penaltı hesaplanırken RAID’lerin penaltı değerlerinin çarpımlarından oluşuyor yani burada da penaltı bu yüzden dörttür diyoruz. 


Mininum    : 6 Disk

Maksimum : Raid kontrollerine göre değişkenlik gösterebiliyor.

Boyut : Toplam Raid 5 sayısı x (bir raid yapısı içindeki disk sayısı – 1)

Yedeklilik  : 1 Disk Penaltı Değeri : 4




RAID 60


  • En az iki tane RAID 6’in RAID 0 ile birleştirilmiş halidir. 
  • Veri yazılırken ilk başta RAID 0 gibi hareket edip ikinci kısımda ise RAID 6 gibi hareket ediyorlar. 
  • Burada penaltı hesaplanırken RAID’lerin penaltı değerlerinin çarpımlarından oluşuyor yani burada da penaltı bu yüzden altıdır diyoruz. 


Mininum     : 8 Disk

Maksimum  : Raid kontrollerine göre değişkenlik gösterebiliyor.

Boyut          : Toplam Raid 6 sayısı x (bir raid yapısı içindeki disk sayısı – 2)

Yedeklilik   : 2 Disk Penaltı Değeri : 6




Gerçek IOPS Hesaplama 


  • Makalenin girişinde IOPS’tan ve bu IOPS değerlerini bulmak için bir yardımcı program kullanmamız gerektiğinden bahsetmiştik. Kullanmış olduğunuz herhangi bir analiz programıyla sistemim ihtiyacı olan IOPS ve Read/Write ratio değerlerini çıkarttıktan sonra sistemin asıl ihtiyacı olan IOPS’u hesaplamak gerekir. Çünkü bu programlar sizin alt yapınızda ki Raid levelını ve bunlardan oluşan penaltıyı hesaplamaz.RAID penaltı aslında disklere erişim süresi ve kullandığı modele göre yazma şekillerinden ötürü kaybetmiş olduğu değerlerdir ve bu değerler yazma kısmında kaybetmiş olarak düşünebilirsiniz. Raidlerine göre penaltılarını yukarıda belirtmiştik aşağıda kısaca özetlemiş bulunuyorum.

RAID 0     1 

RAID 1     2 

RAID 5     4

RAID 6     6 

RAID 10   2



Bu penaltılar ile beraber bir IOPS hesapladığınızda aşağıdaki formül oluşur. 

Gerçek IOPS = ((Toplam IOPS × % READ)+ (Toplam IOPS × % WRITE × RAID Penaltısı))


Örnek olarak bir Vmware sisteminiz olsun ve buranın analizini yaptıktan sonra ortaya 2000 gibi bir IOPS değeri ve % 40 oranında okuma % 60 oranında da yazma olsun ve Raid olarak Raid 10 seçmiş olalım. 

Formulü işleme koyduğumuzda


((2000x%40)+(2000x%60×2))= 800 +2400 = 3200 gibi bir rakam çıkar. 

Bu çıkan değer ise bizim gerçek IOPS ihtiyacımızı göstermiş olur.


Bandwitdh


Verinin anlık veya toplamda kullanabileceği veri transfer limitini gösteren değere bandwitdh denir.

Storage tarafında kullandığımız bandwitdh boyutları ise 1 ve 10Gb; iSCSI ve NAS tarafında, 2, 4, 8 Gb; ise FC tarafında geçerlidir. Gelecek teknolojilerde ethernet çözümü 40Gb, FC de ise 16Gb olarak tasarlanmış durumda fakat şuan sadece switch düzeyinde kullanım aşamasındalar.

Bandwitdh ihtiyaç hesaplanması için şöyle bir formül bulunmakta; 

Bandwitdh = IOPS x Block Size x 8

Bu formül ile ihtiyacınız olan bandwitdh ortaya çıkacaktır. Bir önceki örnekten devam edelim;

Burada çıkan gerçek IOPS ihtiyacımız 3200 idi ve Vmware kullanılmıştı. Vmware’in VMFS5 şeklinde formatlanmış yapısı 1MB Block Size olarak tasarlanmıştır. Formülü kullanacak olursak; 

Bandwitdh = 3200 x 1 x 8 =25600 Mbit/sn. = 25Gbit/sn. Bu da en az 4 adet 8 Gbit’lik FC bağlantı, 3 adet 10 Gbit’lik iSCSI bağlantı ile sağlanabilir. 


Storage Seçimi


Bu kısma kadar storage için etken oluşturan değerleri bir gözden geçirmiş olduk. Şimdi bu bilgileri temel alarak bir storage seçimine geçelim. Elimizde bir tek boyut hesabımız ve kaç disk kullanmamız gerektiği kaldı.

Yukarıda ki örnekten devam edelim.

Seçebileceğimiz bağlantı modelini belirlemiş olduk aslında 4 adet 8Gbit’lik FC veya 3 Adet 10Gbit’lik bir iSCSI storage olmalı demiştik ve 3200 IOPS ihtiyacımız çıkmıştı.

Boyut olarak 5 TB’lık bir alana ihtiyacımız olsun. 

Disk olarak 15k’lık SAS 600 GB’lık diskler kullanalım. Yapımızda RAID 10 kullandığımızda boyut için çıkan disk ihtiyacımız 18 olarak çıkıyor. 18 disk ile IOPS ihtiyacımız karşılayabilecek miyiz bir bakalım.

Toplam IOPS = Disk IOPS x Disk Sayısı = 180 x 18 = 3240 olarak IOPS elde edebiliyoruz. Bu da IOPS ihtiyacımızı karşılamış oluyor.

Ortamda Clone ve Snaphot kullanımı da olacaksa Bunlar için de disk ihtiyacımızı belirleyelim. 

Bunlar için bir IOPS ihtiyacımız bulunmadığından NL-SAS disklerde kullanabiliriz. Boyut olarak 5 TB’lık alan ihtiyacımız olduğundan Clone için de bu kadarlık bir alana ihtiyacımız var. Snapshot için ise var olan 5TB’lık alanın maksimum %20’sinin değişebileceğini düşünecek olursak 1 TB’lık alanda snapshot için ayıracak olursak toplam 6 TB’lık bir alana ihtiyacımız var. 1 TB’lık diskler ile RAID 5 kullanarak toplam 7 Disk içinde burası için ihtiyacımızı karşılamış bulunmaktayız.

Tabi ki disklerin sadece RAID ile değil storage tarafında da yedekliliğini de sağlamak için burada SAS diskler için en az iki diski global spare ve NL-SAS diskler içinde en az bir tane diski global spare olarak ayarlarsak toplam SAS için 20 Disk, NL-SAS için ise 8 Disk yeterli olacaktır. 

Son olarak da yıllık büyüme hedeflerinizi belirleyip bunun içinde disk ihtiyacımızı eklediğimiz zaman kaç disk ihtiyacımız ortaya çıkacaktır. Bundan sonrası ise bir marka seçmek olacaktır. Burada karar tamamen sizin hangi markaya güveniyor veya hangisi sizin bütçenize uyuyor ise onu seçmeniz yeterli olacaktır.

Başka makalelerde X markanın ürünlerininde özelliklerini de anlatmaya çalışacağım. 

Görüşmek üzere…  

Popüler Yayınlar