Yoksa mümkün mü? Elbette SAP sistemlerinin taşınması karmaşık ve zahmetli bir süreçtir ve başarısı tüm katılımcıların iyi koordine edilmiş çalışmasını gerektirir. Ve eğer geçiş kısa sürede gerçekleşirse iş çok daha karmaşık hale geliyor. Herkes bunu yapmaya karar vermez. Birkaç nedeni olabilir. Örneğin sürecin kendisi uzun ve organizasyonel açıdan karmaşıktır. Ayrıca planlanmamış sistem kesintisi riski de vardır. Veya müşteriler böyle bir operasyon geçirdikten sonra harcanan çabayla orantılı faydalar alacaklarından emin değiller. Ancak istisnalar da var.
Kesimin altında, müşterilerin SAP sistemlerini taşıma ve sürdürme sürecinde karşılaştığı zorluklardan bahsedeceğiz, stereotiplerin neden her zaman gerçeklikle örtüşmediğini tartışacağız ve bir müşterinin sistemlerini yeni bir sürüme nasıl geçirmeyi başardığımıza dair bir örnek olay çalışmasını paylaşacağız. üç aydan biraz uzun bir süre içinde yeni altyapı.
SAP sistemleri barındırma
Sadece beş yıl önce, müşterilerin SAP uygulamaları için barındırma kaynaklarını yoğun bir şekilde kullanmaya başlayacağını hayal etmek zordu. Çoğu durumda bunlar şirket içinde uygulandı. Ancak dış kaynak kullanımı modellerinin ve bulut hizmetleri pazarının gelişmesiyle birlikte müşterilerin dünya görüşü değişmeye başladı. SAP için bulut lehine seçimi etkileyen argümanlar nelerdir?
- SAP'yi yeni uygulamayı planlayan yeni başlayanlar için bulut altyapısı neredeyse standart bir seçimdir - kaynakların sistemin mevcut ihtiyaçlarına göre ölçeklenebilirliği ve kaynakları temel olmayan yetkinliklerin geliştirilmesine yönlendirme konusundaki isteksizlik.
- Geniş bir sistem ortamına sahip şirketlerde, SAP sistemlerini barındırmanın yardımıyla CIO'lar, niteliksel olarak farklı bir risk yönetimi düzeyine ulaşırlar, çünkü İş ortağı SLA'dan sorumludur.
- Üçüncü en yaygın argüman, yüksek kullanılabilirlik ve DR senaryolarını uygulamaya yönelik altyapı oluşturmanın yüksek maliyetidir.
- Faktör 2027 – satıcı, 2027'de eski sistemlere yönelik desteğin sona ereceğini duyurdu. Bu, veritabanının HANA'ya aktarılması anlamına gelir; bu da modernizasyon maliyetlerini ve yeni bilgi işlem gücünün satın alınmasını gerektirir.
Rusya'daki SAP barındırma pazarının artık oldukça olgun olduğu düşünülebilir. Bu da hosting platformlarını değiştirmek isteyen müşterilere geniş bir fırsat sunuyor. Ancak bu tür projeler, geçiş prosedürünün karmaşıklığı nedeniyle işletmeler arasında haklı olarak endişeye neden olabilir. Bu durum, müşterileri, yalnızca SAP sistemlerinin barındırılması ve bakımı konusunda olağanüstü yetkinliklere sahip olması değil, aynı zamanda geçiş alanında başarılı deneyime sahip olması gereken hizmet sağlayıcılardan daha fazla talepte bulunmaya zorluyor.
SAP hostingi değiştirmenin zorlukları nelerdir?
Hostingler farklıdır. Beyan edilen hizmet düzeyiyle tutarsızlık, küçük metinlerde rezervasyonlarla birlikte birçok "ama" ve yıldız işareti, barındırma sağlayıcısının sınırlı kaynakları ve yetenekleri, müşteriyle iletişim konularında esneklik eksikliği, bürokrasi, teknik sınırlamalar, teknik desteğin düşük yeterliliği uzmanlar ve diğer birçok nüans - bunlar, müşterilerin iş sistemlerini dış kaynak altyapılarında çalıştırırken karşılaşabilecekleri tuzakların sadece küçük bir kısmı. Çoğu zaman müşteri için tüm bunlar gölgede, çok sayfalı bir sözleşme ormanında kalır ve hizmetleri kullanma sürecinde ortaya çıkar.
Bir noktada müşteri, aldığı hizmet düzeyinin beklentilerinden uzak olduğunu anlıyor. Bu, durumu düzeltmek için çözümler bulmak için bir tür katalizördür ve başarısızlık durumunda, sorunlar sınıra ulaştığında ve çok acı verici hale geldiğinde, hizmet sağlayıcıyı değiştirme yönünde alternatif seçenekler geliştirmek için aktif eylemlere geçerler. .
Neden son dakikaya kadar bekliyorlar? Bunun nedeni basit; istemciler için sistemleri taşıma süreci her zaman şeffaf ve anlaşılır değildir. Müşterinin geçiş süreciyle ilişkili gerçek riskleri değerlendirmesi zordur. Müşteriler için geçişin bir tür kara kutu olduğunu söyleyebiliriz: Fiyat, sistem kesintisi, riskler ve bunların nasıl azaltılacağı belirsizdir ve genel olarak karanlık ve korkutucudur. Sanki işe yaramazsa, hem zirvede hem de sanatçılarda kafalar yuvarlanacak.
SAP, kurumsal düzeyde bir sistemdir, karmaşıktır ve en hafif deyimle ucuz değildir. Bunların uygulanması, değiştirilmesi ve bakımı için makul bütçeler harcanır ve işletmenin ömrü bunların kullanılabilirliğine ve doğru çalışmasına bağlıdır. Şimdi büyük bir üretimi durdurmanın sonuçlarını hayal edin. Bunlar, çok sayıda sıfırla hesaplanabilen mali kayıpların yanı sıra itibar ve diğer eşit derecede önemli risklerdir.
Müşterilerimizden birinden SAP sistemlerinin taşınması durumunda ortaya çıkabilecek zorlukları her aşamada analiz edeceğiz.
Hazırlık ve tasarım
Göç, birçok farklı parçadan oluşan bir formüldür. Ve en önemlilerinden biri de hedef (yeni) altyapının tasarlanması ve hazırlanması aşamasıdır.
Sistemlerin mevcut uygulamalarına, mimarilerine dalmamız gerekiyordu. Hedef altyapıda mevcut çözümleri bir yerde tekrarladık, bazı noktalarda takviye ve iyileştirmeler yaptık, bir yerlerde yeniden düzenledik, hata toleransı ve kullanılabilirliği sağlayacak çözümleri düşündük ve seçtik, ayrıca tüm kaynakları mümkün olduğunca konsolide ettik.
Tasarım süreci sırasında birçok farklı alıştırma gerçekleştirildi ve bu da sonuçta geçiş için mümkün olduğunca hazırlanmayı ve her türlü nüansı ve tuzağı hesaba katmayı mümkün kıldı (bunlar hakkında daha sonra detaylı bilgi verilecektir).
Sonuçta veri merkezimizi temel alan, ayrı ayrı tasarlanmış özel bir bulut altyapısı elde ettik:
- SAP HANA için özel fiziksel sunucular;
- Uygulama sunucuları ve altyapı hizmetleri için VMware sanallaştırma platformu;
- L2 VPN için veri merkezleri arasında çoğaltılmış iletişim kanalları;
- ürünü ve "diğer her şeyi" ayırmak için iki ana depolama sistemi;
- Ayrı bir sunucu, disk rafı ve teyp kitaplığına sahip Veritas Netbackup tabanlı SRC.
Teknik açıdan tüm bunları şu şekilde uyguladık.
SAP
- Üretken HANA için depolamayı etkili bir şekilde kullanmak amacıyla, SAP kullanarak sistemik veritabanı çoğaltması olmadan paylaşılan diskler kullandık. Tüm bunlar, Pacemaker'ı temel alan Aktif Beklemeli SUSE HAE kümesinde yer alıyordu. Evet, kurtarma süresi replikasyona göre biraz daha uzundur ancak depolama alanından yarı yarıya tasarruf ediyoruz ve bunun sonucunda müşterinin bütçesinden tasarruf ediyoruz.
- Üretim öncesi ortamlarda HANA kümeleri terk edildi ancak teknik olarak üretim yapılandırması tekrarlandı.
- Test ve geliştirme ortamları, bir MCOS yapılandırmasında kümeler olmadan birkaç sunucuya daha dağıtıldı.
- Tüm uygulama sunucuları sanallaştırıldı ve VMware'de barındırıldı.
Сети
- Kontrol ve üretim ağlarının hatlarını anahtar yığınlarıyla fiziksel olarak ayırdık ve üretken olanları müşterinin veri merkezlerine doğru çevirdik.
- Büyük trafik akışlarını karıştırmamak için yeterli sayıda ağ arayüzü kurduk.
- Depolama sistemlerinden veri aktarmak için klasik FC SAN fabrikaları yaptık.
Depolamak
- SAP'nin üretken ve üretim öncesi yükü tamamen flash dizide kaldı.
- Geliştirici test ortamları ve altyapı hizmetleri ayrı bir hibrit diziye yerleştirildi.
IBS, İrritabl Barsak Sendromu
- Veritas Netbackup kullanılarak yapılmıştır.
- MCOS yapılandırmalarını yedeklemek için yerleşik komut dosyalarına biraz ekledik.
- Hızlı kurtarma için operasyonel kopyaları bir disk rafına koyarız ve uzun süreli depolama için bantlar kullanırız.
İzleme
- Tüm donanım, işletim sistemi ve SAP Zabbix altında kuruldu.
- Grafana'da birçok yararlı gösterge tablosu topladık.
- Bir uyarı oluştuğunda Zabbix, olay yönetimi sisteminde bir talep oluşturabilir; bunu Jira'ya uyguladık. Bilgiler Telegram kanalında da kopyalanıyor.
Telegram
HANA'nın genel sağlığı
SAP Uygulama Sunucusu Durumu:
Altyapı hizmetleri
- Dahili ad alanlarına hizmet vermek için müşterinin sunucularıyla senkronize edilen bir DNS sunucuları kümesi oluşturuldu.
- Veri alışverişi için ayrı bir dosya sunucusu oluşturduk.
- Çeşitli konfigürasyonları saklamak için Gitlab eklendi.
- Çeşitli Hassas bilgiler için HashiCorp Kasasını aldık.
Taşıma işlemi
Genel olarak geçiş süreci aşağıdaki aşamalardan oluşur:
- gerekli tüm proje belgelerinin hazırlanması;
- mevcut sağlayıcıyla müzakereler - organizasyonel sorunların çözülmesi;
- proje için yeni ekipmanların satın alınması, teslimatı ve kurulumu;
- geçiş ve işlem hata ayıklamasını test edin;
- sistem aktarımı, göçle mücadele.
Ekim 2019 sonunda sözleşme imzaladık, mimarisini tasarladık ve müşteriyle anlaştıktan sonra gerekli ekipmanların siparişini verdik.
Öncelikle dikkat etmeniz gereken ekipmanın teslim süresidir. Yazılım üreticisinin donanım platformlarına yönelik gereksinimlerini karşılayan SAP NAHA sertifikalı donanımın teslimatı ortalama 10-12 hafta sürer. Ve mevsimsellik dikkate alındığında (projenin uygulanması tam olarak Yeni Yıla denk geldi), bu süre bir ay daha artabilirdi. Buna göre süreci olabildiğince hızlandırmak gerekiyordu: Distribütör-tedarikçi ile çalıştık ve uçakla (kara ve deniz yolları yerine) hızlandırılmış teslimat konusunda anlaştık.
Kasım ve Aralık ayları göçe hazırlanmak ve ekipmanların bir kısmını almakla geçti. Hazırlığı genel bulutumuzdaki bir test tezgahında gerçekleştirdik; burada tüm ana adımları inceledik ve olası zorlukları ve sorunları tespit ettik:
- proje ekibi üyeleri arasındaki etkileşim için dakika dakika zamanlamalarla ayrıntılı bir plan hazırladı;
- veritabanı ve uygulama sunucuları için hedef altyapıdakiyle hemen hemen aynı şekilde bir test tezgahı oluşturuldu;
- entegrasyonların işleyişini test etmek için gerekli iletişim kanallarını ve altyapı hizmetlerini yapılandırdı;
- geçiş senaryoları üzerinde çalıştı;
- Bulut ayrıca önceden yapılandırılmış sanal makine şablonları oluşturmamıza da yardımcı oldu; bunları daha sonra kolayca içe aktardık ve hedef ortama dağıttık.
Yeni Yıl tatilinden kısa bir süre önce ilk parti ekipman bize ulaştı. Bu, bazı sistemlerin gerçek donanım üzerinde konuşlandırılmasını mümkün kıldı. Her şey gelmediğinden, tedarikçi ve distribütörlerle anlaştığımız yedek ekipmanı bağladık. Son aşamada hedef altyapının kalıntılarını aldık.
Son teslim tarihine yetişmek için mühendislerimiz Yeni Yıl tatillerini feda etmek ve tatillerin ortasında 2 Ocak'ta hedef altyapıyı hazırlamak için çalışmaya başlamak zorunda kaldılar. Evet, bu bazen ateş yakıldığında ve başka seçeneğin olmadığı durumlarda olur. Söz konusu olan, işletmenin yaşamının bağlı olduğu sistemlerin performansıydı.
Genel geçiş sırası şuna benziyordu: ilk olarak en az kritik olan sistemler (geliştirme ortamı, test ortamı), ardından üretken sistemler. Göçün son aşaması Ocak sonu ve Şubat başında gerçekleşti.
Geçiş süreci dakikasına kadar planlandı. Bu, tüm görevlerin, tamamlanma süresinin ve sorumlu kişilerin listesini içeren bir geçiş planıdır. Test geçişinde tüm adımlar zaten hazırlanmıştı, dolayısıyla canlı geçişte planı takip etmek ve süreci koordine etmek yeterliydi.
Göç sistematik olarak birkaç aşamada gerçekleştirildi. Her aşamada iki sistem bulunmaktadır.
Üç aylık bir çalışmanın sonucunda CROC veri merkezinde tamamen çalışır durumda olan bir sistem ortaya çıktı. Genel olarak ekip çalışmasıyla olumlu bir sonuç elde edildi; tüm katılımcıların sürece katkısı ve özverisi maksimum düzeydeydi.
Müşterinin projedeki rolü
Müşterimizin ayrıldığı sağlayıcıyla iletişim kurmak kolay olmadı. Bu anlaşılabilir bir durum; onlar projenin başarılı bir şekilde tamamlanmasıyla ilgilenen kişiler listesindeki son kişilerdi. Müşteri tüm iletişim sorunlarını iletme ve pedal çevirme görevini üstlendi ve bu 100500% ile başa çıktı. Bunun için kendisine özellikle teşekkür ediyorum. Sürece bu kadar makul bir katılım olmasaydı, projenin sonucu tamamen farklı olabilirdi.
Süreçlerin “eski” sağlayıcı tarafında resmileştirilmesi nedeniyle altyapı desteği, o zamanlar hala onların müşterisi olan sorunlardan tam anlamıyla uzak uzmanlar tarafından gerçekleştirildi. Örneğin, aynı veritabanını dışa aktarma işlemi bir saatten beş saate kadar sürebilir. Sonra bunun bir tür sihir, bize asla açıklanmayan bir sır olduğu ortaya çıktı. Muhtemelen teknik destek mühendisleri bu arada meditasyona daldılar, Rusya'nın uzak bir yerinde teslim tarihlerinin olduğunu, mühendislerin yılbaşı salatası olmadığını, müşterinin ağladığını ve acı çektiğini unutuyorlardı...
Projenin sonuçları
Geçişin son adımı sistemlerin bakım için aktarılmasıydı.
Artık müşteri talepleri için tek pencerede hizmet sağlıyoruz ve iş ortağımız itelligence ile birlikte altyapı bileşenlerinin desteklenmesi ve SAP temeline ilişkin tüm görev kapsamını kapsıyoruz. Müşteri altı aydır özel bir bulutta yaşıyor. Bu süre zarfındaki hizmet vakalarına ilişkin istatistikler şunlardır:
- 90 olay (%20'si müşteriyi dahil etmeden çözüldü)
- SLA kapsamında çözümlendi – %100
- Planlanmamış sistem kapanmaları – 0
Müşterimizinkine benzer sorunlarınız varsa ve bunların nasıl çözüleceği hakkında daha fazla bilgi edinmek istiyorsanız, şu adrese yazın: [e-posta korumalı]
Kaynak: habr.com