Kaydet tuşuna basarak bu formda paylaştığınız bilgilerle ilgili olarak Kişisel Verilerin Korunması Kanunu Uyarınca Aydınlatma Metninde yer alan şartları kabul etmiş sayılırsınız.
Kaydet!
1
Kurumsal
Hakkımızda
Referanslar
Markalarımız
Sertifikalar
Hizmetlerimiz
Bizim Bulutumuzdan Verdiğimiz Hizmetler
Back up as a Service Container as a Service Disaster Recovery as a Service Infrastructure as a Service Monitoring as a Service SAPHANA as a Service Security as a Service
Firewall as a Service
SIEM as a Service
Vulnerability Management as a Service
WAF as a Service
IPS as a Service
Loadbalancer as a Service
AntiVirus as a Service
Sizin Veri Merkezinizde Verdiğimiz Hizmetler
Yönetilen Hizmetler
Yönetilen Yedekleme ve FKM Hizmeti
Yönetilen Altyapı Hizmeti
Yönetilen SAP Basis Hizmeti
Dell EMC Veri Merkezi Altyapı Çözümleri
PowerEdge Sunucu Ailesi
Depolama Sistemleri
Yedekleme ve İş Sürekliliği Hizmeti Siber Kurtarma Hizmeti Dış Kaynak Hizmeti VMWare Ürün Ailesi
SAP Hizmetleri
SAP Basis Destek Hizmeti SAP Danışmanlık Hizmeti
Kaynaklar
Bulut Terimleri Sözlüğü
Etkinlikler
Haberler
Blog Yazıları
Başarı Hikayeleri
Bilgi Merkezi
Videolar
Whitepaper & Broşürler
İletişim
Destek English
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?
Adınız
Soyadınız
Firmanız
Ünvan
E-Posta Adresiniz
Telefon Numaranız
Bizimle kurmuş olduğunuz iş ilişkisi kapsamında bizlerle paylaşmış olduğunuz verilerinizi, sizleri ürün ve hizmetlerimizle ilgili bilgilendirmek ve ürünlerimizle ilgili etkinliklerimizden haberdar edebilmek amacıyla işlemekteyiz. Kişisel verilerinizi nasıl işlediğimize ilişkin daha detaylı bilgi ve haklarınız için Kişisel Verilerin Korunması Kanunu Uyarınca Aydınlatma Metninde yer alan aydınlatma metnini inceleyebilirsiniz. Gönder tuşuna basarak bu formda paylaştığınız bilgilerle ilgili olarak Kişisel Verilerin Korunması Kanunu Uyarınca Aydınlatma Metninde yer alan şartları kabul etmiş sayılırsınız.
Gönder
Paylaşın
Bilgi Merkezi İçerikleri
Şirketinizi Korumak, Verilerinizi Korumakla Başlar
Detaylar
How to Leverage Cloud for Your DX Journey | IDC DX Summit, 19 Ekim 2021
Detaylar
Çalışmak için mükemmel bir yer: GlassHouse
Detaylar
Yedekleme Altyapı ve Operasyonunuzu Neden Servis Olarak Almalısınız?
Detaylar
Girişimcinin Dünyası | Hüseyin Bilgen'den Girişimcilere Öneriler
Detaylar
GlassHouse Azure Hibrit Bulut Servisleri ile Her Yerden İnovasyon
Detaylar
Proaktivite'nin yeni adı: Monitoring as a Service hizmetleri
Detaylar
Bulut Çözümlerinin Üretimde ve Enerjide Sürekliliğe Etkisi
Detaylar
Dijital Dönüşüm Neleri Değiştirdi?
Detaylar
IDC Financial Services Summit 2021
Detaylar
Siber Kurtarma, Yedekleme ve Felaket Kurtarma ile iş sürekliliğinde sinerjiyi yakalamak
Detaylar
Dijital Dönüşümün Anahtarı: Konteyner Teknolojileri
Detaylar
Tümünü göster
Blog Yazıları
Kubernetes Platformu Seçiminde Dikkat Edilmesi Gerekenler
Kubernetes Platformu Seçiminde Dikkat Edilmesi Gerekenler
Detaylar
Başarılı bir Kubernetes Stratejisi Nasıl Oluşturulur?
Başarılı bir Kubernetes Stratejisi Nasıl Oluşturulur?
Detaylar
Bulut Bilişimin Beş Temel Özelliği ve Türkiye'nin İhtiyacı Olan Altıncı Özellik
Bulut Bilişimin Beş Temel Özelliği ve Türkiye'nin İhtiyacı Olan Altıncı Özellik
Detaylar
HANA SCALE-OUT TASARIMI
HANA SCALE-OUT TASARIMI
Detaylar
HANA Sistemlerinin Ölçeklendirilmesi
HANA Sistemlerinin Ölçeklendirilmesi
Detaylar
Yazılım Tabanlı Tekilleştirmenin Toplam Sahip Olma Maliyetine Etkileri -2
Yazılım Tabanlı Tekilleştirmenin Toplam Sahip Olma Maliyetine Etkileri -2
Detaylar
Yedekleme Verilerimiz Güvende mi?
Yedekleme Verilerimiz Güvende mi?
Detaylar
Yazılım Tabanlı Tekilleştirmenin Toplam Sahip Olma Maliyetine Etkileri -1
Yazılım Tabanlı Tekilleştirmenin Toplam Sahip Olma Maliyetine Etkileri -1
Detaylar
Intel QAT Teknolojisi ve Yeni Nesil Power Protect Data Domain Sistemlerine Etkileri
Intel QAT Teknolojisi ve Yeni Nesil Power Protect Data Domain Sistemlerine Etkileri
Detaylar
2020 Yılı Sonunda Hangi SAP Ürünlerinin Desteği Kalkıyor?
2020 Yılı Sonunda Hangi SAP Ürünlerinin Desteği Kalkıyor?
Detaylar
SAP Sistemleri Yönetim Hizmetleri (SAP BASIS)
SAP Sistemleri Yönetim Hizmetleri (SAP BASIS)
Detaylar
Tümünü göster
Copyright 2021 © GlassHouse Türkiye
Kurumsal
Hakkımızda
Referanslar
Markalarımız
Sertifikalar
GlassHouse Cloud
GlassHouse Cloud Stratejisi
Container as a Service
Backup as a Service
Disaster Recovery as a Service
Infrastructure as a Service
Monitoring as a Service
SAP HANA as a Service
Hizmetler
Yönetilen Hizmetler
Yönetilen Yedekleme ve FKM
Yönetilen Altyapı
Yönetilen SAP Basis
SAP Hizmetleri
SAP Basis Destek Hizmetleri
SAP Danışmanık Hizmetleri
SAP Solution Manager Hizmetleri
Dış Kaynak Hizmeti
Çözümler
Veri Koruma Çözümleri
Dell Technologies Ürün Ailesi
PowerEdge Sunucu Ailesi
Depolama Sistemleri
VMware Ürün Ailesi
Siber Kurtarma Çözümleri
Kaynaklar
Bulut Terimleri Sözlüğü
Etkinlikler
Haberler
Blog Yazıları
Başarı Hikayeleri
Bilgi Merkezi
İletişim
Kişisel Veri Açık Rıza Metni
Kişisel Verilerin Korunması Kanunu Uyarınca Aydınlatma Metni
Istanbul - Vadistanbul 2A Ofis Kat: 6 D: 51 Ayazağa / İstanbul +90 212 360 15 55 | +90 850 885 01 75
Ankara - eOfis, Koç İkiz Kuleleri, Söğütözü Cad. No:2, Ankara +90 312 945 04 94 | +90 850 885 01 75
Johannesburg, South Africa - Office #51, Corner Main & Sloane Street Bryanston, The Campus, Ground Floor, Twickenham Building, Johannesburg, Gauteng, 2021 +27 011 575 4201 - Fax +27 011 576 6000