복원성 계획
비즈니스 또는 조직은 다시 클라이언트 데이터 통합을 위한 특정 요구사항을 가집니다. 시간을 갖고 세부 사항으로 설계를 시작하기 전에 입자에서 요구 사항을 충족하는 통합 구조를 계획할 수 있습니다.
복원성 요구사항 결정
사용자 환경의 복원성을 보장하기 전에 먼저 업무와 관련된 복원성을 정의해야 합니다. 즉, 통합 프로세스의 중단과 연관된 비용은 얼마입니까?
일부 고객의 경우 몇 분 중단이 허용되며 처리 기간 내에 잘 실행되는 뱃치 프로세스만 부분적으로 지연합니다. 다른 고객의 경우 중단에 몇 초 정도 불구하면 비즈니스에 직접적인 영향을 미치는 재무 손실이 발생할 수 있습니다.
해당 관점에서 다음 요소를 확인해야 합니다.
- 환경에 허용되는 운용중단의 기간은 무엇입니까? 운용중단 발생 시 비즈니스의 비용을 정의하고 운용중단이 운용중단 기간과 어떤 방식으로 바뀔 수 있는지 파악해야 합니다.
- 어떤 기술을 사용해야 하며 필요한 서비스 레벨로 어떻게 전달할 수 있습니까? 실시간 또는 일괄 처리 방법을 사용하겠습니까? 또는 이 둘의 조합? 처리하는 데이터 양은 얼마입니까?
복구 구조 정의
복원형 구조를 정의하려면 엔드투엔드 데이터 통합 솔루션을 확인해야 합니다.
통합 프로세스의 경우 다음과 같은 구조 구성 요소(하드웨어 및 소프트웨어 모두) 를 고려해야 합니다.
- 소스 시스템의 복원성
- 대상 시스템의 복원성
- 스테이지 영역의 복원성이 사용된 경우
- 데이터 통합 도구의 복원성
- 오케스트레이션의 복원성(ETL 툴 밖에 있는 경우)
- 네트워크 복원성(연결 관심 사항 및 대역폭 관심 사항 모두)
재해 복구 및 고가용성 측면에서 요구사항을 고려해야 합니다. 이 기반 구조가 설치된 데이터 센터가 손실된 경우 어떻게 됩니까?
Oracle Data Integrator 설치가 복원이 필요한 요소는 다음과 같습니다.
- 에이전트가 중복이어야 함: JEE 에이전트는 로드 밸런서가 에이전트 간에 로드를 분산한다는 점에서 복원성을 제공하도록 설계되었습니다.
- Oracle Data Integrator 저장소는 복원형 시스템에서 실행 중이어야 합니다. Oracle RAC 또는 Exadata 설치는 최소 요구사항이므로 노드 손실이 전체 기반 구조의 손실을 의미하지 않습니다. Oracle Cloud 배포의 경우 Oracle Database Exadata Cloud Service에서 복원형 솔루션을 제공합니다.
- 외부 제품을 사용하여 Oracle Data Integrator 프로세스(예를 들어, Oracle Integration ) 를 통합관리하는 경우 이 제품도 복원해야 합니다.
재해 복구 전략을 고려하는 경우 위에 설명된 것과 동일한 요소가 필요하므로 다음 사항을 확인해야 합니다.
- Oracle Data Integrator 프로세스를 계속 실행할 수 있도록 DR 사이트에서 Oracle Data Integrator 저장소의 최근 복사본을 제공합니다.
- 해당 DR 사이트에서 이 저장소에 액세스할 수 있는 Oracle Data Integrator 에이전트를 보유하고 있습니다.
- 소스 및 대상 시스템에 액세스할 수 있거나 소스 및 대상 시스템의 복사본에 액세스할 수 있습니다.
특히 Oracle Data Integrator의 경우 검증해야 하는 토폴로지의 두 가지 요소가 있습니다.
- Oracle Data Integrator 작업 저장소의 IP 주소 또는 서버 이름은 Oracle Data Integrator 마스터 저장소에 저장됩니다. DR 사이트로 전환할 때 이름 또는 IP 주소가 변경되는 경우 Oracle Data Integrator를 시작하기 전에 이 정보가 업데이트되었는지 확인해야 합니다.
- 소스 및 대상 시스템의 IP 주소 또는 서버 이름은 작업 저장소에 저장됩니다. 두 가지 가능한 전략이 있습니다.
- 각 논리 장치에 대해 2개의 고유한 물리적 서버 정의를 가질 수 있는 각 환경(기본 및 DR) 에 대해 별도의 컨텍스트를 정의합니다.
- 또는 DR 사이트에서 Oracle Data Integrator를 시작하기 전에 IP 주소 또는 서버 이름을 덮어씁니다.
- 모든 경우에 Oracle Data Integrator 저장소의 정보를 덮어쓰는 SDK를 사용하는 모든 스크립트에는 기본 사이트의 정보를 복원하는 역방향 스크립트가 있어야 합니다.
초기 및 연속 로드에 대한 계획
고가는 대상 시스템의 초기 로드에 대해 약간 다른 프로세스를 설계해야 일반 로드(예: 실시간 또는 일별 일괄 처리) 에 집중할 수 있습니다.
이를 통해 예측하지 못한 추측 방지를 원하는 경우 이러한 초기 로드 프로세스를 유지하고 유지 관리하는 것이 중요합니다. 특히 다음과 같은 상황이 발생할 때 초기 로드(또는 부분 초기 로드) 를 재실행할 수 있는 기능이 없어야 합니다.
- 주요 결함은 로드된 데이터의 유효성에서 검색됩니다(데이터 누락, ETL에서 부적합한 공식 등).
- 대상 시스템에서 주요 운용중단이 발생하여 대량 데이터 손실이 발생합니다.
- 일부 이유로 인해 너무 오랫동안 통합 프로세스를 실행하지 못합니다.
초기 로드를 실행할 수 있는 기능도 있습니다. 또한 새 환경을 인스턴스화할 수 있습니다.
이전 로드(예: 이전 분기 데이터) 를 재적용하는 기능으로 이러한 로드 전략을 향상시킬 수도 있습니다. 이렇게 하려면 로드된 데이터의 부분 정리 및 부분 로드를 조합해야 합니다.