تجربه تغییر میزبانی SAP: چگونه می توان سیستم ها را بدون اینکه به شدت دردناک باشد مهاجرت کرد

یا امکانش هست؟ البته مهاجرت سیستم های SAP فرآیندی پیچیده و پر دردسر است که موفقیت آن مستلزم کار هماهنگ همه شرکت کنندگان است. و اگر مهاجرت در زمان کوتاهی انجام شود، کار بسیار پیچیده تر می شود. همه تصمیم نمی گیرند این کار را انجام دهند. ممکن است دلایل مختلفی وجود داشته باشد. به عنوان مثال، خود این فرآیند طولانی و از نظر سازمانی پیچیده است. به علاوه خطر خرابی سیستم برنامه ریزی نشده وجود دارد. یا مشتریان مطمئن نیستند که با انجام چنین عملیاتی، مزایایی متناسب با تلاش‌های انجام شده دریافت خواهند کرد. با این حال، استثناهایی وجود دارد.

در زیر برش، در مورد مشکلاتی که مشتریان در فرآیند مهاجرت و حفظ سیستم های SAP با آن مواجه هستند صحبت خواهیم کرد، بحث خواهیم کرد که چرا کلیشه ها همیشه با واقعیت مطابقت ندارند، و یک مطالعه موردی در مورد اینکه چگونه توانستیم سیستم های مشتری را به یک سیستم انتقال دهیم، به اشتراک خواهیم گذاشت. زیرساخت های جدید در کمتر از سه ماه

میزبانی سیستم های SAP

فقط پنج سال پیش، تصور اینکه مشتریان به طور گسترده شروع به استفاده از منابع میزبانی برای برنامه های SAP کنند، دشوار بود. در بیشتر موارد آنها در محل اجرا شدند. با این حال، با توسعه مدل های برون سپاری و بازار خدمات ابری، جهان بینی مشتریان شروع به تغییر کرد. چه استدلال هایی بر انتخاب به نفع ابر برای SAP تأثیر می گذارد؟

• برای مبتدیانی که به تازگی برای پیاده سازی SAP برنامه ریزی کرده اند، زیرساخت ابری تقریباً یک انتخاب استاندارد است - مقیاس پذیری منابع برای نیازهای فعلی سیستم و عدم تمایل به انحراف منابع به سمت توسعه شایستگی های غیر اصلی.
• در شرکت هایی با چشم انداز سیستم بزرگ، با کمک میزبانی سیستم های SAP، CIOها به سطح کیفی متفاوتی از مدیریت ریسک می رسند، زیرا شریک مسئول SLA است.
• سومین استدلال رایج، هزینه بالای ساخت زیرساخت برای اجرای سناریوهای دسترسی بالا و DR است.
• Factor 2027 – فروشنده پایان پشتیبانی از سیستم های قدیمی را در سال 2027 اعلام کرد. این به معنای انتقال پایگاه داده به HANA است که مستلزم هزینه های نوسازی و خرید قدرت محاسباتی جدید است.

بازار میزبانی SAP در روسیه اکنون می تواند کاملا بالغ در نظر گرفته شود. و این فرصت کافی را برای مشتریانی که می خواهند پلتفرم میزبانی خود را تغییر دهند، فراهم می کند. با این حال، چنین پروژه هایی به درستی می توانند به دلیل پیچیدگی روند مهاجرت، نگرانی در بین مشاغل ایجاد کنند. این امر مشتریان را وادار می کند تا تقاضاهای افزایش یافته ای را برای ارائه دهندگان خدمات ایجاد کنند، که نه تنها باید شایستگی های استثنایی در میزبانی و نگهداری سیستم های SAP داشته باشند، بلکه باید تجربه موفقی در زمینه مهاجرت داشته باشند.

مشکلات تغییر میزبانی SAP چیست؟

هاست ها متفاوت هستند. عدم تطابق با سطح اعلام شده خدمات، "اما" و ستاره های زیاد با رزرو در متن کوچک، محدودیت منابع و قابلیت های ارائه دهنده هاست، عدم انعطاف پذیری در مسائل ارتباطی با مشتری، بوروکراسی، محدودیت های فنی، صلاحیت پایین پشتیبانی فنی متخصصان، و همچنین بسیاری از نکات ظریف دیگر - اینها تنها بخش کوچکی از مشکلاتی است که مشتریان ممکن است در هنگام بهره برداری از سیستم های تجاری خود در زیرساخت های برون سپاری با آنها مواجه شوند. اغلب، برای مشتری، همه اینها در سایه، در جنگل یک قرارداد چند صفحه ای باقی می ماند و در فرآیند استفاده از خدمات ظاهر می شود.

در برخی موارد برای مشتری آشکار می شود که سطح خدماتی که دریافت می کند با انتظارات او فاصله دارد. این نوعی کاتالیزور برای یافتن راه‌حل‌هایی برای اصلاح وضعیت است و در صورت شکست، وقتی مشکلات تا حد انباشته می‌شوند و بسیار دردناک می‌شود، به سمت اقدامات فعال برای توسعه گزینه‌های جایگزین در جهت تغییر ارائه‌دهنده خدمات می‌روند. .

چرا تا آخرین لحظه منتظر می مانند؟ دلیل آن ساده است - فرآیند مهاجرت سیستم برای مشتریان همیشه شفاف و قابل درک نیست. ارزیابی خطرات واقعی مرتبط با فرآیند مهاجرت برای مشتری دشوار است. می توان گفت که مهاجرت برای مشتریان نوعی جعبه سیاه است: نامشخص است، قیمت، خرابی سیستم، خطرات و نحوه کاهش آنها، و به طور کلی تاریک و ترسناک است. مثل این است که اگر نتیجه ندهد، سرها هم در بالا و هم روی اجراکنندگان می چرخند.

SAP یک سیستم در سطح سازمانی است، پیچیده و، به زبان ساده، ارزان نیست. بودجه های مناسبی صرف اجرا، اصلاح و نگهداری آنها می شود و عمر شرکت به در دسترس بودن و عملکرد صحیح آنها بستگی دارد. حالا عواقب توقف تولید بزرگ را تصور کنید. این‌ها زیان‌های مالی هستند که می‌توان آن‌ها را با اعداد با تعداد زیادی صفر و همچنین خطرات اعتباری و سایر خطرات به همان اندازه قابل محاسبه بود.

ما مشکلاتی را که ممکن است در هر مرحله در مورد مهاجرت سیستم های SAP از یکی از مشتریانمان ایجاد شود، تجزیه و تحلیل خواهیم کرد.

آماده سازی و طراحی

مهاجرت یک فرمول با بخش های مختلف است. و یکی از مهمترین آنها مرحله طراحی و آماده سازی زیرساخت هدف (جدید) است.

ما نیاز داشتیم که به پیاده سازی موجود سیستم ها، معماری آنها بپردازیم. در زیرساخت هدف، راه‌حل‌های موجود را در جایی تکرار کردیم، در برخی نقاط آن‌ها را تکمیل و بهبود دادیم، در جایی دوباره آن‌ها را اصلاح کردیم، برای اطمینان از تحمل خطا و در دسترس بودن راه‌حل‌ها را اندیشیدیم و انتخاب کردیم، و همچنین تمام منابع را تا حد امکان ادغام کردیم.

در طول فرآیند طراحی، تمرینات مختلف زیادی انجام شد که در نهایت این امکان را فراهم کرد که تا حد امکان برای مهاجرت آماده شوید و انواع تفاوت‌ها و مشکلات را در نظر بگیرید (در ادامه در مورد آنها بیشتر توضیح خواهیم داد).

چیزی که ما به آن رسیدیم یک زیرساخت ابر خصوصی طراحی شده بر اساس مرکز داده ما است:

• سرورهای فیزیکی اختصاصی برای SAP HANA؛
• پلت فرم مجازی سازی VMware برای سرورهای برنامه و خدمات زیرساخت.
• کانال های ارتباطی تکراری بین مراکز داده برای L2 VPN.
• دو سیستم ذخیره سازی اصلی برای جداسازی محصول و "همه چیز دیگر"؛
• SRC مبتنی بر Veritas Netbackup با سرور جداگانه، قفسه دیسک و کتابخانه نوار.

و در اینجا نحوه اجرای همه اینها از نقطه نظر فنی است.

SAP

• برای استفاده موثر از فضای ذخیره سازی برای HANA مولد، از دیسک های مشترک بدون تکرار پایگاه داده سیستمیک با استفاده از SAP استفاده کردیم. همه اینها در یک خوشه SUSE HAE فعال در حالت آماده به کار بر اساس Pacemaker قرار گرفتند. بله، زمان بازیابی کمی بیشتر از تکرار است، اما ما در فضای ذخیره سازی به نصف صرفه جویی می کنیم و در نتیجه در بودجه مشتری صرفه جویی می کنیم.
• در محیط های پیش تولید، خوشه های HANA کنار گذاشته شدند، اما از نظر فنی پیکربندی تولید تکرار شد.
• محیط های آزمایش و توسعه در چندین سرور دیگر بدون خوشه در یک پیکربندی MCOS توزیع شدند.
• تمام سرورهای برنامه مجازی سازی شده و در VMware میزبانی می شوند.

شبکه

• ما به طور فیزیکی خطوط شبکه های کنترل و تولید را با پشته های سوئیچ جدا کردیم و شبکه های مولد را به سمت مراکز داده مشتری چرخاندیم.
• ما تعداد کافی رابط شبکه را نصب کردیم تا جریان های ترافیکی زیاد را با هم مخلوط نکنیم.
• برای انتقال داده ها از سیستم های ذخیره سازی، کارخانه های کلاسیک FC SAN را ساختیم.

SHD

• بار تولیدی و پیش تولیدی SAP روی آرایه تمام فلش باقی ماند.
• محیط‌های آزمایش توسعه‌دهنده و خدمات زیرساختی در یک آرایه ترکیبی جداگانه قرار گرفتند.

سندرم روده تحریک‌پذیر

• ساخته شده با استفاده از Veritas Netbackup.
• ما کمی به اسکریپت های داخلی برای پشتیبان گیری از تنظیمات MCOS اضافه کردیم.
• ما نسخه های عملیاتی را برای بازیابی سریع روی قفسه دیسک قرار می دهیم و از نوارها برای ذخیره سازی طولانی مدت استفاده می کنیم.

نظارت

• تمامی سخت افزارها، سیستم عامل و SAP تحت Zabbix نصب شدند.
• ما داشبوردهای مفید زیادی را در گرافانا جمع آوری کرده ایم.
• هنگامی که یک هشدار رخ می دهد، Zabbix می تواند یک درخواست در سیستم مدیریت حادثه ایجاد کند، ما آن را در Jira پیاده سازی کرده ایم. اطلاعات در کانال تلگرام نیز تکراری می باشد.

تلگرام

سلامت عمومی هانا

وضعیت سرور برنامه SAP:

خدمات زیرساختی

• برای سرویس‌دهی به فضاهای نام داخلی، خوشه‌ای از سرورهای DNS ایجاد شد که با سرورهای مشتری همگام‌سازی می‌شوند.
• ما یک فایل سرور جداگانه برای تبادل داده ایجاد کردیم.
• برای ذخیره تنظیمات مختلف، Gitlab اضافه شد.
• برای اطلاعات حساس مختلف، HashiCorp Vault را گرفتیم.

فرآیند مهاجرت

به طور کلی، فرآیند مهاجرت شامل مراحل زیر است:

• تهیه کلیه اسناد پروژه لازم؛
• مذاکره با ارائه دهنده فعلی - حل و فصل مسائل سازمانی؛
• خرید، تحویل و نصب تجهیزات جدید برای پروژه؛
• مهاجرت آزمایشی و اشکال زدایی فرآیند؛
• انتقال سیستم، مبارزه با مهاجرت

در پایان مهرماه 2019 قراردادی منعقد کردیم، سپس معماری را طراحی کردیم و پس از توافق با مشتری، تجهیزات لازم را سفارش دادیم.

چیزی که ابتدا باید به آن توجه کنید زمان تحویل تجهیزات است. به طور متوسط، تحویل سخت افزار تایید شده برای SAP NAHA که الزامات سازنده نرم افزار برای پلتفرم های سخت افزاری را برآورده می کند، 10 تا 12 هفته طول می کشد. و با در نظر گرفتن فصلی بودن (اجرای پروژه دقیقاً در سال جدید سقوط کرد) این مدت می توانست یک ماه دیگر افزایش یابد. بر این اساس، لازم بود روند تا حد امکان تسریع شود: ما با توزیع کننده-تامین کننده کار کردیم و در مورد تحویل سریع هواپیما (به جای مسیرهای زمینی و دریایی) توافق کردیم.

ماه های نوامبر و دسامبر برای آماده سازی مهاجرت و دریافت بخشی از تجهیزات صرف شد. ما آماده سازی را روی یک نیمکت آزمایشی در ابر عمومی خود انجام دادیم، جایی که تمام مراحل اصلی را انجام دادیم و مشکلات و مشکلات احتمالی را تشخیص دادیم:

• یک برنامه دقیق برای تعامل بین اعضای تیم پروژه با زمان بندی دقیقه به دقیقه تهیه کرد.
• یک میز آزمایش برای پایگاه داده و سرورهای برنامه تقریباً مشابه زیرساخت هدف ایجاد کرد.
• کانال های ارتباطی لازم و خدمات زیرساختی را برای آزمایش عملکرد ادغام ها پیکربندی کرد.
• سناریوهای برش کار کرد.
• ابر همچنین به ما کمک کرد تا قالب‌های ماشین مجازی از پیش پیکربندی شده‌ای را ایجاد کنیم، که سپس به سادگی آن‌ها را وارد کرده و در منظره هدف مستقر کردیم.

کمی قبل از تعطیلات سال نو، اولین دسته از تجهیزات به دست ما رسید. این امکان استقرار برخی از سیستم ها را بر روی سخت افزار واقعی فراهم کرد. از آنجایی که همه چیز به دست نیامد، تجهیزات جایگزینی را وصل کردیم که تامین آن را با فروشنده و توزیع کنندگان به توافق رسیدیم. ما بقایای زیرساخت هدف را در مرحله نهایی دریافت کردیم.
برای رسیدن به مهلت مقرر، مهندسان ما مجبور شدند تعطیلات سال نو را قربانی کنند و کار آماده سازی زیرساخت های مورد نظر را در 2 ژانویه و در میانه تعطیلات آغاز کنند. بله، گاهی اوقات این اتفاق می افتد که در آتش است و به سادگی هیچ گزینه دیگری وجود ندارد. در خطر، عملکرد سیستم هایی بود که عمر شرکت به آنها بستگی دارد.

ترتیب کلی مهاجرت به این صورت بود: اول، سیستم‌های کم اهمیت (چشم‌انداز توسعه، چشم‌انداز آزمایش)، سپس سیستم‌های مولد. مرحله نهایی مهاجرت در اواخر ژانویه و اوایل فوریه انجام شد.

روند مهاجرت تا دقیقه برنامه ریزی شده بود. این یک طرح برش با لیستی از تمام وظایف، زمان تکمیل و افراد مسئول است. همه مراحل قبلاً در مهاجرت آزمایشی انجام شده بود، بنابراین در مهاجرت زنده فقط باید برنامه را دنبال کنید و روند را هماهنگ کنید.

مهاجرت به صورت سیستماتیک در چند مرحله انجام شد. در هر مرحله دو سیستم وجود دارد.

نتیجه یک اسپرینت سه ماهه سیستمی بود که در مرکز داده CROC کاملاً عملیاتی است. در مجموع با کار تیمی نتیجه مثبت حاصل شد؛ مشارکت و ایثار همه شرکت کنندگان در این فرآیند حداکثر بود.

نقش مشتری در پروژه

برقراری ارتباط با ارائه دهنده ای که مشتری ما را ترک می کرد آسان نبود. این قابل درک است؛ آنها آخرین نفر در لیست افراد علاقه مند به تکمیل موفقیت آمیز پروژه بودند. مشتری وظیفه تشدید و رکاب زدن تمام مسائل ارتباطی را بر عهده گرفت و با این 100500% کنار آمد. از این بابت از او تشکر ویژه ای دارم. بدون چنین مشارکت عملی در فرآیند، نتیجه پروژه می توانست کاملاً متفاوت باشد.

با توجه به رسمی شدن فرآیندها در سمت ارائه دهنده "سابق"، پشتیبانی زیرساخت توسط متخصصانی انجام شد که به معنای واقعی کلمه از مشکلات دور بودند و در آن زمان هنوز مشتری آنها بودند. به عنوان مثال، فرآیند صادرات یک پایگاه داده می تواند از یک ساعت تا پنج ساعت طول بکشد. سپس به نظر می رسید که این نوعی جادو بود، رازی که هرگز برای ما فاش نشد. احتمالاً مهندسان پشتیبانی فنی در این بین به مدیتیشن پرداخته اند و فراموش کرده اند که جایی در روسیه دور ضرب الاجل است، مهندسان بدون سالاد سال نو، مشتری گریه می کند و عذاب می کشد...

نتایج پروژه

مرحله نهایی مهاجرت، انتقال سیستم ها برای تعمیر و نگهداری بود.

اکنون ما یک سرویس پنجره واحد را برای درخواست‌های مشتری ارائه می‌دهیم و کل محدوده وظایف مربوط به پشتیبانی از مؤلفه‌های زیرساخت و پایه SAP را همراه با شریک خود - هوشمند پوشش می‌دهیم. مشتری شش ماه است که در یک ابر خصوصی زندگی می کند. در اینجا آمار موارد خدماتی در این مدت آمده است:

• 90 حادثه (20٪ بدون دخالت مشتری حل شد)
• حل شده در SLA - 100٪
• خاموشی های برنامه ریزی نشده سیستم - 0

اگر مشکلاتی مشابه مشکلات مشتری ما دارید و می خواهید در مورد نحوه حل آنها بیشتر بدانید، به آدرس زیر بنویسید: [ایمیل محافظت شده]

منبع: www.habr.com