Sitemizi kullanabilmeniz için tarayıcınızda javascriptlerin çalışmasına izin vermelisiniz.

HANA Sistemlerinin Ölçeklendirilmesi

HANA Sistemlerinin Ölçeklendirilmesi


SAP sistemleri, disk tabanlı büyüyen veritabanı yapısından farklı olarak, yine SAP tarafından geliştirilen HANA veritabanı ile hem uygulama katmanında hem de veritabanı katmanında köklü değişikliklerin gerçekleşmesine sebep oldu. HANA'nın en farklı özelliklerinden bir tanesi verilerin bellek üzerine yüklenerek çok daha hızlı işlem yapmasına ve sorgulara daha hızlı cevap vermesine olanak sağladı.

Klasik veritabanı ile çalışan SAP sistemlerinde artan veri nedeni ile oluşan kaynak ihtiyacı büyük oranda veritabınına yeni disk alanları eklenerek gideriliyordu, sistem üzerindeki yük artmadığı sürece işlemci veya bellek miktarında ciddi bir artış ihtiyacı oluşmuyordu. Bundan dolayı SAP için donanım yatırımı yapan şirketler 3-5 yıllık bir öngörü ile yaptıkları bu yatırımlarında SAP ve veritabanı kaynaklı bir kaynak darboğazı kolay kolay yaşamıyorlardı.

HANA ile birlikte veriler belleğe yüklendiği için veritabanı boyutunun artması sadece disk tarafında büyüme ile sınırlı kalmıyor aynı zamanda bellek miktarının da arttırılması ihtiyacını neden oldu. Bellekler diskler kadar ucuz ve kolay sağlanamadığı için 3-5 yıllık öngörü ile tasarlanan HANA altyapılarının ölçeklendirilmesi kritik bir konu haline geldi.

Canlı HANA sunucuları SAP tarafından sertifikasyon süreçlerini tamamlamış kullanıma hazır donanımlar (appliance) veya TDI diye adlandırılan sunucular üzerinde çalıştırılması gerekiyor. TDI modelinde sistemlerin uyumluluğu ve ihtiyaçları karşılaması ile ilgili sorumluluk müşteri ve/veya entegratörde oluyor. Sertifikalı sunucular listesine ait linki yazımızın sonunda paylaşıyorum. Bu sertifikalı sunucularda işlemci sayılarına göre desteklenen bellek miktarı da değişmektedir, hatta çalıştırılacak SAP uygulamasına göre (BW / SoH, S4H) bile aynı işlemci adetinde desteklenen bellek miktarı farklılık gösterebilir. 2 soketli sunucuların çoğunluğu 3TB ‘a kadar desteklenmekte olup daha fazla bellek ihtiyacı oluşması durumunda 4 soket veya üzeri bir sunucu seçilmesi gerekiyor. Sunucu tarafındaki işlemci/bellek oranı kısıtlamalarından dolayı donanım yatırımı yapılırken bu sunucuların maksimum büyüyebilecekleri bellek miktarına göre seçilmesi ve bu seçim yapılırken de gereğinden fazla maliyet oluşmaması için 3-5 yıllık büyüme öngörüsüne göre uygun sunucunun tercih edilmesi gerekiyor. Ancak proje başlangıcında yapılan hesaplamalara göre daha hızlı büyüyen bir SAP sisteminde, öngörülenden daha kısa zaman diliminde kaynak artırımına gitmek durumunda kalabiliriz.

Bu kaynak artırımının birden fazla nedeni olabilir, yanlış ölçeklendirme hesaplaması olabileceği gibi HANA sistemlerinin sağladığı katma değerden dolayı planlananın dışında farklı iş süreçlerinin de devreye alınması gibi durumlar olabilir. Sonuç olarak sunucunun bellek kapasitesini arttırma durumu oluştuğunda mevcut sunucuya ek işlemci ve bellek ilave edebiliyorsak bunu sağlayıp kapasite artırımına gitmemiz gerekiyor fakat maksimum işlemci ve bellek miktarına ulaşıldığı durumlarda ise daha büyük kapasiteli yeni bir sunucu alımına gitmek zorunda kalabiliyoruz. Bundan dolayı şirketler HANA projelerinde kendi veri merkezlerinde barındırma (on-premise) seçeneği yerine HANA Enterpise Cloud (HEC) veya hibrit bulut yapısını sağlayabilen, bünyesinde SAP ve HANA uzmanlığını barındıran GlassHouse Cloud gibi hizmet sağlayıcılar tercih edilmeye başlandı. SAP projelerinde on-premise ile bulut opsiyonlarının detaylı karşılaştırıldığı farklı bir makaleyi de yazacağım.

HANA veritabanı 128 GB gibi çok küçük ölçekli bellek konfigürasyonlarından başlayıp 32 TB hatta çok daha yüksek bellek kapasitesine ihtiyaç duyabilen SAP ortamlarının oluşmasına imkân sağladı, tabii bu kadar büyük kapasitelerin tasarlanması yukarı belirttiğim kısıtlamalardan dolayı zor ve maliyetli olabildiği için SAP tarafından dikey (scale-up) ve yatay (scale-out) mimarilerinin ikisi de desteklenmeye başladı. Kısaca bu mimarileri açıklayacak olursak;
 






Scale-Up

HANA veritabanı tek bir fiziksel sunucu üzerinde çalışmakta olup, HANA veritabanı kapasitesi fiziksel sunucunun maksimum desteklediği (işlemci/bellek) ve SAP tarafından sertifikalanan maksimum kapasitesiyle sınırlı olmaktadır. 8 TB ve üzeri sistemler bazı üreticilerde bulunmadığı için büyük ölçekli sistemlerde bu yapıyı oluşturmak veya kapasitesini arttırmak daha sınırlı olmaktadır.
 






Scale-Out

HANA veritabanı servislerinin birden çok sunucuyu dağıtılarak çalıştırıldığı mimari yapıdır. Örneğin 15 TB'lık tek bir sunucu yerine 3TB'lık 5 adet sunucu olarak aynı hana kapasitesi oluşturulabilir.
 



İlk bakışta scale-out çözümü daha uygun görünse de kurulum ve yönetim kısmında daha fazla efor gerektiren bir çözüm olarak karşımıza çıkıyor. Ayrıca bu mimari yakın zamana kadar SAP BW, SAP CAR gibi spesifik belli başlı ürünleri destekmekteydi, kısa bir süre önce S/4HANA ‘nın scale-out altyapı desteği duyuruldu. S/4HANA sistemlerinin scale-out mimarisinde çalıştırılması konusunda hem tasarım hem de kurulum adımlarını içeren detaylı bir yazı daha paylaşıyor olacağım.

 

Peki hangi SAP ürünlerinde ne zaman scale-out mimarisini düşünmeye başlayabiliriz?

BW ve CAR gibi sistemlerde, HANA veritabanı çok hızlı büyüyor ve 3-5 yıl içerisinde tek bir sunucu ile bu kadar büyük kapasiteyi oluşturamayacağımızı öngörüyorsak o zaman scale-out bizim için bir opsiyon olabilir. Her yıl 3TB büyüyen bir sistemi ele alırsak 5 yıllık öngörümüzde 15 TB olacak bir sistem için 1 yıldan 15TB'lık bir sunucu almak yerine ilk aşamada 4 adet 1 TB'lık sunucu ile scale-out yapısını oluşturup sonra sistemin her büyüme ihtiyacı olduğunda 1 TB'lık yeni sunucuları ekleyerek sistem kapasitesini arttırabilir ve ilk yatırım maliyetini düşürebiliriz.

S/4HANA sisteminde scale-out desteği neyi geldiği için buradaki kısıtlamalar biraz daha fazla diyebiliriz. Şu anda en fazla 4 tane aktif node desteklenmektedir ve her bir node'un kapasitesi en az 8 Core 6TB bellek olmalıdır. Bu aşamada scale-out yapısına geçmeyi gerektirecek firma sayısı sınırlı olacaktır. S/4HANA sistemlerinin geçmişi birkaç yıl öncesine dayandığı için bu kadar büyük verileri oluşturacak sistemler henüz oluşmadı, bazı büyük hacimli şirketlerde yeni yeni oluşuyor. Zamanla hem bu kısıtlamaların azalacağını hem de veritabanının büyüyeceğini göz önüne alırsak birkaç sene sonra S/4HANA Scale-out projelerinin daha yaygın olacağını düşünüyorum.

Linkler;

Certified and Supported SAP HANA Hardware

SAP S/4HANA - Multi-Node Support

 

Ümit Toptaş
GlassHouse SAP Presales Mühendisi
 

Detaylı bilgi almak için sizi aramamızı ister misiniz?

Bilgi Merkezi İçerikleri

Blog Yazıları

Bu site; deneyiminize yardımcı olmak, ürünlerimizi ve hizmetlerimizi kullanımınızı analiz etmek, tanıtım ve pazarlama çalışmalarımıza yardımcı olmak ve üçüncü taraflardan içerik sağlamak için çerezleri ve diğer izleme teknolojilerini kullanır. Daha fazlasını öğrenmek için: Gizlilik Politikamız | Çerez Politikamız