2 설치 계획

DIVAnet은 일반적으로 여러 DIVA 사이트에서 구성되는 분산된 응용 프로그램입니다. 이 장에서는 설치해야 할 DIVAnet 서비스 및 설치할 위치를 확인하는 데 필요한 개념에 대해 설명합니다. 세 가지 주요 단계는 다음과 같습니다.

1. 특정 사이트에 대해 원하는 워크플로우를 실현하기 위해 연결해야 하는 사이트를 이해해야 합니다. 사이트 연결 이해를 참조하십시오.

2. 시스템에서 각 사이트에 대해 원격 액세스(또는 로컬 액세스)를 사용으로 설정해야 합니다. 사이트에서 원격 액세스 사용으로 설정을 참조하십시오.

3. DIVAnet 워크플로우에 연결해서 로컬로 사용하는 클라이언트 응용 프로그램이 있는 사이트에서 로컬 클라이언트 액세스를 구성해야 합니다. 로컬 클라이언트 액세스 구성을 참조하십시오.

사이트 연결 이해

DIVAnet 사이트는 정확히 하나의 DIVArchive 설치(클라우드에 존재할 수 있음) 및 하나 이상의 DIVAnet 서비스로 정의됩니다. 각 사이트에는 고유한 사이트 이름이 지정됩니다. 각 DIVAnet 서비스는 DIVAnet 구성 파일에서 LocalSitename 매개변수로 표시된 특정 사이트에 속합니다. 로컬 클라이언트 액세스를 사용하거나 사용하지 않고도 여러 DIVAnet 사이트를 구성할 수 있습니다. DIVAnet 사이트는 서로 통신할 수 있으며 상대 사이트의 정보를 서로 복제할 수 있습니다.

DIVAnet 연결의 가장 기본적인 유형은 DIVAnet을 단일 DIVArchive 시스템에 대한 단순 DIVArchive 프록시로 사용하는 것입니다. 이 구성에서는 DIVAnet Direct 모드가 사용됩니다. DIVA API 연결에서 작업을 허용 또는 거부하도록 액세스 규칙을 구성할 수 있습니다. 이 모드는 여러 사이트의 통합 뷰를 제공하지 않으며, 예를 들어, 사이트 간 복사를 위해 사용할 수 없습니다. DIVAnet Direct 모드 설정에 대한 자세한 내용은 클라이언트 API 포트 구성을 참조하십시오.

여러 DIVA 사이트를 실제로 하나의 대형 아카이브 시스템으로 처리할 수 있으려면 DIVAnet 서비스를 사용해서 DIVAnet 사이트를 하나로 연결해야 합니다. 이 장의 남은 절에서는 아카이브된 컨텐츠의 통합 뷰를 얻기 위해 DIVAnet을 구성하는 방법에 대해 설명합니다.

DIVAnet은 원격 사이트에 연결하여 자산 정보를 검색하고, 원격 사이트의 상태를 모니터하고, 사이트에 요청(예: 복원 요청)을 전송하고, DIVAnet 레벨 요청을 충족시킬 수 있습니다. 이러한 다양한 상호 작용을 통해 DIVAnet은 하나의 대형 아카이브 시스템으로 작동할 수 있습니다.

주:

일부 DIVAnet 배치에서는 각 사이트를 네트워크의 다른 사이트에 연결할 필요가 없습니다.

다음 그림은 뉴욕, LA 및 달라스 세 개의 사이트에 배치된 일반적인 DIVAnet 예를 보여줍니다. 이 예에서 뉴욕에 있는 응용 프로그램은 LA 및 달라스에서 자산(그리고 뉴욕에 있는 기존 자산)을 확인하고 복사할 수 있습니다. 또한 LA에 있는 응용 프로그램은 뉴욕 및 달라스에서 자산을 확인하고 복사할 수 있습니다. 달라스 사이트에서는 실행되는 응용 프로그램이 없습니다.

이 배치를 실현하기 위해서는 사이트에 대해 원격 액세스를 구성합니다. 달라스는 지원할 로컬 클라이언트가 없으므로, 이러한 시나리오를 보여주는 훌륭한 예입니다. 여기에서는 달라스가 뉴욕에 연결된 방식을 확인할 수 있습니다. 그런 다음 클라이언트 액세스를 위해 사이트를 구성하는 방법을 살펴보고, 뉴욕 및 LA를 조사하고, 이러한 사이트가 연결된 방식을 확인합니다.

DIVAnet 서비스

DIVAnet 서비스는 DIVAnet 배치에서 컴퓨팅 작업을 수행할 책임이 있는 서버에 설치된 Windows 또는 Linux 서비스입니다. 테이블 2-1에서는 사용 가능한 DIVAnet 서비스 요약을 보여줍니다.

테이블 2-1 DIVAnet 서비스

서비스	설명
Client Adapter	DIVAnet ClientAdapter 서비스는 DIVA API 및 웹 서비스에서 요청을 수락하고 DIVArchive 사이트 및 DIVAnet 데이터베이스와 상호 작용하여 이러한 요청을 충족시킵니다. 이 서비스는 로컬 클라이언트(응용 프로그램) 액세스를 구현할 때 구성됩니다. 이 서비스는 또한 최소한의 프록시 전용 DIVAnet 배치에서도 사용할 수 있습니다(DIVAnet Direct 모드, 클라이언트 API 포트 구성에서 설명). 자세한 내용은 DIVAnet ClientAdapter 서비스를 참조하십시오.
Manager Adapter	ManagerAdapter 서비스는 DIVAnet과 Oracle DIVArchive Manager 사이의 브리지 역할을 수행합니다. 이 서비스는 DIVA 사이트에 대한 원격 액세스를 제공합니다. 특히 자산 정보가 동기화되는 사이트를 포함해서 모든 DIVAnet 사이트에 대해 구성됩니다. 자세한 내용은 DIVAnet ManagerAdapter 서비스를 참조하십시오.
DB Sync	DbSync 서비스는 여러 DIVArchive 사이트에서 자산 정보를 동기화하고 이 정보를 DIVAnet 데이터베이스에 저장합니다. 이 서비스는 로컬 클라이언트(응용 프로그램) 액세스를 구현할 때 구성됩니다. 자세한 내용은 DIVAnet DbSync 서비스를 참조하십시오.

사이트에서 원격 액세스 사용으로 설정

DIVArchive 사이트에서 다른 DIVAnet 시스템의 원격 액세스를 사용으로 설정하려면 해당 사이트에서 ManagerAdapter 서비스를 설정하고 DIVArchive에서 원격 액세스를 구성해야 합니다.

다음 그림은 전체 DIVAnet 구성을 포함하는 뉴욕 사이트(원격 액세스 및 로컬 클라이언트 액세스)와 원격 액세스만 구성되는 달라스 사이트의 예를 보여줍니다. 달라스 사이트에서는 실행되는 DIVAnet 서비스가 ManagerAdapter 서비스 하나만 있습니다. DIVArchive는 다른 사이트와 올바르게 상호 작용할 수 있도록 구성되어 있습니다.

DIVAnet ManagerAdapter 서비스

ManagerAdapter 서비스는 DIVAnet과 DIVArchive Manager 사이의 브리지 역할을 수행합니다. 다른 DIVAnet 시스템의 원격 액세스를 제공하도록 구성해야 합니다. 보안 및 성능상의 이유로, Oracle은 ManagerAdapter를 DIVArchive Manager와 동일한 시스템에 설치할 것을 권장합니다. 마찬가지로, ClientAdapter 및 DIVAnet 데이터베이스는 완전히 다른 서버에서 하나로 실행되는 경우가 많습니다. ManagerAdapter는 간단한 구성 파일을 사용해서 구성됩니다. 자세한 내용은 제 4 장을 참조하십시오.

DIVArchive

DIVAnet 워크플로우를 실현하기 위해 필요한 구성 중 대부분은 각 DIVArchive 사이트에서 수행됩니다. 이 절에서는 DIVAnet이 DIVA와 상호 작용하는 방법 및 DIVA 구성의 중요성을 이해하는 데 필요한 일부 개념에 대해 자세히 설명합니다. DIVArchive 구성 방법에 대한 자세한 내용은 Oracle DIVArchive Installation and Configuration Guide를 참조하십시오.

객체 및 인스턴스

DIVArchive 시스템에서 아카이브된 객체는 두 가지 매개변수인 객체 이름 및 객체 범주를 통해 고유하게 식별됩니다. 범주는 이름 공간과 비슷한 객체의 공식 이름의 일부입니다. 예를 들어, 이름이 CLIP01이고 범주가 MOVIES인 객체는 이름이 CLIP01이고 범주가 COMMERCIALS인 객체와 다른 객체입니다.

DIVAnet은 객체 이름 및 범주를 사용해서 여러 사이트에서 객체를 연관시킵니다.

주:

한 사이트의 객체가 다른 사이트의 객체와 객체 이름 및 범주가 동일하면 DIVAnet이 이 둘을 동일한 객체로 고려합니다.

DIVAnet을 사용해서 자산을 아카이브하는 경우 DIVAnet에서는 (기본적으로) 다른 사이트에서 이미 아카이브된 자산과 동일한 이름(및 범주)을 갖는 새 자산을 거부합니다. 그러나 DIVArchive 시스템으로 직접 실행되는 아카이브는 이 방법으로 검사되지 않습니다. DIVAnet을 사용하지 않고 아카이브를 수행하면 다른 B 사이트의 객체가 A 사이트의 해당 객체와 다른 컨텐츠를 포함하게 될 수 있습니다. 따라서 DIVAnet이 잘못된 컨텐츠를 복원할 수 있습니다.

DIVArchive에서 아카이브된 각 객체는 테이프 또는 디스크에서 객체의 각 물리적 복사본에 대해 하나씩 여러 인스턴스를 포함할 수 있습니다. 각 인스턴스에 대해서는 인스턴스 순서 번호가 있습니다. 이러한 번호 매김은 0부터 시작하며, 객체의 각 인스턴스에 대해 1씩 증분됩니다. 따라서, 객체 이름, 범주 및 인스턴스 순서 번호를 제공하여 DIVA 시스템에서 인스턴스를 고유하게 참조할 수 있습니다.

DIVAnet은 DIVArchive 인스턴스 순서 번호로부터 파생되는 인스턴스 순서 번호의 고유 세트를 지정합니다. 이렇게 하면 각 객체에 대해 DIVAnet 인스턴스 순서 번호가 모든 DIVAnet 사이트에서 고유하게 됩니다.

소스 및 대상

DIVArchive Source/Destination에는 DIVArchive 외부의 고객 서버 또는 디스크와 통신하는 데 필요한 정보가 포함되어 있습니다. 고객은 이러한 서버 및 디스크를 통해 DIVArchive에 대해 컨텐츠를 전송할 수 있습니다.

DIVAnet에는 Source/Destination 이름과 관련하여 중요한 규칙이 적용됩니다.

주:

한 사이트의 Source/Destination이 다른 사이트와 동일한 이름을 사용할 경우, DIVAnet은 이러한 두 항목이 동일한 물리적 서버 및 디스크를 참조하는 것으로 간주합니다.

이러한 규약은 DIVAnet 시스템을 설정할 때 중요합니다(자세한 내용은 복원 워크플로우 참조). API를 통해 Source/Destinations를 주소 지정할 수 있고, 이러한 항목들이 동일한 물리적 서버, 디스크 및 경로를 가리킬 경우에는 이들 항목에 동일한 이름을 지정해야 합니다.

전송 Source/Destinations 설정

DIVAnet을 사용해서 한 사이트에서 다른 사이트로 컨텐츠를 전송하려면, 하나 이상의 Source/Destination을 두 사이트에서 액세스할 수 있도록 구성합니다. 이러한 공통 Source/Destination은 DIVAnet이 한 사이트에서 다른 사이트로 객체를 복사하는 데 사용됩니다. 두 사이트에서 Source/Destination 구성은 다음과 같은 특성을 가져야 합니다.

• 동일한 이름 - 모든 사이트에서 동일한 물리적 서버, 디스크 및 디렉토리를 참조하는 Source/Destinations에 대해 동일한 이름을 구성해야 합니다.

  DIVAnet의 사이트 간 매핑은 동일한 위치를 참조하지만 반드시 동일한 이름으로 지정되지는 않는 Source/Destinations를 처리할 수 있습니다. 자세한 내용은 사이트 간 매핑을 참조하십시오.

• 동일한 장소 - 두 Source/Destination 항목은 서버의 디스크에서 정확히 동일한 위치(경로)를 가리켜야 합니다. 전송 유형(예: FTP_STANDARD, DISK)은 각 사이트마다 다를 수 있으며, 구성에서도 다른 루트 경로가 포함될 수 있습니다. 예를 들어, 이름이 NY_SHOWS인 Source/Destination은 뉴욕 사이트에서 DISK 유형일 수 있지만 LA 사이트에서는 FTP 유형일 수 있습니다.

• 트랜스코드 또는 이름 바꾸기 없음 - 사이트 간 복사에 사용된 Source/Destinations의 경우, Source/Destination에서 복원 시 트랜스코딩을 구성하지 마십시오. 이렇게 하면 잘못된 컨텐츠가 DIVA 사이트에 아카이브될 수 있습니다.

• 소스에서 삭제 - 복사 명령에 사용되는 각 Source/Destination에 대해 DIVArchive Source/Destination 구성에서 -allow_delete_on_source를 설정합니다. 이렇게 하면 DIVA에 전송된 후 사이트에서 컨텐츠가 삭제되도록 허용합니다. 이 옵션은 DIVA의 Source/Destination 구성 패널의 옵션 필드에 제공합니다.

• AXF 및 체크섬 - DIVArchive에서 AXF Genuine Checksums를 사용으로 설정하여 사이트 간 복사(한 사이트에서 다른 사이트로의 복사 작업)에 대해 엔드 투 엔드 체크섬 비교를 사용으로 설정할 수 있습니다. DIVArchive Configuration Utility에서 복사에 사용하는 Source/Destination을 선택한 후 AXF Genuine Checksum 옵션을 선택합니다. 이렇게 한 후에는 DIVAnet 사이트 간 매핑 AdditionalOptions 매개변수에 -axf 옵션을 설정할 수 있습니다. 그러면 소스 사이트에서 AXF 래퍼에 체크섬 정보를 포함하고, 대상 사이트에서 다시 검사를 수행할 수 있습니다.

DIVArchive Configuration Utility의 Source/Destination 패널에 있는 Site 매개변수와 혼동하지 마십시오. 이 사이트 이름은 DIVA에서만 사용되며, DIVAnet 사이트에 해당되지 않습니다(자세한 내용은 Oracle DIVArchive Installation and Configuration Guide 참조).

주의:

DIVAnet에 연결되었을 때 DIVArchive 구성 매개변수의 이름(예: Source/Destinations, Media Names 및 Storage Plans)을 수정하면 오류가 발생할 수 있습니다.

매체(스토리지 매체) 및 스토리지 계획

DIVAnet이 한 DIVA 시스템에서 다른 시스템으로 객체를 복사할 때는 대상 사이트에서 복사의 아카이브 Media Name 및 Storage Plan Name을 지정할 때 주의해야 합니다. 각 DIVA 시스템에서 매체 값과 관련해서 올바른 이름 지정 정책을 사용하십시오.

DIVAnet은 각 객체 인스턴스를 동기화할 때 DIVA 매체 이름을 기록합니다. 복사 작업에서 매체/스토리지 계획을 자동으로 지정하도록 DIVAnet을 구성할 수 있습니다. 자세한 내용은 DIVAnet에서 선택(any 매체)을 참조하십시오. 이 기능을 구성하는 방법 중 하나는 소스 객체와 동일한 스토리지 계획 이름을 사용해서 대상 사이트에 아카이브하는 것입니다. 이렇게 하려면 대상 DIVA에서 적절한 스토리지 계획을 구성해야 합니다. 또는 DIVA 매체 매핑을 사용해서 모든 대상 DIVA 사이트에서 스토리지 계획 이름을 매체 또는 다른 스토리지 계획으로 변환할 수 있습니다.

DFM(드롭 폴더 모니터)

DFM은 폴더에서 새로운 컨텐츠를 모니터한 후 새로운 컨텐츠를 DIVArchive로 아카이브합니다. DFM은 특정 드롭 폴더로 복원하는 방식으로 컨텐츠를 선택하고 이를 다른 DIVA 시스템에 아카이브합니다.

DIVAnet은 DFM 없이도 복사 워크플로우를 구현할 수 있지만, 일부 경우에는 DFM이 필요하거나 적합할 수 있습니다. 혼합 환경에서 DFM 없이 복사하려는 경우에는 DIVAnet RestoreAndArchive 전송 방법을 사용할 수 있습니다. 하지만 DFM을 사용하는 것이 적합한 경우도 있습니다. DFM을 사용하는 것이 적합한 경우로는 전송이 실패한 컨텐츠에 대해 고유 정리를 수행하려는 자율 사이트 또는 타사 WAN 가속기가 사용되는 시스템을 들 수 있습니다. 전송을 위해 DFM을 사용하려면 DIVAnet RestoreAndMonitor 사이트 간 전송 방법을 사용합니다. 자세한 내용은 사이트 간 전송 매핑(워크플로우 프로파일)을 참조하십시오.

로컬 클라이언트 액세스 구성

로컬 클라이언트 액세스를 구성하려면 다음 항목들을 구성해야 합니다.

• 원격 액세스를 위한 로컬 DIVArchive(사이트에서 원격 액세스 사용으로 설정 참조)

• ClientAdapter 서비스

• DbSync 서비스

• DIVAnet 데이터베이스

모든 DIVAnet 서비스를 구성하면 사이트에서 전체 DIVAnet 워크플로우 처리를 사용으로 설정할 수 있습니다.

다음 그림에서는 뉴욕 및 LA 사이트가 모두 전체 DIVAnet 워크플로우 처리를 위해 구성됩니다. LA 응용 프로그램은 LA의 ClientAdapter에 직접 연결할 수 있습니다. 이렇게 하면 필요에 따라 뉴욕에서 컨텐츠를 검색할 수 있습니다. 로컬 DIVAnet 데이터베이스는 한 사이트에서 다른 사이트로의 연결이 끊기더라도 사이트 간 전역 자산 뷰를 제공합니다. 충분한 권한이 부여된 경우, LA의 DIVAnetUI 사용자는 뉴욕에서 LA로 컨텐츠를 복사할 수 있으며, 뉴욕에서 컨텐츠를 삭제할 수도 있습니다.

뉴욕의 ClientAdapter에 원격으로 연결되도록 Customer App 2를 구성하는 것이 기술적으로 가능하지만, 이러한 구성은 더 나은 가용성, 보안 및 감사 성능을 제공하는 경우가 많습니다. 특히 안정적이지 않거나 느린 WAN 링크에서는 성능과 확장성도 향상되는 경우가 많습니다.

DIVAnet ClientAdapter 서비스

DIVA API를 사용하거나, DIVAnet GUI를 사용하려는 응용 프로그램 클라이언트는 DIVAnet ClientAdapter 서비스에 연결됩니다. 이 DIVAnet 서비스는 응용 프로그램으로부터 웹 및 소켓 연결을 수락하고 요청을 처리합니다. ClientAdapter는 DIVArchive 및 DIVAnet이 설치된 사이트에 대해 로컬인 응용 프로그램이 있는 각 사이트에서 구성됩니다. ClientAdapter는 ManagerAdapter 서비스를 통해 로컬 및 원격 사이트와 통신합니다. ClientAdapters는 또한 소켓 모드를 사용해서 DIVArchive Manager에 직접 연결될 수도 있습니다.

ClientAdapter 서비스는 1개(또는 2개)의 구성 파일을 사용해서 구성됩니다(자세한 내용은 제 4 장 참조).

DIVAnet DbSync 서비스

DbSync 서비스는 여러 DIVArchive 사이트에서 자산 정보를 동기화하고 이 정보를 DIVAnet 데이터베이스에 저장합니다. DbSync는 여러 사이트에서 ManagerAdapter 서비스와 원격으로 통신하여 아카이브된 객체 정보를 동기화합니다. DbSync는 일반적으로 ClientAdapter와 함께 배치됩니다. DbSync 서비스 및 ClientAdapter는 모두 DIVAnet 데이터베이스에 대한 직접 액세스가 필요합니다.

DbSync 서비스는 단순 구성 파일을 사용해서 구성됩니다(자세한 내용은 제 4 장 참조).

표시 전용 사이트

사이트를 표시 전용으로 구성할 수 있습니다. 즉, 사이트의 자산 정보가 동기화되지만, 요청(또는 그 외 다른 메시징)이 사이트로 전송되지 않도록 구성할 수 있습니다. 이 사이트(예: diva4 사이트)는 ClientAdapter 구성이 아닌 DbSync 구성 파일에서 구성합니다. diva4 사이트는 표시 전용이 됩니다. 이 사이트의 자산 정보는 UI 및 정보용 API 호출로 질의할 수 있지만, 사이트로 전송되는 요청(DIVAnet 사용)은 거부됩니다.

DIVAnet 데이터베이스

DIVAnet 로컬 클라이언트 액세스를 구성할 때는 DIVAnet 데이터베이스 설정이 포함됩니다.

객체 정리

DIVAnet은 일부 경우에 복원을 수행하기 전 원격 사이트에서 로컬 사이트로 객체를 임시로 복사하여 복원 작업을 충족시킵니다. 이렇게 하면 이후의 컨텐츠 복원이 훨씬 더 빠르게 수행됩니다. DIVAnet은 복원 후 디스크 인스턴스를 자동으로 삭제하지 않습니다. 대신, 나중에 이를 복원하려는 경우를 위해 컨텐츠를 남겨둡니다.

DIVArchive에는 지정된 디스크/어레이가 가득 찼을 때 컨텐츠를 자동으로 정리할 수 있는 두 가지 도구가 있습니다.

• Oracle DIVArchive SPM(Storage Plan Manager)에는 개별 DIVA 사이트에 대해 디스크 인스턴스를 자동으로 정리할 수 있는 기능이 있습니다.

• DIVArchive Local Delete는 비슷한 기능을 수행할 수 있지만, 객체가 다른 DIVA 사이트에도 존재하는지를 선택적으로 확인할 수 있습니다.

DIVArchive는 기본적으로 니어라인 디스크 인스턴스를 만들도록 구성되기 때문에, DIVAnet 원격 액세스 전용으로 구성된 DIVA 사이트에서 객체 정리를 수행해야 할 수도 있습니다.

DIVAnet 버전 호환성

DIVAnet 2.1은 DIVArchive 7.3.1 이상과 연동됩니다. DIVAnet을 최신 릴리스로 업그레이드하지 않을 경우 DIVAnet에서 DIVArchive의 이후 릴리스에 통합된 일부 기능에 액세스하지 못할 수 있습니다.

DIVAnet 2.1 ClientAdapter 및 DbSync 서비스는 DIVAnet 2.0 ManagerAdapter와 함께 연동되지만, 한 가지 예외사항이 있습니다. DIVAnet 프록시 모드(DIVAnet 데이터베이스를 사용하지 않는 직접 모드)가 DIVAnet 2.0 ManagerAdapter에 연결되지 않습니다.