Hoặc là nó có thể? Tất nhiên, việc di chuyển hệ thống SAP là một quá trình phức tạp và tốn nhiều công sức, để thành công đòi hỏi sự phối hợp nhịp nhàng của tất cả những người tham gia. Và nếu việc di chuyển được thực hiện trong thời gian ngắn, nhiệm vụ sẽ trở nên phức tạp hơn nhiều. Không phải ai cũng quyết định làm điều này. Có thể có nhiều lý do. Ví dụ, bản thân quá trình này rất dài và phức tạp về mặt tổ chức. Ngoài ra còn có nguy cơ hệ thống ngừng hoạt động ngoài dự kiến. Hoặc khách hàng không chắc chắn rằng khi trải qua một ca phẫu thuật như vậy, họ sẽ nhận được những lợi ích tương xứng với công sức đã bỏ ra. Tuy nhiên, vẫn có những ngoại lệ.
Phần dưới đây sẽ nói về những khó khăn mà khách hàng gặp phải trong quá trình di chuyển và bảo trì hệ thống SAP, thảo luận lý do tại sao các khuôn mẫu không phải lúc nào cũng tương ứng với thực tế và chia sẻ một nghiên cứu điển hình về cách chúng tôi quản lý để di chuyển hệ thống của khách hàng sang một hệ thống khác. cơ sở hạ tầng mới chỉ trong hơn ba tháng.
Lưu trữ hệ thống SAP
Chỉ 5 năm trước, thật khó để tưởng tượng rằng khách hàng sẽ bắt đầu sử dụng ồ ạt tài nguyên lưu trữ cho các ứng dụng SAP. Trong hầu hết các trường hợp, chúng được triển khai tại chỗ. Tuy nhiên, với sự phát triển của các mô hình gia công và thị trường dịch vụ đám mây, thế giới quan của khách hàng bắt đầu thay đổi. Các lập luận ảnh hưởng đến sự lựa chọn có lợi cho đám mây cho SAP là gì?
- Đối với những người mới bắt đầu dự định triển khai SAP, cơ sở hạ tầng đám mây gần như là một lựa chọn tiêu chuẩn - khả năng mở rộng tài nguyên theo nhu cầu hiện tại của hệ thống và miễn cưỡng chuyển hướng tài nguyên sang phát triển các năng lực không cốt lõi.
- Ở các công ty có bối cảnh hệ thống lớn, với sự trợ giúp của việc lưu trữ hệ thống SAP, CIO đạt được cấp độ quản lý rủi ro khác biệt về mặt chất lượng, bởi vì Đối tác chịu trách nhiệm về SLA.
- Lập luận phổ biến thứ ba là chi phí xây dựng cơ sở hạ tầng cao để thực hiện các kịch bản DR và tính sẵn sàng cao.
- Yếu tố 2027 – nhà cung cấp đã thông báo chấm dứt hỗ trợ cho các hệ thống cũ vào năm 2027. Điều này có nghĩa là chuyển cơ sở dữ liệu sang HANA, kéo theo chi phí cho việc hiện đại hóa và mua sức mạnh tính toán mới.
Thị trường lưu trữ SAP ở Nga hiện có thể được coi là khá trưởng thành. Và điều này mang đến nhiều cơ hội cho những khách hàng muốn thay đổi nền tảng lưu trữ của họ. Tuy nhiên, những dự án như vậy có thể gây lo ngại cho các doanh nghiệp do sự phức tạp của thủ tục di chuyển. Điều này buộc khách hàng phải đặt ra yêu cầu ngày càng cao đối với các nhà cung cấp dịch vụ, những người không chỉ phải có năng lực đặc biệt trong việc lưu trữ và bảo trì hệ thống SAP mà còn phải có kinh nghiệm thành công trong lĩnh vực di chuyển.
Những khó khăn khi thay đổi dịch vụ lưu trữ SAP là gì?
Hosting thì khác. Không nhất quán với mức độ dịch vụ đã công bố, nhiều “nhưng” và dấu hoa thị với sự đặt trước bằng văn bản nhỏ, nguồn lực và khả năng hạn chế của nhà cung cấp dịch vụ lưu trữ, thiếu linh hoạt trong các vấn đề giao tiếp với khách hàng, quan liêu, hạn chế kỹ thuật, năng lực hỗ trợ kỹ thuật thấp chuyên gia, cũng như nhiều sắc thái khác - đây chỉ là một phần nhỏ trong những cạm bẫy mà khách hàng có thể gặp phải khi vận hành hệ thống kinh doanh của mình trong cơ sở hạ tầng gia công phần mềm. Thông thường, đối với khách hàng, tất cả những điều này vẫn ở trong bóng tối, trong một hợp đồng nhiều trang và xuất hiện trong quá trình sử dụng dịch vụ.
Tại một thời điểm nào đó, khách hàng thấy rõ rằng mức độ dịch vụ mà họ nhận được vượt xa sự mong đợi của họ. Đây là một loại chất xúc tác để tìm ra giải pháp khắc phục tình hình và trong trường hợp thất bại, khi vấn đề tích tụ đến mức giới hạn và trở nên rất nhức nhối, họ chuyển sang hành động tích cực để phát triển các phương án thay thế theo hướng thay đổi nhà cung cấp dịch vụ. .
Tại sao họ lại đợi đến phút cuối cùng? Lý do rất đơn giản - quá trình di chuyển hệ thống cho khách hàng không phải lúc nào cũng minh bạch và dễ hiểu. Khách hàng khó có thể đánh giá những rủi ro thực tế liên quan đến quá trình di chuyển. Có thể nói rằng việc di chuyển đối với khách hàng giống như một loại hộp đen: không rõ ràng về giá cả, thời gian ngừng hoạt động của hệ thống, rủi ro và cách giảm thiểu chúng, và nói chung là tối tăm và đáng sợ. Giống như, nếu nó không thành công, thì những cái đầu sẽ lăn lộn ở phía trên và ở những người biểu diễn.
SAP là một hệ thống cấp doanh nghiệp, phức tạp và nói một cách nhẹ nhàng thì không hề rẻ. Ngân sách hợp lý được chi cho việc triển khai, sửa đổi và bảo trì, và tuổi thọ của doanh nghiệp phụ thuộc vào tính sẵn có và hoạt động chính xác của chúng. Bây giờ hãy tưởng tượng hậu quả của việc dừng một số hoạt động sản xuất lớn. Đây là những tổn thất tài chính, có thể được tính bằng những con số có số lượng lớn bằng 0, cũng như những rủi ro về danh tiếng và những rủi ro đáng kể khác.
Chúng tôi sẽ phân tích những khó khăn có thể phát sinh ở từng giai đoạn trong trường hợp di chuyển hệ thống SAP từ một trong những khách hàng của chúng tôi.
Chuẩn bị và thiết kế
Di chuyển là một công thức có nhiều phần khác nhau. Và một trong những điều quan trọng nhất là giai đoạn thiết kế và chuẩn bị cơ sở hạ tầng mục tiêu (mới).
Chúng tôi cần đi sâu vào việc triển khai các hệ thống hiện có, kiến trúc của chúng. Trong cơ sở hạ tầng mục tiêu, chúng tôi lặp lại các giải pháp hiện có ở đâu đó, bổ sung và cải thiện chúng ở một số điểm, làm lại chúng ở đâu đó, suy nghĩ kỹ lưỡng và lựa chọn các giải pháp để đảm bảo khả năng chịu lỗi và tính sẵn sàng, đồng thời cũng hợp nhất tất cả các nguồn lực nhiều nhất có thể.
Trong quá trình thiết kế, nhiều bài tập khác nhau đã được thực hiện, điều này cuối cùng giúp bạn có thể chuẩn bị nhiều nhất có thể cho việc di chuyển và tính đến tất cả các loại sắc thái và cạm bẫy (sẽ nói thêm về chúng sau).
Những gì chúng tôi đạt được là cơ sở hạ tầng đám mây riêng được thiết kế riêng dựa trên trung tâm dữ liệu của chúng tôi:
- máy chủ vật lý chuyên dụng cho SAP HANA;
- Nền tảng ảo hóa VMware cho máy chủ ứng dụng và dịch vụ hạ tầng;
- các kênh liên lạc trùng lặp giữa các trung tâm dữ liệu cho L2 VPN;
- hai hệ thống lưu trữ chính để tách sản phẩm và “mọi thứ khác”;
- SRC dựa trên Veritas Netbackup với một máy chủ, kệ đĩa và thư viện băng riêng biệt.
Và đây là cách chúng tôi triển khai tất cả những điều này từ quan điểm kỹ thuật.
SAP
- Để sử dụng hiệu quả bộ lưu trữ cho HANA hiệu quả, chúng tôi đã sử dụng ổ đĩa dùng chung mà không cần sao chép cơ sở dữ liệu hệ thống bằng SAP. Tất cả điều này được gói gọn trong cụm SUSE HAE ở chế độ chờ chủ động dựa trên Máy tạo nhịp tim. Có, thời gian khôi phục lâu hơn một chút so với sao chép, nhưng chúng tôi tiết kiệm được một nửa dung lượng lưu trữ và do đó, tiết kiệm ngân sách của khách hàng.
- Trong môi trường tiền sản xuất, cụm HANA đã bị loại bỏ, nhưng về mặt kỹ thuật, cấu hình sản xuất đã được lặp lại.
- Môi trường thử nghiệm và phát triển đã được phân phối trên một số máy chủ khác mà không cần cụm trong cấu hình MCOS.
- Tất cả các máy chủ ứng dụng đều được ảo hóa và lưu trữ trong VMware.
Сети
- Về mặt vật lý, chúng tôi đã tách biệt các đường viền của mạng điều khiển và mạng sản xuất bằng nhiều bộ chuyển mạch, chuyển các mạng hiệu quả về phía trung tâm dữ liệu của khách hàng.
- Chúng tôi đã cài đặt đủ số lượng giao diện mạng để không trộn lẫn các luồng lưu lượng lớn.
- Để truyền dữ liệu từ hệ thống lưu trữ, chúng tôi đã tạo ra các nhà máy FC SAN cổ điển.
SHD
- Tải sản xuất và tiền sản xuất của SAP được để lại trên mảng toàn flash.
- Môi trường thử nghiệm dành cho nhà phát triển và dịch vụ cơ sở hạ tầng được đặt trên một mảng kết hợp riêng biệt.
IBS
- Được tạo bằng Veritas Netbackup.
- Chúng tôi đã thêm một chút vào các tập lệnh tích hợp để sao lưu cấu hình MCOS.
- Chúng tôi đặt các bản sao hoạt động trên giá đĩa để phục hồi nhanh chóng và chúng tôi sử dụng băng để lưu trữ lâu dài.
Giám sát
- Tất cả phần cứng, hệ điều hành và SAP đều được cài đặt dưới Zabbix.
- Chúng tôi đã thu thập được nhiều trang tổng quan hữu ích trong Grafana.
- Khi cảnh báo xảy ra, Zabbix có thể tạo yêu cầu trong hệ thống quản lý sự cố; chúng tôi đã triển khai yêu cầu này trên Jira. Thông tin cũng được sao chép trên kênh Telegram.
Telegram
Sức khỏe tổng quát của HANA
Trạng thái máy chủ ứng dụng SAP:
Dịch vụ cơ sở hạ tầng
- Để phục vụ các không gian tên nội bộ, một cụm máy chủ DNS đã được tạo ra và được đồng bộ hóa với các máy chủ của khách hàng.
- Chúng tôi đã tạo một máy chủ tệp riêng để trao đổi dữ liệu.
- Để lưu trữ các cấu hình khác nhau, Gitlab đã được thêm vào.
- Để biết nhiều thông tin nhạy cảm khác nhau, chúng tôi đã lấy HashiCorp Vault.
Quá trình di chuyển
Nói chung, quá trình di chuyển bao gồm các giai đoạn sau:
- chuẩn bị tất cả các tài liệu dự án cần thiết;
- đàm phán với nhà cung cấp hiện tại - giải quyết các vấn đề về tổ chức;
- mua, vận chuyển và lắp đặt thiết bị mới cho dự án;
- kiểm tra di chuyển và gỡ lỗi quy trình;
- chuyển giao hệ thống, chống di cư.
Cuối tháng 2019/XNUMX, chúng tôi ký hợp đồng, thiết kế kiến trúc, thống nhất với khách hàng và đặt mua các thiết bị cần thiết.
Điều bạn cần chú ý đầu tiên chính là thời gian bàn giao thiết bị. Trung bình, việc phân phối phần cứng được chứng nhận cho SAP NAHA đáp ứng yêu cầu của nhà sản xuất phần mềm đối với nền tảng phần cứng mất 10-12 tuần. Và tính đến tính thời vụ (việc thực hiện dự án rơi vào đúng dịp Tết), khoảng thời gian này có thể đã tăng thêm một tháng nữa. Theo đó, cần phải đẩy nhanh quá trình càng nhiều càng tốt: chúng tôi đã làm việc với nhà phân phối-nhà cung cấp và thống nhất về việc giao hàng nhanh bằng đường hàng không (thay vì đường bộ và đường biển).
Tháng 11 và tháng 12 được dành để chuẩn bị cho việc di chuyển và nhận một số thiết bị. Chúng tôi đã tiến hành chuẩn bị trên băng ghế thử nghiệm trên đám mây công cộng của mình, nơi chúng tôi đã thực hiện tất cả các bước chính và phát hiện ra những khó khăn và vấn đề có thể xảy ra:
- chuẩn bị một kế hoạch chi tiết về sự tương tác giữa các thành viên trong nhóm dự án với thời gian từng phút;
- đã xây dựng một băng ghế thử nghiệm cho cơ sở dữ liệu và máy chủ ứng dụng theo cách gần giống như trong cơ sở hạ tầng mục tiêu;
- định cấu hình các kênh liên lạc và dịch vụ cơ sở hạ tầng cần thiết để kiểm tra hoạt động tích hợp;
- xây dựng các kịch bản cắt giảm;
- Đám mây cũng giúp chúng tôi tạo các mẫu máy ảo được định cấu hình sẵn, sau đó chúng tôi chỉ cần nhập và triển khai vào bối cảnh mục tiêu.
Ngay trước kỳ nghỉ Tết, lô thiết bị đầu tiên đã đến với chúng tôi. Điều này giúp có thể triển khai một số hệ thống trên phần cứng thực. Vì không phải mọi thứ đều đến nơi nên chúng tôi đã kết nối thiết bị thay thế, nguồn cung cấp mà chúng tôi đã thỏa thuận được với nhà cung cấp và nhà phân phối. Chúng tôi đã nhận được phần còn lại của cơ sở hạ tầng mục tiêu ở giai đoạn cuối.
Để đáp ứng thời hạn, các kỹ sư của chúng tôi đã phải hy sinh kỳ nghỉ Tết và bắt đầu công việc chuẩn bị cơ sở hạ tầng mục tiêu vào ngày 2 tháng XNUMX, giữa kỳ nghỉ lễ. Đúng, điều này đôi khi xảy ra khi nó bốc cháy và đơn giản là không có lựa chọn nào khác. Bị đe dọa là hiệu suất của các hệ thống mà cuộc sống của doanh nghiệp phụ thuộc vào.
Thứ tự di chuyển chung trông như thế này: đầu tiên là các hệ thống ít quan trọng nhất (bối cảnh phát triển, bối cảnh thử nghiệm), sau đó là các hệ thống sản xuất. Giai đoạn di cư cuối cùng diễn ra vào cuối tháng Giêng và đầu tháng Hai.
Quá trình di chuyển đã được lên kế hoạch đến từng phút. Đây là kế hoạch chuyển tiếp với danh sách tất cả các nhiệm vụ, thời gian hoàn thành và những người chịu trách nhiệm. Tất cả các bước đã được thực hiện trong quá trình di chuyển thử nghiệm, vì vậy trong quá trình di chuyển trực tiếp, bạn chỉ cần tuân theo kế hoạch và điều phối quy trình.
Việc di chuyển được thực hiện một cách có hệ thống trong nhiều giai đoạn. Có hai hệ thống trong mỗi giai đoạn.
Kết quả của cuộc chạy nước rút kéo dài ba tháng là một hệ thống đã hoạt động hoàn toàn trong trung tâm dữ liệu CROC. Nhìn chung, kết quả tích cực đã đạt được thông qua tinh thần đồng đội, sự đóng góp và cống hiến của tất cả những người tham gia trong quá trình là tối đa.
Vai trò của khách hàng trong dự án
Giao tiếp với nhà cung cấp mà khách hàng của chúng tôi sắp rời đi không hề dễ dàng. Điều này có thể hiểu được, họ là những người cuối cùng trong danh sách những người quan tâm đến việc hoàn thành thành công dự án. Khách hàng đảm nhận nhiệm vụ giải quyết và xử lý tất cả các vấn đề liên lạc và giải quyết 100500% này. Đặc biệt cảm ơn anh ấy vì điều này. Nếu không có sự tham gia khả thi như vậy vào quá trình, kết quả của dự án có thể đã hoàn toàn khác.
Do việc chính thức hóa các quy trình từ phía nhà cung cấp “cũ”, việc hỗ trợ cơ sở hạ tầng được thực hiện bởi các chuyên gia, những người thực sự không gặp vấn đề gì, vào thời điểm đó vẫn là khách hàng của họ. Ví dụ: quá trình xuất cùng một cơ sở dữ liệu có thể mất từ một đến năm giờ. Sau đó, dường như đây là một loại phép thuật nào đó, một bí mật chưa bao giờ được tiết lộ cho chúng ta. Có lẽ trong lúc đó các kỹ sư hỗ trợ kỹ thuật đã chìm đắm trong thiền định mà quên mất rằng đâu đó ở nước Nga xa xôi có deadline, các kỹ sư không có món salad đầu năm, khách hàng đang khóc lóc đau khổ...
Kết quả dự án
Bước cuối cùng của quá trình di chuyển là chuyển hệ thống để bảo trì.
Giờ đây, chúng tôi cung cấp dịch vụ một cửa cho các yêu cầu của khách hàng và bao gồm toàn bộ phạm vi nhiệm vụ liên quan đến hỗ trợ các thành phần cơ sở hạ tầng và nền tảng SAP cùng với đối tác của chúng tôi - itelligence. Khách hàng đã sống trên đám mây riêng được sáu tháng. Dưới đây là số liệu thống kê về các trường hợp dịch vụ trong thời gian này:
- 90 sự cố (20% được giải quyết mà không liên quan đến khách hàng)
- Đã giải quyết trong SLA – 100%
- Tắt hệ thống đột xuất – 0
Nếu bạn gặp vấn đề tương tự như khách hàng của chúng tôi và bạn muốn tìm hiểu thêm về cách giải quyết chúng, hãy viết thư tới: [email được bảo vệ]
Nguồn: www.habr.com