S/4 HANA Sizing
SAP projelerinde önemli bir maliyet kalemi de S/4 Hana Sizing( Sunucu boyutlandırma).Özellikle yerli ve on premise ERP kullanan firmalar, SAP‘ye geçerken mevcut sunucu kaynaklarını SAP uygulama ve veri tabanında kullanmak isterler. HANA veri tabanı ile artık bu teknik olarak pek mümkün olmasa da, mevcut makine parkurundaki sunucular SAP uygulama sunucusu (Application server) olarak kullanıldığını görüyoruz. Tabii ki firmaya ve SAP kullanımına göre değişiklik gösterse de, asıl SAP donanım yatırımı HANA tarafında. Çünkü Hana on Memory olduğudan, yüksek bir memory kullanımı söz konusu. Örnek vermek gerekirse, Uygulama sunucularında 2 adet 96 GB Ram ve 16 Core bir server kullanıyorken, aynı altyapıda 512 GB RAM HANA tarafında yetersiz kalabilmektedir. Hana’nın yedeğinini de düşününce bu kapasite iyice büyümekte ve şirkete olan maliyetini arttırmaktadır.
Yukarıda belirtildiği gibi bu rakamlar sadece bir örnek ve tabii ki firmadaki kullanıcı sayısına ve kullanılan süreç, oluşturulan belgeler gibi bir çok parametreye bağlı. SAP’de bu konuda aslında bir sizing bilgisi veriyor, aşağıdaki linkten ulaşılabilir.
https://www.sap.com/about/benchmark/sizing.html
https://www.sap.com/about/benchmark/sizing.quick-sizer.html#quick-sizer
Projelerde canlı öncesi SAP tarafından iletilen ve müşteriler tarafından doldurulan bir sizing dokümanı olsa da, bu tarz öngörüye dayanan işlemlerde her zaman hata payı vardır. Özellikle bazı süreçlerin değiştiği ve SAP’de yerli ERP’lere göre oldukça fazla belge oluşturulmasından dolayı doğru sizing yapmak oldukça zor. Örnek vermem gerekirse, 2 uygulama sunucusu ile canlıya geçilen bir firmada 1 ay içinde 5-6 tane ek uygulama sunucusu daha eklenmişti. HANA RAM tarafında da bu sürede önce 2 katına, sonra bir kat daha ekleme yapılarak 3 katına çıkıldı. Canlının üçüncü yılında HANA kaynağı başlangıçtakinin 6 katına çıkarılmak durumunda kalındı. Uygulama sunucuları da 15 civarındaydı.
Uygulama tarafındaki sizing ve optimizasyon için farklı görüş ve uygulamalar var. Bazı yöneticiler yatayda büyümek isterken( fazla sayıda uygulama sunucusu gibi), bazıları ise az ama güçlü sunucularla dikeyde büyümek isterler. Burada da kesin bir doğru olmamakla birlikte, şahsi kanaatim yatayda büyümenin, bir sunucuda sorun olduğunda diğerlerinde hızlıca devam edilebilmesi ve daha az proses ve iş gücü kaybı getireceğinden bence daha doğru olduğu yönünde.Dikeyde büyümenin riski, bir sunucuda sorun olduğunda çok fazla kaynak kaybı yaşatmasıdır.
Konu hakkında başka yazı için
