Ooyala Flex 하드웨어 사양

Ooyala Flex 하드웨어 권장 사항은 Ooyala Flex 빌드의 일부분으로 사용하도록 제시되는 추천 항목 세트입니다.

하드웨어

아래에는 Ooyala Flex용 하드웨어/클라우드 리소스 제공을 위한 대략적인 지침이 나와 있습니다.

Ooyala Flex 관리자 노드:

• 4개 CPU

• 4GB RAM

• 50GB 디스크 공간

Ooyala Flex 인덱스 노드:

• 2개 CPU

• 4GB RAM

• 50GB 디스크 공간

Ooyala Flex 게시 노드:

• 2개 CPU

• 4GB RAM

• 50GB 디스크 공간

Ooyala Flex 전송 노드

• 2GB RAM

이 노드의 디스크 공간 제공량은 인제스트하는 자산의 최대 크기에 따라 달라집니다. 전송 리소스 노드에는 로컬에서 전송 중인 모든 파일이 저장되므로, 이 노드는 가장 큰 자산과 전송 중인 다른 파일을 합한 크기에 해당하는 파일을 저장할 수 있을 정도로 커야 합니다. 파일 시스템 및 어플리케이션 오버헤드는 20GB 이하이므로 자산이 10GB보다 작으며 3개를 초과하는 파일의 병렬 전송 인제스트를 수행하는 경우가 아니면 디스크 공간은 50GB이면 충분합니다. 최소 50GB의 디스크 공간을 제공하고, 정기적으로 큰 파일을 전송하는 경우에는 공간을 추가로 제공하는 것이 좋습니다.

저장소

Ooyala Flex는 복원이 가능하도록 설계되어 있지만, Ooyala Flex를 복원하려는 경우에는 사용하도록 선택한 저장소 역시 복원이 가능해야 합니다. 복원 가능한 저장소는 다음과 같이 제공할 수 있습니다.

• 복원 가능 NAS/전용 어플라이언스(예: EMC Isilon, Oracle ZFS Storage)

• NetApp CIFS + NFS 공유

• Amazon S3

클러스터링과 관련된 인덱스 및 기타 파일을 저장할 수 있도록 Ooyala Flex 노드 간에 저장소를 공유해야 합니다. 이러한 이유로 인해 Amazon S3과 같은 클라우드 저장소를 사용할 수는 없으며, 성능을 고려할 때 NFS 공유를 사용하는 것이 좋습니다. Amazon AWS 또는 Rackspace와 같은 클라우드 환경에서 Ooyala Flex 환경을 설정할 때는 단일 실패 지점이 없도록 해야 하는데, EBS(Amazon) 및 CBS(Rackspace)의 경우 한 번에 하나의 서버만 액세스할 수 있습니다. 이러한 위험을 방지할 수 있는 방법 중 하나는 GlusterFS와 같은 클러스터된 파일 시스템을 사용하는 것입니다. 이러한 방식은 Ooyala에서 직접 테스트한 것은 아니며 단순한 제안 사항일 뿐입니다.

복원 기능

Ooyala Flex의 복원 기능과 관련된 또 다른 중요한 요소는, 인덱스 노드를 제외한 모든 노드가 다른 노드 실패 시에도 계속 작동 가능한 독립 노드 또는 클러스터로 실행된다는 점입니다. 따라서 가능한 경우에는 노드를 다른 호스트(VMware) 또는 다른 가용성 영역(Amazon) 등으로 분할하는 것이 좋습니다. 이러한 방식을 보여 주는 간소화된 기본 하드웨어 구성의 예로 교차 연결된 개별 네트워크 스위치 두 개를 사용하는 경우를 들 수 있습니다.

네트워킹

아래에는 전체 Ooyala Flex 스택(관리자, 게시, 전송 리소스)의 네트워킹 설정에 대한 대략적인 지침이 나와 있습니다.

부하 분산 장치를 사용하여 Ooyala Flex Console용으로 복원 가능한 종점을 제공하는 것이 좋습니다. 전용 부하 분산기가 없어도 Apache 및 CARP를 사용하여 이러한 종점을 설정할 수는 있습니다. 그러나 Amazon과 같은 특정 호스팅 환경/클라우드 환경에서는 CARP를 사용할 수 없습니다. 이러한 환경에서는 Riverbed SteelApp(이전 명칭 Stingray) 부하 분산 장치를 사용하는 것이 좋습니다. 그러면 Amazon ELB 솔루션과 함께 Ooyala Flex를 정상적으로 실행할 수 있습니다. Amazon에서 Ooyala Flex를 설정할 때는 Ooyala Flex Console과 게시 종점용으로 각각 하나씩 두 개의 ELB 인스턴스가 필요합니다.

환경을 잠글 때는 부하 분산 장치 및 FTP 리소스 노드를 DMZ에 배치하는 것이 좋습니다. Amazon에 배포할 때는 DMZ에 NAT 인스턴스도 필요할 가능성이 높습니다.

• TCP가 아닌 UDP를 통해 '가속 전송'을 사용하는 경우에는 FTP를 통해 전송 리소스 노드에 직접 액세스해야 합니다.

• 게시용으로 CDN을 사용하는 경우에는 관리자 노드와 게시 노드 둘 다에 CDN에 대한 아웃바운드 액세스 권한이 필요합니다.

• 게시 및 전송 리소스 노드는 부하 분산된 Ooyala Flex Console 종점을 사용하여 관리자와 통신해야 합니다. 관리자는 http를 통해 게시 종점 및 모든 전송 리소스 노드(이러한 노드는 공유 종점을 포함하지 않으며 클러스터가 아닌 단순한 중복 쌍임)와 통신합니다.

아웃바운드 액세스가 완전히 잠긴 상태에서 관리자 전용 Ooyala Flex 스택을 실행할 수 있습니다. 단, Ooyala Flex는 NEM 배포 도구를 통해서만 배포할 수 있으며 이 도구를 사용하려면 Ooyala의 패키지 및 SVN 리포지토리에 액세스해야 합니다. 이 도구 사용을 위한 VPN 액세스 권한은 Ooyala에서 제공해 드립니다.

데이터베이스

Ooyala Flex는 관계형 데이터 저장을 위해 MySQL을 사용합니다. DB 솔루션용으로 충분한 메모리를 제공하고, InnoDB 버퍼 풀에서 최대한 많은 메모리를 사용할 수 있도록 해야 합니다. 최소 8GB RAM을 제공하는 것이 좋습니다. 매일 수백 개의 자산을 인제스트하고 복잡한 워크플로를 수행할 것으로 예상되는 경우에는 사용 가능한 RAM이 매우 빠르게 소진될 수 있으므로 데이터베이스용으로 SSD 저장소 솔루션을 사용하는 것이 좋습니다.

복원 기능을 제공하기 위해 현재 지원되는 솔루션은 복제 슬레이브를 사용하고 기본 DB 서버에 문제가 발생할 때 해당 슬레이브로 장애 조치(failover)하는 방식뿐입니다. 마스터 DB 서버에 오류가 발생하는 경우 슬레이브 DB에서 Ooyala Flex를 실행할 수 있어야 하므로, 마스터 필요한 것과 정확히 동일한 양의 리소스를 제공해야 합니다. Ooyala Flex는 MySQL 5.6 이상 버전과 InnoDB 저장소 엔진만을 지원합니다. 이러한 용도로 NDB MySQL Cluster 솔루션을 사용할 수는 없습니다. 복제 슬레이브를 사용할 때는 MySQL binlog 형식을 ROW로 설정해야 합니다(기본값은 STATEMENT임).