인프라 유지보수 정보

Oracle은 Oracle Data Infrastructure Cloud@Customer에서 Oracle이 관리하는 모든 인프라 구성요소를 정기적으로 업데이트합니다.

Oracle은 모범 사례를 따르는 자동화된 프로세스를 사용하여 제품 픽스 및 보안 픽스를 적용합니다. 이 업데이트는 데이터를 보호하고 데이터베이스 가용성, 무결성, 보안 및 Oracle Cloud 규제준수 요구사항을 지원하는 데 도움이 됩니다. 또한 자동화된 유지보수는 인프라 유지 관리에 필요한 작업도 줄여줍니다.

Oracle 관리 구성 요소에는 물리적 서버 호스트, 스토리지, 네트워크 카드, ILOM(Integrated Lights Out Management) 인터페이스 및 제어 플레인 프록시 서비스 VM이 포함될 수 있습니다.

Oracle은 3개월마다 분기별 유지보수를 수행하며 제품 수정, 개선사항 및 보안 수정사항을 포함할 수 있습니다.

Oracle은 드문 예외적인 경우를 제외하고 일정이 잡힌 유지보수에 대한 사전 통지를 제공합니다. 또한 Oracle은 VM 클러스터의 VM에 해당하는 권장 업데이트에 대한 통지를 제공합니다.

Oracle은 가능한 경우 서비스 가용성을 유지하기 위해 유지 관리 일정을 잡습니다. 일부 업데이트는 개별 구성 요소를 사용할 수 없는 동안 성능 및 처리 능력에 일시적으로 영향을 줄 수 있습니다. 예를 들어, 서버 패치 적용에는 일반적으로 재시작이 필요합니다. Oracle은 가능한 경우 롤링 시퀀스로 서버를 재시작하므로 갱신 프로세스 중에 서비스를 계속 사용할 수 있습니다. 재시작하는 동안 짧은 시간 동안 각 서버를 사용할 수 없으므로 전체 서비스 용량이 줄어듭니다. 응용 프로그램에서 재시작을 허용할 수 없는 경우 완화를 계획합니다. 예를 들어, 서버 패치를 적용하는 동안 응용 프로그램을 종료합니다.

분기별 유지보수

Oracle은 업데이트 프로세스 전반에 걸쳐 데이터베이스 가용성을 유지하는 롤링 유지 관리 작업을 사용하여 분기별 유지 관리가 애플리케이션에 미치는 영향을 최소화합니다. 고가용성을 위해 설계된 애플리케이션은 중단 없이 데이터베이스 연결을 사용 가능한 인스턴스로 자동 투명하게 마이그레이션하므로 다운타임을 예약할 필요가 없습니다.

Oracle은 Oracle 정의 유지보수 정책에 따라 유지보수 일정을 잡습니다. 예상치 않은 업무 요구 사항이 발생하면 유지 관리 일정을 조정할 수 있습니다.

기본적으로 인프라 유지보수는 롤링 업데이트를 사용하여 서버부터 스토리지를 업데이트한 후 수행됩니다.

서버는 한 번에 하나씩 업데이트되며, 항상 최대 하나의 서버가 오프라인 상태입니다. 각 호스트에 대해 VM이 종료되고, 서버가 업데이트 및 다시 시작되고, VM이 시작되고, 다른 서버는 작동 상태로 유지됩니다. 이 접근 방식은 고가용성을 위해 설계된 애플리케이션에는 영향을 주지 않지만 롤링 인스턴스 재시작을 처리하도록 작성되지 않은 이전 애플리케이션에는 영향을 줄 수 있습니다. 이 프로세스는 두 서버가 모두 업데이트될 때까지 계속됩니다.

서버 유지 관리가 완료되면 스토리지 유지 관리가 시작됩니다. 스토리지 디스크는 한 번에 하나씩 업데이트됩니다. 패치 저장 영역은 데이터베이스 가용성에 영향을 주지 않으므로 응용 프로그램에 영향을 주지 않습니다. 그러나 롤링 스토리지 유지 관리는 스토리지 디스크가 오프라인 상태(사용 가능한 I/O 용량 감소)이고 서비스로 돌아간 후 재동기화되는 동안(데이터 인프라 서버의 오버헤드가 적음) I/O 성능을 줄일 수 있습니다. 유지 관리 대상이 아닌 서버에 대한 추가 작업을 수용하도록 데이터베이스 및 스토리지의 크기를 적절히 조정하면 성능에 미치는 영향을 최소화하거나 제거할 수 있습니다.

롤링 유지보수 동안 데이터베이스를 사용할 수 있어야 하지만 자동 유지보수는 Oracle Clusterware가 실행 중인지 확인하지만 서버가 다시 온라인으로 전환된 후 모든 데이터베이스 서비스 및 PDB(플러그인할 수 있는 데이터베이스)를 사용할 수 있는지 확인하지 않습니다. 유지보수 후 데이터베이스 서비스 및 PDB의 가용성은 서비스 정의에 따라 달라질 수 있습니다. 예를 들어, 선호 노드와 사용 가능한 노드로 구성된 데이터베이스 서비스는 유지 관리 중에 재배치될 수 있으며 유지 관리가 완료된 후 원래 노드로 자동으로 재배치되지 않을 수 있습니다. Oracle은 잠재적인 영향을 줄이기 위해 애플리케이션의 지속적인 가용성에 관한 문서를 검토할 것을 권장합니다. 지침에 따라 서버가 순차적으로 업데이트되므로 인프라 유지보수의 영향을 경미한 서비스 성능 저하로 제한해야 합니다.

Oracle은 MAA(Maximum Availability Architecture) 모범 사례를 따르고 Data Guard를 사용하여 중요한 응용 프로그램의 고가용성을 보장할 것을 권장합니다. Data Guard가 사용으로 설정된 데이터베이스의 경우 Oracle은 기본 및 대기 데이터베이스를 실행하는 데이터 인프라의 유지보수 기간을 구분할 것을 권장합니다. 인프라 유지보수 동안 기본 데이터베이스에 미치는 영향을 방지하기 위해 기본 데이터베이스를 호스팅하는 데이터 인프라에 대한 유지보수 전에 전환을 수행할 수도 있습니다.

유지보수 기간이 유지보수 성공을 방해할 수 있는 문제를 식별하기 시작하기 전에 Oracle Data Infrastructure Cloud@Customer 인프라 구성요소에 대해 사전 검사가 수행됩니다. 사전 검사 중에는 인프라 및 모든 구성 요소가 온라인 상태로 유지됩니다. 초기 사전 검사는 유지보수가 시작되기 약 2주 전에 실행되고, 다른 사전 검사는 유지보수가 시작되기 약 24시간 전에 실행됩니다. 사전 검사에서 일정 조정이 필요한 문제를 식별하면 통지를 구독한 사용자에게 통지가 전송됩니다.

유지보수 기간 최소화