파일럿 단계 살펴보기

  • 20분

파일럿은 프로젝트 계획 및 준비와 병행해서 실행할 수 있습니다. 이 단계를 사용하여 계획 및 준비 단계에서 식별된 옵션을 테스트할 수도 있습니다. 파일럿의 일환으로 전체 HA/DR 솔루션과 보안 디자인을 설정하고 유효성을 검사하는 것이 좋습니다. 이 단계에서 확장성 테스트를 수행하거나 SAP 샌드박스 시스템을 배포할 수 있는 경우도 있습니다. 파일럿을 실행하려면 고객은 먼저 Azure로 마이그레이션하려는 중요하지 않은 시스템을 식별하고 다음 작업을 수행하여 계속 진행해야 합니다.

1. Azure로의 데이터 전송을 최적화

접근 방식과 결과는 Azure에 대한 고객의 연결에 따라 달라집니다. 데이터 양에 따라 ExpressRoute, 사이트 간 VPN 또는 오프라인 데이터 전송 서비스(예: Azure Data Box 또는 Azure Import/Export 서비스)를 이 목적으로 사용할 수도 있습니다.

2. SAP 이질적인 플랫폼 마이그레이션

데이터베이스 데이터 내보내기 및 가져오기를 포함하는 다른 유형의 SAP 플랫폼 마이그레이션인 경우 내보내기 및 가져오기 단계를 테스트하고 최적화합니다. SQL Server를 대상으로 하는 대규모 이기종 마이그레이션의 경우 SAP OS/DB Migration to SQL Server–FAQ를 참조합니다. 릴리스 업그레이드 또는 SAP DMO(데이터베이스 마이그레이션 옵션)와 마이그레이션을 결합할 필요가 없는 경우 마이그레이션 모니터/SWPM을 사용할 수 있습니다. 자세한 내용은 SUM의 DMO(데이터베이스 마이그레이션 옵션) - 소개를 참조하세요. 두 경우 모두 다음 단계를 사용합니다.

  • 원본에서 내보낼 시간을 측정하고, 내보낸 콘텐츠를 Azure에 업로드하고, 가져오기를 수행합니다. 내보내기와 가져오기 간 겹침을 최대화합니다.
  • 원본 데이터베이스와 대상 데이터베이스 간 비교를 사용하여 대상 인프라의 크기를 적절히 조정합니다.
  • 유효성을 검사하고 타이밍을 최적화합니다.

3. 기술 유효성 검사 수행

VM 유형

  • SAP 지원 참고, SAP HANA 하드웨어 디렉터리, SAP PAM(제품 가용성 매트릭스)을 참조하여 지원되는 Azure VM SKU, 해당 Azure VM SKU에 대해 지원되는 OS 릴리스, 지원되는 SAP 및 DBMS 릴리스에 관한 정보가 정확한지 확인합니다.
  • Azure에서 배포하는 인프라 및 애플리케이션 구성 요소의 크기 유효성을 검사합니다. 기존 애플리케이션을 마이그레이션하는 경우 기존 원격 분석에 따라 필요한 SAPS를 가져올 수 있어야 합니다. SAP 벤치마크를 검색하고 SAP Note #1928533에 나열된 SAPS 번호와 비교합니다. 또한 Azure VM의 SAPS 등급에 제공된 정보(찾을 위치 및 혼동할 수 있는 위치)를 참조하세요.
  • 최대 스토리지 처리량과 계획 단계에서 선택한 여러 다른 VM 유형의 네트워크 처리량에 대한 Azure VM의 크기 조정을 평가하고 테스트합니다. 이 데이터는 Azure의 가상 머신 크기에서 찾을 수 있습니다. Azure VM 게스트 운영 체제가 Windows인 경우 크기 조정을 위해 캐시되지 않은 최대 디스크 처리량을 고려하는 것이 중요합니다. Linux의 경우 크기 조정을 위해 캐시되지 않은 최대 디스크 처리량을 고려하는 것도 중요합니다.

스토리지

  • SAP 애플리케이션 계층을 나타내는 VM 및 성능이 중요하지 않은 DBMS 배포에는 최소한 Azure 표준 SSD 스토리지를 사용하고, 성능이 중요한 DBMS VM에는 Azure Premium Storage를 사용합니다.
  • Azure 표준 HDD 디스크를 사용하지 말고
  • Azure 관리 디스크를 사용합니다.
  • M 시리즈 Azure VM이 있는 DBMS 로그 드라이브에 대해 Azure 쓰기 가속기를 사용하도록 설정합니다. 문서화된 쓰기 가속기 제한 및 사용 제한에 유의합니다.
  • DBMS 관련 스토리지 정보는 SAP 워크로드용 Azure Virtual Machines DBMS 배포에 대한 고려 사항과 해당 문서에서 참조되는 DBMS 관련 설명서를 참조하세요.
  • SAP HANA 배포의 경우 Azure의 SAP HANA 인프라 구성 및 작업을 참조하세요.
  • 디바이스 ID를 사용하여 Azure 데이터 디스크를 Azure Linux VM에 탑재해서는 안됩니다. 대신 UUID(Universally Unique Identifier)를 사용합니다. 그래픽 도구를 사용하여 Azure 데이터 디스크를 탑재할 때는 주의해야 합니다. /etc/fstab에 있는 항목을 다시 검사하여 디스크가 UUID를 사용하여 탑재되었는지 확인합니다. 자세한 내용은 Linux VM에 연결하여 새 디스크 탑재를 참조하세요.

네트워킹

Azure 가상 네트워크 간 또는 내부에서 가상 네트워크 인프라 및 SAP 애플리케이션 배포를 테스트하고 평가합니다.

  1. 다음을 기준으로 단일 Azure 가상 네트워크 내의 허브 및 바퀴살 가상 네트워크 아키텍처나 마이크로 구분 방법을 평가합니다.

    • 피어링된 Azure VNet 간의 데이터 교환으로 인한 비용(자세한 내용은 Azure 가상 네트워크 가격 책정 참조).
    • Azure 가상 네트워크 간 피어링 종료 기능과 가상 네트워크 서브넷에서 호스트된 애플리케이션 또는 VM이 보안 위험이 될 경우 NSG를 사용하여 가상 네트워크 내의 서브넷을 격리 하는 기능 비교
    • 온-프레미스, 인터넷, Azure 가상 데이터 센터 간 네트워크 트래픽의 중앙 로깅 및 감사

  2. SAP 애플리케이션 계층과 SAP DBMS 계층 간의 데이터 경로를 평가하고 테스트합니다. 평가의 일환으로 다음을 고려합니다.

    • SAP 애플리케이션과 SAP NetWeaver, Hybris 또는 S/4HANA 기반 SAP 시스템의 DBMS 계층 간 통신 경로에 네트워크 가상 어플라이언스를 배치할 수 없습니다.
    • 피어링되지 않은 개별 Azure 가상 네트워크에 SAP 애플리케이션 계층과 SAP DBMS를 배치할 수 없습니다.
    • ASG(Azure 애플리케이션 보안 그룹) 및 NSG(네트워크 보안 그룹)를 사용하여 SAP 애플리케이션 계층과 SAP DBMS 계층 간 트래픽 흐름을 제어할 수 있습니다.

  3. SAP 애플리케이션 계층과 SAP DBMS 계층에서 사용되는 VM에서 Azure 가속화된 네트워킹을 사용할 수 있는지 확인합니다. Azure에서 가속화된 네트워킹을 지원하기 위한 다음 OS 요구 사항에 유의하세요.

    • Windows Server 2012 R2 또는 이후 버전
    • SUSE Linux 12 SP3 또는 이후 버전
    • RHEL 7.4 또는 이후 버전
    • Oracle Linux 7.5. RHCKL 커널을 사용하려면 릴리스 3.10.0-862.13.1.el7이 필요합니다. Oracle UEK 커널을 사용하려면 릴리스 5가 필요합니다.

  4. SAP Note #500235 및 SAP Note #1100926에 따라 SAP 애플리케이션 계층 VM과 DBMS VM 간의 네트워크 대기 시간을 테스트하고 평가합니다. SAP Note #1100926의 네트워크 대기 시간 지침을 기준으로 결과를 평가합니다. 네트워크 대기 시간은 보통에서 정상 범위 내에 있어야 합니다.

  5. Azure ILB(내부 부하 분산 장치) 배포가 Direct Server Return을 사용하도록 설정되어 있는지 확인합니다. 이 설정은 DBMS 계층의 고가용성 구성에 ILB가 사용되는 경우 대기 시간을 줄입니다.

  6. Linux 게스트 운영 체제와 함께 Azure Load Balancer를 사용하는 경우 Linux 네트워크 매개 변수 net.ipv4.tcp_timestamps가 0으로 설정되어 있는지 확인합니다. 이는 SAP Note #2382421에 대한 일반적인 권장 사항과 모순됩니다. SAP Note는 Azure 부하 분산 장치와 함께 작동하도록 매개 변수를 0으로 설정해야 한다는 사실을 반영하여 업데이트 되었습니다.

고가용성 및 재해 복구 배포

  • 특정 Azure 가용성 영역을 대상으로 하지 않고 SAP 애플리케이션 계층을 배포하는 경우 SAP 대화 상자 인스턴스 또는 동일한 SAP 시스템의 미들웨어 인스턴스를 실행하는 모든 VM이 동일한 가용성 집합에 배포되었는지 확인합니다.

    • SAP 중앙 서비스와 DBMS에 대해 고가용성이 필요하지 않은 경우 SAP 애플리케이션 계층과 동일한 가용성 집합에 해당 VM을 배포할 수 있습니다.

  • 고가용성을 위해 SAP Central Services와 DBMS 계층을 수동 복제본으로 보호해야 하는 경우 하나의 가용성 집합에 SAP Central Services 노드 2개를 배포하고 다른 가용성 집합에 DBMS 노드 2개를 배포합니다.

  • Azure 가용성 영역에 배포하는 경우에는 가용성 집합을 활용할 수 없습니다. 대신, 영역 간 대기 시간이 가장 짧은 두 개의 개별 가용성 영역에 활성 및 수동 Central Services 노드를 배포해야 합니다.

  • 가용성 영역에서 DBMS 및 SAP Central Services 계층에 대한 Windows Server 또는 Pacemaker 기반 장애 조치(failover) 클러스터를 만드는 경우 Azure 표준 부하 분산 장치를 사용해야 합니다. 기본 부하 분산 장치는 영역 배포를 지원하지 않습니다.

시간 제한 설정

  • SAP 인스턴스의 SAP NetWeaver 개발자 추적을 검사하고 큐에 넣기 서버와 SAP 작업 프로세스 간 연결이 끊어지지 않았는지 확인합니다. 이러한 두 레지스트리 매개 변수를 설정하면 연결 끊김을 방지할 수 있습니다.

    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. 자세한 내용은 KeepAliveTime을 참조하세요.
    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. 자세한 내용은 KeepAliveInterval을 참조하세요.

  • 온-프레미스 SAP GUI 인터페이스와 Azure에 배포된 SAP 애플리케이션 계층 간 GUI 시간 초과를 방지하려면 default.pfl 또는 인스턴스 프로필에서 다음 매개 변수를 설정합니다.

    • rdisp/keepalive_timeout = 3600
    • rdisp/keepalive = 20

  • Windows 장애 조치(failover) 클러스터링을 사용하는 경우 응답하지 않는 노드에 의해 트리거되는 장애 조치(failover)를 결정하는 매개 변수가 올바르게 설정되어 있는지 확인합니다. Microsoft TechCommunity 문서 장애 조치(failover) 클러스터 네트워크 임계값 조정에는 매개 변수와 매개 변수가 장애 조치(failover) 동작에 미치는 영향이 나열되어 있습니다. 예를 들어 클러스터 노드가 동일한 서브넷에 있다고 가정할 경우 장애 조치(failover) 매개 변수를 다음과 같이 구성해야 합니다.

    • SameSubNetDelay = 2000

    • SameSubNetThreshold = 15

    • RoutingHistorylength = 30

    • 고가용성 및 재해 복구 절차 테스트:

      • Azure VM을 종료(Windows 게스트 OS)하거나 운영 체제를 패닉 모드로 설정(Linux 게스트 OS)하여 장애 조치(failover)를 시뮬레이션합니다.

      • 장애 조치(failover)를 완료하는 데 걸리는 시간을 측정합니다. 시간이 너무 오래 걸리면 다음을 고려합니다.

        • SUSE Linux의 경우 Azure Fencing 에이전트 대신 SBD 디바이스를 사용하여 장애 조치(failover) 속도를 높입니다.
        • SAP HANA의 경우 데이터를 다시 로드하는 데 시간이 너무 오래 걸리면 스토리지 성능을 향상시키는 것이 좋습니다.

      • 백업/복원 시퀀스 및 타이밍을 테스트하고 필요한 경우 조정합니다. 백업 시간만으로 충분하지 않은지 확인합니다. 또한 복원 작업을 테스트하고 복원 작업을 수행합니다. RTO가 데이터베이스 또는 VM 복원 프로세스에 의존하는 RTO SLA 내에 복원 시간이 있는지 확인합니다.

      • DR 기능 및 아키텍처를 테스트합니다.

4. 보안 검사 수행

  • 구현한 Azure RBAC(역할 기반 액세스) 방법의 유효성을 테스트합니다. 목표는 서로 다른 팀에 위임된 액세스 및 사용 권한을 분리하고 제한하는 것입니다. 예를 들어 SAP Basis 팀원은 지정된 Azure 가상 네트워크에 Azure VM을 배포하고 해당 Azure VM에 디스크를 할당할 수 있어야 합니다. 그러나 SAP Basis 팀은 새 가상 네트워크를 만들거나 기존 가상 네트워크의 설정을 변경할 수 없어야 합니다. 반면에 네트워크 팀원은 SAP 애플리케이션과 DBMS VM이 실행되는 가상 네트워크에 Azure VM을 배포할 수 없어야 합니다. 또한 네트워크 팀원은 VM의 특성을 변경하거나 VM 및 해당 디스크를 삭제할 수 없어야 합니다.
  • NSG 규칙이 예상대로 작동하고 보호된 리소스를 보호하는지 확인합니다.
  • 미사용 암호화 및 전송 중 암호화를 확인합니다. 인증서를 백업, 저장, 액세스하는 프로세스를 정의 및 구현하고 암호화된 엔터티의 복원 프로세스 유효성을 검사합니다.
  • OS 디스크에 Azure Disk Encryption을 사용합니다.
  • 암호화 메커니즘을 구현할지 여부를 결정할 때는 실용적인 방법을 고려합니다. 예를 들어 Azure Disk Encryption과 DBMS 투명한 데이터베이스 암호화를 둘 다 적용해야 하는지 여부를 평가합니다.

5. 성능 테스트

마이그레이션 시나리오에서 SAP 추적 및 측정값을 활용하여 다음을 기준으로 현재 구현과 파일럿을 비교합니다.

  • 상위 10개 온라인 보고서
  • 상위 10개 일괄 작업
  • 크로스-프레미스 트래픽을 중심으로 인터페이스를 통해 SAP 시스템으로 데이터 전송