SAP sistemlerini Microsoft Azure'a geçirme stratejilerini analiz etme
SAP iş yüklerini Azure'a dağıtmayı düşünen müşterilerin çoğunluğunun mevcut bir şirket içi SAP uygulaması vardır. Yeşil alan dağıtımlarının sayısı nispeten azdır.
Kuruluşlar genellikle kurumsal kaynak planlama (ERP), küresel ticaret, iş zekası (BI) ve diğerleri gibi iş işlevleri için SAP sistemlerine sahiptir. Bu sistemlerin içinde korumalı alan, geliştirme, test ve üretim gibi ortamlar bulunur.
Yukarıdaki şekildeki her yatay satır bir ortamdır. Her sütun, bir iş işlevine (erp ve BI gibi) yönelik bir SAP sistemidir.
Alttaki satırlar veya katmanlar daha düşük riskli ortamlardır ve daha az kritiktir. En üste doğru olanlar daha yüksek risk ve daha kritiktir. Yığın yukarı doğru ilerlerken geçiş işleminde daha fazla risk vardır. Dolayısıyla üretim en kritik ortamdır ve iş sürekliliği için de kullanılan kullanıcı kabul testi (Test) ortamı ise en kritik ikinci ortamdır.
Alttaki sistemler daha küçüktür, bu nedenle daha az bilgi işlem kaynağına, daha düşük kullanılabilirlik ve boyut gereksinimlerine ve daha az aktarım hızına sahiptir. Ancak, üretim veritabanıyla aynı miktarda depolama alanına sahiptirler.
Yatay strateji
Yatay bir stratejiyle, Azure'da denemeler yapmak ve deneyim kazanmak için güvenli bir yol olduğundan yığının en altından başlarsınız. Ayrıca işletimsel, dağıtım ve onay süreçlerinizi yeniden tanımlarken kullanmak için iyi bir stratejidir. Siz Azure'a geçtikçe bu işlemler değişecektir. Strateji şu şekilde çalışır:
- Riski sınırlamak için düşük etkili korumalı alan veya eğitim sistemleriyle başlayın. Bir sorun olursa, çok az sayıda kullanıcıyı veya görev açısından kritik iş işlevlerini etkileme tehlikesi vardır.
- Ardından Azure'da SAP sistemlerini çalıştırma, barındırma ve yönetme konusunda deneyim kazandıkça öğrendiklerini yığının üst kısmındaki bir sonraki sistem katmanına uygulayın.
- Her katman için maliyetleri, tasarruf eden olası parayı, performansı ve iyileştirme potansiyelini tahmin edin ve gerekirse ayarlayın.
Dikey strateji
Azure'daki üretim sistemleriyle ilgili deneyim kazanmak için, yatay stratejiye paralel olarak düşük riskli sistemlerle dikey bir strateji kullanabilirsiniz. Bu, Azure için iç süreçleri ayarlama ve ekip üyelerini eğitma fırsatı da sunar. Üretimdeki sorunları erken fark etmek için harika bir yoldur. Strateji şu şekilde çalışır:
- Maliyet, müşteriler, hizmet düzeyi sözleşmeleri (SLA) ve yasal gereksinimler üzerindeki etkisine bakın. İlk olarak, en düşük riski olan sistemleri (korumalı alandan üretime) taşıyın: idare, risk ve uyumluluk sistemi ve ardından nesne olay deposu (OER) sistemi. Ardından, BI ve ERP gibi daha yüksek riskli olanları taşıyın.
- Yeni bir SAP sisteminiz olduğunda, şirket içine yerleştirmek ve daha sonra taşımak yerine varsayılan olarak Azure'da başlayın. Diyagramda, OER bunun bir örneğidir. OER yeni ve düşük riskli bir sistemdir. Diğer sistemlerimizden bazılarını yatay stratejiyle Azure'a taşıdıktan sonra, OER dikey yığınının tamamını korumalı alandan üretime kadar uçtan uca Azure'a dağıtabilirsiniz.
- Önce en kritik sisteminizi hareket ettirmeyin. Taşıdığınız son sistem, en yüksek risk, en görev açısından kritik sistem olan ERP üretim sistemidir. Performans açısından en yoğun sanal makine SKU'ları ve en büyük depolama alanı gerekir.
- Önce tek başına sistemleri taşıyın. Bazı sistemler, ERP ve GTS sistemleri gibi diğer sistemlerle yakından birleştirilir. İkisi arasında çok fazla zaman uyumlu, gerçek zamanlı trafik var. ERP'yi Azure'a taşır ancak GTS'yi şirket içinde tutarsanız, ağ gecikme süresi nedeniyle performansı etkiler; bu nedenle bunları birlikte taşıyın.
- Birkaç SAP sisteminiz varsa, bir SAP sisteminden diğerine veya SAP'den SAP ekosistemi dışındaki uygulamalara yukarı ve aşağı akış bağımlılıklarını arayın. Gecikme süresine karşı yüksek hassasiyete sahip trafik desenlerini ve alanlarını inceleyin.
- Sıkı bir şekilde bağlı sistemleriniz varsa, taşımanın hangi etkiyi oluşturacağını görmek için bir performans analizi yapın. Çok fazla etki yoksa, bunları ayrı olarak Azure'a (örneğin ERP'nin bağımsız Business Warehouse'u) taşıdınız. Aksi takdirde, geçiş grupları oluşturun ve bunları birlikte taşıdık.
- Bazı durumlarda beklemeyi göz önünde bulundurun. Bazen belirli sistemleri hemen Azure'a taşımak istemezsiniz. Bu, işleme gereksinimleri sanal makinelerin henüz yeterince büyük olmadığı kadar yüksek olduğunda boyutlandırma gereksinimleriyle ilgili olabilir. Bu sistemleri taşımanın müşterilerle birlikte SLA'ları etkilemediğinden emin olmak için testler çalıştırın.