SAP 호스팅 변경 경험: 극심한 고통 없이 시스템을 마이그레이션하는 방법

아니면 가능할까요? 물론, SAP 시스템 마이그레이션은 복잡하고 힘든 과정이며, 이를 성공적으로 이루려면 모든 참여자의 협력이 필요합니다. 그리고 마이그레이션이 짧은 시간 안에 수행된다면 작업은 몇 배나 더 복잡해집니다. 모든 사람이 이렇게 결정하는 것은 아닙니다. 여러 가지 이유가 있을 수 있습니다. 예를 들어, 그 과정 자체가 길고 조직적으로 복잡합니다. 게다가 계획되지 않은 시스템 가동 중단의 위험도 있습니다. 혹은 고객들은 그러한 수술을 받은 후, 노력에 상응하는 혜택을 받을 수 있을지 확신하지 못합니다. 그러나 예외도 있습니다.

아래에서는 SAP 시스템의 마이그레이션 및 유지 관리 과정에서 고객이 직면하는 어려움에 대해 설명하고, 고정관념이 항상 현실과 일치하지 않는 이유를 논의하며, 단 3개월 만에 고객의 시스템을 새로운 인프라로 마이그레이션하는 데 성공한 사례 연구를 공유합니다.

SAP 시스템 호스팅

불과 5년 전만 해도 고객이 SAP 애플리케이션에 대한 호스팅 리소스를 대량으로 사용할 것이라고 상상하기 어려웠습니다. 대부분의 경우, 온프레미스로 구현되었습니다. 하지만 아웃소싱 모델과 클라우드 서비스 시장이 발전하면서 고객의 전망도 바뀌기 시작했습니다. SAP를 위해 클라우드를 선택하는 이유는 무엇입니까?

• SAP 구현을 막 계획한 초보자에게 클라우드 인프라는 실질적으로 표준적인 선택입니다. 시스템의 현재 요구 사항에 맞는 리소스 확장성과 핵심이 아닌 역량 개발에 리소스를 돌리고 싶지 않은 마음 때문입니다.
• 대규모 시스템 환경을 갖춘 회사의 CIO는 SAP 시스템 호스팅을 사용하여 질적으로 새로운 수준의 위험 관리를 달성합니다. 파트너가 SLA에 대한 책임을 지기 때문입니다.
• 세 번째로 가장 자주 제기되는 주장은 고가용성 및 재해 복구 시나리오를 구현하기 위한 인프라 구축 비용이 많이 든다는 것입니다.
• 2027년 요인 - 공급업체가 2027년에 레거시 시스템에 대한 지원 종료를 발표했습니다. 이는 데이터베이스를 HANA로 이전해야 함을 의미하며, 여기에는 현대화 비용과 새로운 컴퓨팅 성능 구매 비용이 수반됩니다.

러시아의 SAP 호스팅 시장은 이제 상당히 성숙되었다고 볼 수 있습니다. 이는 호스팅 플랫폼을 변경하고자 하는 고객에게 많은 기회를 제공합니다. 그러나 이러한 프로젝트는 마이그레이션 절차가 복잡하기 때문에 기업들 사이에서 당연히 우려를 불러일으킬 수 있습니다. 이로 인해 고객은 서비스 제공업체에 더 높은 기준을 요구하게 되었는데, 서비스 제공업체는 SAP 시스템 호스팅 및 지원에 대한 뛰어난 전문성뿐만 아니라 마이그레이션 분야에서의 성공적인 경험도 보유해야 하기 때문입니다.

SAP 호스팅을 변경하는 데 어떤 어려움이 있나요?

호스팅 서비스는 다양합니다. 명시된 서비스 수준을 충족하지 못하거나, 약관에 수많은 단서와 면책 조항이 숨겨져 있거나, 리소스와 기능이 제한적일 수 있습니다. 호스팅 제공업체고객과의 소통 경직, 관료주의, 기술적 한계, 부실한 기술 지원, 그리고 그 밖의 여러 가지 미묘한 차이점들—이러한 것들은 고객이 아웃소싱 인프라에서 비즈니스 시스템을 운영할 때 직면할 수 있는 함정 중 일부에 불과합니다. 이러한 문제들은 대개 여러 페이지로 된 계약서에 숨겨져 있다가 실제 서비스 이용 과정에서 드러나는 경우가 많습니다.

어느 순간, 고객은 자신이 받는 서비스 수준이 기대에 미치지 못한다는 것을 깨닫게 됩니다. 이는 상황을 바로잡기 위한 해결책을 찾기 위한 일종의 촉매이며, 실패할 경우 문제가 한계에 도달하여 정말 고통스러울 때 서비스 제공자를 변경하는 방향으로 대안을 마련하기 위한 적극적인 행동으로 옮겨갑니다.

그들은 왜 마지막 순간까지 기다리나요? 그 이유는 간단합니다. 시스템 이전 과정이 항상 고객에게 투명하고 이해하기 쉬운 것은 아니기 때문입니다. 고객이 마이그레이션 프로세스와 관련된 실제 위험을 평가하는 것은 어렵습니다. 클라이언트의 마이그레이션은 일종의 블랙박스라고 할 수 있습니다. 가격, 시스템 다운타임, 위험과 이를 완화하는 방법 등이 불분명하고 전반적으로 어둡고 무섭습니다. 여기서 만약 잘 안 된다면, 상위 관리자와 공연자 모두의 머리가 뒤집힐 겁니다.

SAP는 기업 수준의 시스템으로 복잡하고, 엄밀히 말하면 저렴하지 않습니다. 적절한 예산이 구현, 개선, 유지관리에 사용되며, 기업의 생존 가능성은 가용성과 올바른 운영에 달려 있습니다. 이제 대규모 생산을 중단하면 어떤 결과가 초래될지 상상해 보세요. 이는 0이 많은 숫자로 계산할 수 있는 재정적 손실일 뿐만 아니라, 평판에 대한 위험과 마찬가지로 중요한 다른 위험도 포함합니다.

우리 고객의 SAP 시스템 마이그레이션 사례를 통해 각 단계에서 발생할 수 있는 어려움을 살펴보겠습니다.

준비 및 설계

이주는 다양한 요소로 구성된 공식입니다. 그리고 가장 중요한 단계 중 하나는 타겟(새로운) 인프라를 설계하고 준비하는 단계입니다.

우리는 기존 시스템 구현과 아키텍처에 몰두해야 했습니다. 목표 인프라에서 우리는 어떤 곳에서는 기존 솔루션을 반복하고, 어떤 곳에서는 보완 및 개선하고, 다른 곳에서는 재설계하고, 장애 허용성과 가용성을 보장하는 솔루션을 고안하고 선택했으며, 가능한 한 모든 리소스를 통합했습니다.

설계 과정에서 다양한 연습을 많이 했고, 이를 통해 최대한 마이그레이션에 대비하고 모든 종류의 미묘한 차이와 함정을 고려할 수 있었습니다(나중에 자세히 설명하겠습니다).

결국 우리는 데이터 센터를 기반으로 맞춤형으로 설계된 프라이빗 클라우드 인프라를 구축했습니다.

• SAP HANA를 위한 전용 물리적 서버
• 애플리케이션 서버 및 인프라 서비스를 위한 VMware 가상화 플랫폼
• L2를 위한 데이터 센터 간 중복 통신 채널 VPN;
• 생산과 "기타"를 분리하기 위한 두 개의 주요 저장 시스템
• Veritas Netbackup을 기반으로 한 백업 시스템으로, 별도의 서버, 디스크 셸프, 테이프 라이브러리를 갖추고 있습니다.

기술적인 관점에서 이 모든 것이 어떻게 구현되었는지 살펴보겠습니다.

SAP

• 생산적인 HANA에 스토리지를 효과적으로 사용하기 위해 SAP 도구를 사용하여 시스템 데이터베이스 복제 없이 공유 디스크를 사용했습니다. 이 모든 것은 Pacemaker를 기반으로 한 SUSE HAE의 Active-Standby 클러스터에 포함되어 있습니다. 네, 복구 시간은 복제보다 조금 더 길지만 저장 공간을 절반으로 절약할 수 있고 결과적으로 고객 예산도 절감할 수 있습니다.
• 사전 프로덕션 환경에서는 HANA 클러스터가 중단되었지만 프로덕션 구성은 기술적으로 반복되었습니다.
• 테스트 및 개발 환경은 MCOS 구성의 클러스터가 없는 여러 대의 서버로 분할되었습니다.
• 모든 애플리케이션 서버는 가상화되어 VMware에서 호스팅되었습니다.

Сети

• 우리는 스위치 스택을 사용하여 제어 네트워크와 생산 네트워크의 윤곽을 물리적으로 분리하고, 생산 네트워크를 고객의 데이터 센터 쪽으로 돌렸습니다.
• 우리는 대규모 트래픽 흐름이 섞이는 것을 피하기 위해 충분한 수의 네트워크 인터페이스를 제공했습니다.
• 저장 시스템에서 데이터를 전송하기 위해 클래식 FC SAN 팩토리가 만들어졌습니다.

SHD

• SAP 프로덕션 및 사전 프로덕션 워크로드는 올플래시 어레이에 남겨졌습니다.
• 개발자와 인프라 서비스를 위한 테스트 환경은 별도의 하이브리드 어레이에 배치되었습니다.

IBS

• Veritas Netbackup을 기반으로 만들어졌습니다.
• MCOS 구성을 백업하기 위해 몇 가지 추가 내장 스크립트를 추가했습니다.
• 빠른 복구를 위해 운영용 사본을 디스크 선반에 보관하고, 장기 보관을 위해 테이프를 사용합니다.

모니터링

• 모든 하드웨어, OS 및 SAP는 Zabbix에 맞게 구성되었습니다.
• 우리는 Grafana에서 많은 유용한 대시보드를 수집했습니다.
• 경고가 발생하면 Zabbix는 Jira에 구현된 인시던트 관리 시스템에서 티켓을 생성할 수 있습니다. 해당 정보는 텔레그램 채널에도 공유되었습니다.

텔레그램

HANA의 일반 상태

SAP 애플리케이션 서버 상태:

인프라 서비스

• 내부 네임스페이스에 서비스를 제공하기 위해 고객 서버와 동기화되는 DNS 서버 클러스터를 설정했습니다.
• 우리는 데이터 교환을 위해 별도의 파일 서버를 만들었습니다.
• 다양한 구성을 저장하기 위해 Gitlab을 추가했습니다.
• 다양한 민감한 정보의 경우 HashiCorp Vault를 사용했습니다.

마이그레이션 프로세스

일반적으로 마이그레이션 프로세스는 다음 단계로 구성됩니다.

• 필요한 모든 설계 문서 준비
• 현재 공급업체와의 협상 - 조직적 문제 해결
• 프로젝트를 위한 신규 장비 구매, 배송 및 설치
• 테스트 마이그레이션 및 프로세스 디버깅
• 시스템 이전, 전투 이주.

2019년 XNUMX월 말에 계약을 체결하고, 건축물을 설계한 후, 고객과 협의하여 필요한 장비를 주문했습니다.

가장 먼저 주의해야 할 점은 장비의 배송 기간입니다. 평균적으로, 소프트웨어 제조업체의 하드웨어 플랫폼 요구 사항을 충족하는 SAP NAHA용 인증 하드웨어를 제공하는 데는 10~12주가 소요됩니다. 그리고 계절성을 고려하면(프로젝트 실행이 새해 전날에 정확히 이루어졌음) 이 기간은 한 달 더 늘어날 수도 있었습니다. 따라서 가능한 한 프로세스를 가속화할 필요가 있었습니다. 우리는 유통업체-공급업체와 협력하여 육로나 해상 경로 대신 비행기를 이용한 신속한 배송에 합의했습니다.

11월과 12월은 이주를 준비하고 일부 장비를 수령하는 데 보냈습니다. 우리는 퍼블릭 클라우드에서 테스트 스탠드를 준비하여 모든 주요 단계를 살펴보고 발생 가능한 어려움과 문제점을 파악했습니다.

• 프로젝트 팀원 간의 상호 작용을 위한 세부적인 계획을 분 단위로 준비했습니다.
• 대상 인프라와 거의 같은 방식으로 데이터베이스와 애플리케이션 서버에 대한 테스트 스탠드를 구축했습니다.
• 통합을 테스트하기 위해 필요한 통신 채널과 인프라 서비스를 구성했습니다.
• 전환 시나리오를 수립했습니다.
• 클라우드는 사전 구성된 가상 머신 템플릿을 만드는 데에도 도움이 되었으며, 이를 간단히 가져와서 대상 환경에 배포할 수 있었습니다.

새해 연휴 직전에 첫 번째 장비가 우리에게 도착했습니다. 이를 통해 일부 시스템을 실제 하드웨어에 배포하는 것이 가능해졌습니다. 모든 사람이 도착한 것은 아니어서 우리는 대체 장비를 연결했고, 공급업체와 유통업체와 공급에 대해 합의했습니다. 우리는 이미 마지막 단계에 있는 목표 인프라의 잔해를 받았습니다.
마감일을 맞추기 위해 당사 엔지니어들은 새해 연휴를 희생하고 연휴 기간인 2월 XNUMX일부터 목표 인프라 준비 작업을 시작해야 했습니다. 네, 화재가 발생했는데 다른 선택의 여지가 없을 때 이런 일이 가끔 발생합니다. 문제의 핵심은 기업의 생명이 달려 있는 시스템의 기능성이었습니다.

일반적인 마이그레이션 순서는 다음과 같습니다. 먼저 중요도가 가장 낮은 시스템(개발 환경, 테스트 환경)을 마이그레이션하고, 그 다음에 프로덕션 시스템을 마이그레이션합니다. 이주의 마지막 단계는 1월 말에서 2월 초에 이루어졌습니다.

이주 과정은 분 단위까지 계획되었습니다. 이는 모든 업무, 완료 시간 및 책임자 목록이 포함된 전환 계획입니다. 테스트 마이그레이션 중에 모든 단계가 이미 완료되었으므로, 프로덕션 마이그레이션에서는 계획을 따르고 프로세스를 조정하는 것만 남았습니다.

이주는 여러 단계에 걸쳐 체계적으로 수행되었습니다. 각 단계에는 두 개의 시스템이 있습니다.

3개월에 걸친 스프린트 결과, KROK 데이터 센터에서 완벽하게 작동하는 시스템이 탄생했습니다. 전반적으로, 공동의 노력 덕분에 긍정적인 결과를 얻을 수 있었습니다. 모든 참여자의 기여와 헌신이 최대한 발휘되었습니다.

프로젝트에서 고객의 역할

고객이 떠나는 것을 공급업체와 소통하는 것은 쉽지 않았습니다. 그들이 프로젝트의 성공적인 완료에 관심을 가진 사람들의 목록에서 맨 마지막에 있었던 것은 당연한 일이었습니다. 고객은 모든 의사소통 문제를 확대하고 해결하는 작업을 맡았으며 100500% 성공적으로 처리했습니다. 이에 대해 그에게 특별히 감사드리고 싶습니다. 과정에 이렇게 적극적으로 참여하지 않았다면 프로젝트 결과는 완전히 달랐을 수도 있습니다.

"이전" 공급업체 측에서 프로세스를 공식화했기 때문에 인프라 유지 관리 작업은 당시 고객이던 문제와는 문자 그대로 거리가 먼 전문가에 의해 수행되었습니다. 예를 들어, 동일한 데이터베이스를 내보내는 프로세스는 1시간에서 5시간까지 걸릴 수 있습니다. 그 당시에는 그것이 일종의 마법처럼 느껴졌고, 우리에게 결코 밝혀지지 않은 비밀처럼 느껴졌습니다. 아마도 기술 지원 엔지니어들은 명상에 빠져서 먼 러시아 어딘가에 마감 기한이 닥쳐 있고, 엔지니어들은 새해 샐러드가 없고, 고객은 울고 고통받고 있다는 사실을 잊었을 것이다...

프로젝트 결과

이전의 마지막 단계는 유지 관리를 위한 시스템 이전이었습니다.

현재 우리는 고객 요청에 대한 단일 창구 서비스를 제공하고 있으며, 파트너사인 itelligence와 함께 인프라 구성 요소와 SAP 기반을 지원하는 전체 업무량을 다루고 있습니다. 해당 고객은 6개월 동안 프라이빗 클라우드를 사용해 왔습니다. 이 기간 동안의 서비스 사례에 대한 통계는 다음과 같습니다.

• 90건의 사건(20%는 고객 개입 없이 해결됨)
• SLA 내에서 해결됨 - 100%
• 예정되지 않은 시스템 종료 – 0

귀하께서 당사 고객과 유사한 업무를 맡고 계시고 이를 해결하는 방법에 대해 자세히 알고 싶으시다면 ahaidukov@croc.ru로 메일을 보내주세요.

출처 : habr.com