메트로-DR 확장 클러스터용 OpenShift Data Foundation 구성
재해 복구 기능을 제공하는 스토리지 인프라를 제공하기 위해 두 가지 지리적 위치 간에 OpenShift Data Foundation을 구성하는 방법에 대한 지침.
초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견을 보내 주십시오. 어떻게 하면 더 잘할 수 있는지 알려주십시오. 피드백을 제공하려면 다음을 수행합니다.
특정 문구에 대한 간단한 의견 작성 방법은 다음과 같습니다.
- 문서가 Multi-page HTML 형식으로 표시되는지 확인합니다. 또한 문서 오른쪽 상단에 피드백 버튼이 있는지 확인합니다.
- 마우스 커서를 사용하여 주석 처리하려는 텍스트 부분을 강조 표시합니다.
- 강조 표시된 텍스트 아래에 표시되는 피드백 추가 팝업을 클릭합니다.
- 표시된 지침을 따릅니다.
보다 상세하게 피드백을 제출하려면 다음과 같이 Bugzilla 티켓을 생성하십시오.
- Bugzilla 웹 사이트로 이동하십시오.
- 구성 요소 섹션에서 문서 를 선택합니다.
- 설명 필드에 문서 개선을 위한 제안 사항을 기입하십시오. 관련된 문서의 해당 부분 링크를 알려주십시오.
- 버그 제출을 클릭합니다.
1장. Metro-DR 확장 클러스터 소개
Red Hat OpenShift Data Foundation 배포는 두 개의 지리적 위치 사이에서 확장되어 스토리지 인프라에 재해 복구 기능을 제공할 수 있습니다. 두 위치 중 하나와 같은 재해에 문제가 있거나 부분적으로 또는 완전히 사용할 수 없는 경우 OpenShift Container Platform 배포에 배포된 OpenShift Data Foundation은 그대로 유지해야 합니다. 이 솔루션은 인프라 서버 간에 특정 대기 시간 요구 사항이 있는 데이터 센터에만 사용할 수 있습니다.
현재 다른 위치에 있는 OpenShift Container Platform 노드 간에 대기 시간 4밀리초(RTT)를 초과하지 않는 스트레치 클러스터를 사용하여 메트로-DR 솔루션을 배포할 수 있습니다. 대기 시간이 길어지는 경우 Red Hat 고객 지원에 문의하십시오.
다음 다이어그램은 Metro-DR 확장 클러스터에 대한 가장 간단한 배포를 보여줍니다.
OpenShift 노드 및 OpenShift Data Foundation 데몬
다이어그램에서 OpenShift Data Foundation 모니터는 Arbiter 영역에 배포된 Pod에 마스터 노드에 대한 허용 오차가 내장되어 있습니다. 다이어그램은 고가용성 OpenShift Container Platform 컨트롤 플레인에 필요한 각 데이터 영역의 마스터 노드를 보여줍니다. 또한 영역 중 하나의 OpenShift Container Platform 노드에 있는 OpenShift Container Platform 노드가 다른 두 영역의 OpenShift Container Platform 노드와 네트워크로 연결되어 있어야 합니다.
2장. 재해 복구가 활성화된 스토리지 클러스터 배포 준비
2.1. 메트로 - DR 활성화 요구 사항
- 세 개 이상의 OpenShift Container Platform 마스터 노드가 있는지 확인합니다. 세 개의 영역 각각에 하나의 마스터 노드.
- 두 데이터 영역에 걸쳐 4개 이상의 OpenShift Container Platform 작업자 노드가 균등하게 분산되어 있는지 확인합니다.
- 베어 메탈에서 클러스터를 확장하려면 OpenShift Container Platform 마스터 노드의 루트 드라이브로 SSD 드라이브를 사용합니다.
- 각 노드의 레이블이 해당 영역 레이블로 미리 지정되어 있는지 확인합니다. 자세한 내용은 OpenShift Container Platform 노드에 토폴로지 영역 레이블 적용 섹션을 참조하십시오.
- Metro-DR 솔루션은 대기 시간이 영역 간에 2ms를 초과하지 않는 배포를 위해 고안되었습니다. 최대 4ms(Round-trip time)가 있습니다. 대기 시간이 길어지는 경우 Red Hat 고객 지원에 문의하십시오.
유연한 확장 및 중재는 스케일링 논리가 충돌하는 동시에 활성화할 수 없습니다. flexible 스케일링을 사용하면 OpenShift Data Foundation 클러스터에 한 번에 하나의 노드를 추가할 수 있습니다. Arbiter 클러스터에서는 두 개의 데이터 영역 각각에 하나 이상의 노드를 추가해야 합니다.
2.2. OpenShift Container Platform 노드에 토폴로지 영역 레이블 적용
사이트 중단 중에 중재자 기능이 있는 영역이 중재자 레이블을 사용합니다. 이러한 레이블은 임의의이며 세 위치에 대해 고유해야 합니다.
예를 들어 다음과 같이 노드에 레이블을 지정할 수 있습니다.
topology.kubernetes.io/zone=arbiter for Master0 topology.kubernetes.io/zone=datacenter1 for Master1, Worker1, Worker2 topology.kubernetes.io/zone=datacenter2 for Master2, Worker3, Worker4
노드에 라벨을 적용하려면 다음을 수행합니다.
$ oc label node <NODENAME> topology.kubernetes.io/zone=<LABEL>
<NODENAME>- 노드의 이름입니다.Is the name of the node.
<LABEL>- 토폴로지 영역 레이블입니다.
세 영역의 예제 레이블을 사용하여 라벨을 확인하려면 다음을 수행합니다.
$ oc get nodes -l topology.kubernetes.io/zone=<LABEL> -o name<LABEL>토폴로지 영역 레이블입니다.
또는 단일 명령을 실행하여 해당 영역이 있는 모든 노드를 확인할 수 있습니다.
$ oc get nodes -L topology.kubernetes.io/zone
이제 Vertical-DR 확장 클러스터 토폴로지 영역 레이블이 적절한 OpenShift Container Platform 노드에 적용되어 세 위치를 정의합니다.
2.3. Local Storage Operator 설치
로컬 스토리지 장치에서 Red Hat OpenShift Data Foundation 클러스터를 생성하기 전에 Operator Hub에서 Local Storage Operator를 설치합니다.
절차
- OpenShift 웹 콘솔에 로그인합니다.
- Operators → OperatorHub 를 클릭합니다.
-
Filter by keyword 상자에
로컬 스토리지를입력하여 Operator 목록에서 Local Storage Operator 를 찾은 후 클릭합니다. Operator 설치 페이지에서 다음 옵션을 설정합니다.
-
채널 업데이트 채널은
4.9또는stable. - 클러스터의 특정 네임스페이스 로 설치 모드.
- 설치된 Namespace를 Operator 권장 네임스페이스 openshift-local-storage.
- 자동 승인 업데이트.
-
채널 업데이트 채널은
- 설치를 클릭합니다.
검증 단계
- Local Storage Operator에 성공적으로 설치를 나타내는 녹색 눈금이 표시되는지 확인합니다.
2.4. Red Hat OpenShift Data Foundation Operator 설치
Red Hat OpenShift Container Platform Operator Hub를 사용하여 Red Hat OpenShift Data Foundation Operator를 설치할 수 있습니다.
사전 요구 사항
- cluster-admin 및 Operator 설치 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
- Red Hat OpenShift Container Platform 클러스터의 두 데이터 센터에 균등하게 분산된 작업자 노드가 4개 이상 있어야 합니다.
- 추가 리소스 요구 사항은 배포 계획을 참조하십시오.
OpenShift Data Foundation의 클러스터 수준 기본 노드 선택기를 재정의해야 하는 경우 명령줄 인터페이스에서 다음 명령을 사용하여
openshift-storage네임스페이스에 대한 빈 노드 선택기를 지정할 수 있습니다(이 경우 openshift-storage 네임스페이스 생성).$ oc annotate namespace openshift-storage openshift.io/node-selector=
-
노드를
infra로 테인트하여 Red Hat OpenShift Data Foundation 리소스만 해당 노드에 예약되도록 합니다. 이는 서브스크립션 비용을 절감할 수 있도록 지원합니다. 자세한 내용은 스토리지 리소스 관리 및 할당 가이드의 Red Hat OpenShift Data Foundation 전용 작업자 노드 사용 방법을 참조하십시오.
절차
- OpenShift 웹 콘솔에 로그인합니다.
- Operators → OperatorHub 를 클릭합니다.
-
OpenShift Data Foundation을 키워드로 필터링 상자에 스크롤하여 OpenShift Data Foundation Operator를 검색합니다. - 설치를 클릭합니다.
Operator 설치 페이지에서 다음 옵션을 설정합니다.
- Channel을 stable-4.9 로 업데이트합니다.
- 클러스터의 특정 네임스페이스 로 설치 모드.
-
설치된 Namespace를 Operator 권장 네임스페이스 openshift-storage. 네임스페이스
openshift-storage가 없으면 Operator 설치 중에 생성됩니다. 승인 전략을 자동 또는 수동으로 선택합니다.
자동 업데이트를 선택하면 OLM(Operator Lifecycle Manager)은 개입 없이 Operator의 실행 중인 인스턴스를 자동으로 업그레이드합니다.
수동 업데이트를 선택한 경우 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 최신 버전으로 업데이트하기 위해 해당 업데이트 요청을 수동으로 승인해야 합니다.
- Console 플러그인에 대해 Enable 옵션이 선택되어 있는지 확인합니다.
- 설치를 클릭합니다.
검증 단계
OpenShift Data Foundation Operator에 성공적으로 설치를 나타내는 녹색 눈금이 표시되는지 확인합니다.
3장. OpenShift Data Foundation 클러스터 생성
사전 요구 사항
- 재해 복구가 활성화된 스토리지 클러스터를 배포하기 위해 준비 중인 모든 요구 사항을 충족하는지 확인하십시오.
절차
OpenShift 웹 콘솔에서 Operator → 설치된 Operator를 클릭하여 설치된 모든 Operator 를 확인합니다.
선택한 프로젝트 가
openshift-storage인지 확인합니다.- OpenShift Data Foundation Operator를 클릭한 다음 Create StorageSystem 을 클릭합니다.
- 백업 스토리지 페이지에서 로컬 스토리지 장치 옵션을 사용하여 새 StorageClass 만들기 옵션을 선택합니다.
다음을 클릭합니다.
중요아직 설치되지 않은 경우 Local Storage Operator를 설치하라는 메시지가 표시됩니다. Install 을 클릭하고 Local Storage Operator 설치에 설명된 절차를 따릅니다.
로컬 볼륨 세트 생성 페이지에서 다음 정보를 제공합니다.
LocalVolumeSet 의 이름과 StorageClass 를 입력합니다.
기본적으로 스토리지 클래스 이름에 로컬 볼륨 세트 이름이 표시됩니다. 이름을 변경할 수 있습니다.
다음 중 하나를 선택합니다.
모든 노드의 디스크
모든 노드에서 선택한 필터와 일치하는 사용 가능한 디스크를 사용합니다.
선택한 노드의 디스크
선택한 노드에서만 선택한 필터와 일치하는 사용 가능한 디스크를 사용합니다.
중요선택한 노드가 집계된 30 개의 CPU 및 72GiB RAM의 OpenShift Data Foundation 클러스터 요구 사항과 일치하지 않으면 최소 클러스터가 배포됩니다.
최소 노드 요구 사항은 계획 가이드의 리소스 요구 사항 섹션을 참조하십시오.
-
SSD또는NVMe를 선택하여 지원되는 구성을 빌드합니다. 지원되지 않는 테스트 설치를 위해HDD를선택할 수 있습니다. 고급 섹션을 확장하고 다음 옵션을 설정합니다.
볼륨 모드
블록은 기본적으로 선택됩니다.
장치 유형
드롭다운 목록에서 하나 이상의 장치 유형을 선택합니다.
디스크 크기
장치에 대해 최소 크기 100GB와 포함되어야 하는 장치의 사용 가능한 최대 크기를 설정합니다.
최대 디스크 제한
이는 노드에서 생성할 수 있는 최대 PV 수를 나타냅니다. 이 필드가 비어 있으면 일치하는 노드에서 사용 가능한 모든 디스크에 PV가 생성됩니다.
다음을 클릭합니다.
LocalVolumeSet 생성이 표시되는지 확인하는 팝업이 표시됩니다.
- 계속하려면 예 를 클릭합니다.Click Yes to continue.
용량 및 노드 페이지에서 다음을 구성합니다.
확장 클러스터를 사용하려면 Enable arbiter checkbox를 선택합니다. 이 옵션은 중재자에 대한 모든 사전 요구 사항이 충족되고 선택한 노드가 채워지는 경우에만 사용할 수 있습니다. 자세한 내용은 재해 복구가 활성화된 스토리지 클러스터 배포 준비의 Arbiter 확장 클러스터 요구 사항을 참조하십시오 [기술 프리뷰].
드롭다운 목록에서 중재자 영역을 선택합니다.
사용 가능한 원시 용량 은 스토리지 클래스와 연결된 모든 디스크에 따라 용량 값으로 채워집니다. 이 작업을 수행하는 데 시간이 다소 걸립니다.
선택한 노드 목록에는 스토리지 클래스를 기반으로 하는 노드가 표시됩니다.
- 다음을 클릭합니다.
선택 사항: 보안 및 네트워크 페이지에서 요구 사항에 따라 다음을 구성합니다.
- 암호화 활성화 확인란을 선택하여 블록 및 파일 스토리지를 암호화합니다.
다음 암호화 수준 중 하나 또는 둘 다를 선택합니다.
클러스터 전체 암호화
전체 클러스터(블록 및 파일)를 암호화합니다.
StorageClass 암호화
암호화 활성화된 스토리지 클래스를 사용하여 암호화된 영구 볼륨(블록만 해당)을 생성합니다.
외부 키 관리 서비스에 연결을 선택합니다. 이는 클러스터 전체 암호화의 경우 선택 사항입니다.
-
Key Management Service Provider 는 기본적으로
Vault로 설정됩니다. - Vault 서비스 이름, Vault 서버 호스트 주소 ('https://<hostname 또는 ip>''), 포트 번호 및 토큰 을 입력합니다.
-
Key Management Service Provider 는 기본적으로
고급 설정을 확장하여 Vault 구성에 따라 추가 설정 및 인증서 세부 정보를 입력합니다.
- OpenShift Data Foundation 전용 및 고유한 백엔드 경로에 키 값 시크릿 경로를 입력합니다.
- 선택 사항: TLS 서버 이름 및 Vault Enterprise Namespace 를 입력합니다.
- 각 PEM 인코딩 인증서 파일을 업로드하여 CA 인증서,클라이언트 인증서 및 클라이언트 개인 키를 제공합니다.
- 저장을 클릭합니다.
다음 중 하나를 선택합니다.
기본값 (SDN)
단일 네트워크를 사용하는 경우
사용자 정의 (Multus)
여러 네트워크 인터페이스를 사용하는 경우
- 드롭다운에서 공용 네트워크 인터페이스를 선택합니다.
드롭다운에서 Cluster Network Interface 를 선택합니다.
참고추가 네트워크 인터페이스를 하나만 사용하는 경우 단일
NetworkAttachementDefinition, 즉 공용 네트워크 인터페이스인ocs-public-cluster를 선택하고 Cluster Network Interface를 비워 둡니다.
- 다음을 클릭합니다.
검토 및 생성 페이지에서 구성 세부 정보를 검토합니다.
구성 설정을 수정하려면 뒤로 이동하여 이전 구성 페이지로 돌아갑니다.
- Create StorageSystem 을 클릭합니다.
KMS(Key Management System)를 사용한 클러스터 전체 암호화의 경우 Vault Key/Value (KV) 시크릿 엔진 API 버전 2를 사용한 경우
configmap을 편집해야 합니다.- OpenShift 웹 콘솔에서 워크로드 → ConfigMaps 로 이동합니다.
- KMS 연결 세부 정보를 보려면 ocs-kms-connection-details 를 클릭합니다.
configmap을 편집합니다.
- Action 메뉴(journal) → Edit ConfigMap 을 클릭합니다.
VAULT_BACKEND매개 변수를v2로 설정합니다.kind: ConfigMap apiVersion: v1 metadata: name: ocs-kms-connection-details [...] data: KMS_PROVIDER: vault KMS_SERVICE_NAME: vault [...] VAULT_BACKEND: v2 [...]- 저장을 클릭합니다.
검증 단계
설치된 스토리지 클러스터의 최종 상태를 확인하려면 다음을 수행합니다.
- OpenShift 웹 콘솔에서 설치된 Operator → OpenShift Data Foundation → 스토리지 시스템 → ocs-storagecluster-storagesystem → Resources 로 이동합니다.
-
StorageClusterStatus(상태)가Ready이고 옆에 녹색 눈금이 표시되어 있는지 확인합니다.
배포 중재 모드의 경우:
- OpenShift 웹 콘솔에서 설치된 Operator → OpenShift Data Foundation → 스토리지 시스템 → ocs-storagecluster-storagesystem → 리소스 → ocs-storagecluster 로 이동합니다.
YAML 탭에서
spec섹션에서arbiter키를 검색하고enable가true로 설정되어 있는지 확인합니다.spec: arbiter: enable: true [..] nodeTopologies: arbiterLocation: arbiter #arbiter zone storageDeviceSets: - config: {} count: 1 [..] replica: 4 status: conditions: [..] failureDomain: zone
- OpenShift Data Foundation의 모든 구성 요소가 성공적으로 설치되었는지 확인하려면 OpenShift Data Foundation 설치 확인을 참조하십시오.
4장. OpenShift Data Foundation 배포 확인
OpenShift Data Foundation이 올바르게 배포되었는지 확인하려면 다음을 수행하십시오.
4.1. Pod 상태 확인
절차
- OpenShift 웹 콘솔에서 워크로드 → 포드 를 클릭합니다.
프로젝트 드롭다운 목록에서
openshift-storage를 선택합니다.참고Show default projects (기본 프로젝트 표시) 옵션이 비활성화된 경우 토글 버튼을 사용하여 모든 기본 프로젝트를 나열합니다.
각 구성 요소에 대해 예상되는 Pod 수 및 노드 수에 따라 달라지는 방법에 대한 자세한 내용은 표 4.1. “OpenShift Data Foundation 클러스터에 해당하는 Pod” 을 참조하십시오.
-
Running 및 Completed 탭을 클릭하여 다음 Pod가
Running및Completed상태인지 확인합니다.
표 4.1. OpenShift Data Foundation 클러스터에 해당하는 Pod
| 구성 요소 | 해당 Pod |
|---|---|
| OpenShift Data Foundation Operator |
|
| rook-ceph Operator |
(모든 작업자 노드의 Pod) |
| Multicloud Object Gateway |
|
| MON |
(5 Pod는 데이터 센터 영역당 2개, 중재자 영역에서 1개)에 분산됩니다. |
| MGR |
(모든 스토리지 노드의 Pod) |
| MDS |
(2개의 Pod는 두 개의 데이터 센터 영역에 배포됩니다. |
| RGW |
(2개의 Pod는 두 개의 데이터 센터 영역에 배포됩니다. |
| CSI |
|
| rook-ceph-crashcollector |
(1개의 스토리지 노드 및 중재 영역의 Pod 1개) |
| OSD |
|
4.2. OpenShift Data Foundation 클러스터가 정상인지 확인
절차
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
- 개요 탭의 상태 카드에서 스토리지 시스템을 클릭한 다음 해당 팝업에서 스토리지 시스템 링크를 클릭합니다.
- 블록 및 파일 탭의 상태 카드에서 스토리지 클러스터에 녹색 눈금 이 있는지 확인합니다.
- 세부 정보 카드에서 클러스터 정보가 표시되는지 확인합니다.
블록 및 파일 대시보드를 사용하는 OpenShift Data Foundation 클러스터의 상태에 대한 자세한 내용은 Monitoring OpenShift Data Foundation 을 참조하십시오.
4.3. Multicloud Object Gateway가 정상인지 확인
절차
- OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
개요 탭의 상태 카드에서 스토리지 시스템을 클릭한 다음 해당 팝업에서 스토리지 시스템 링크를 클릭합니다.
- Object 탭의 상태 카드에서 Object Service 와 Data Resiliency 모두 녹색 눈금이 있는지 확인합니다.
- 세부 정보 카드에 MCG 정보가 표시되는지 확인합니다.
오브젝트 서비스 대시보드를 사용하는 OpenShift Data Foundation 클러스터의 상태에 대한 자세한 내용은 Monitoring OpenShift Data Foundation 을 참조하십시오.
4.4. OpenShift Data Foundation 특정 스토리지 클래스가 있는지 확인
절차
- OpenShift 웹 콘솔의 왼쪽 창에서 스토리지 → 스토리지 클래스 를 클릭합니다.
OpenShift Data Foundation 클러스터 생성으로 다음 스토리지 클래스가 생성되었는지 확인합니다.
-
ocs-storagecluster-ceph-rbd -
ocs-storagecluster-cephfs -
openshift-storage.noobaa.io -
ocs-storagecluster-ceph-rgw
-
5장. 영역 인식 샘플 애플리케이션 설치
영역 인식 샘플 애플리케이션을 배포하여 OpenShift Data Foundation, Metro-DR 설정이 올바르게 구성되었는지 확인합니다.
데이터 영역 간의 대기 시간을 사용하면 노드와 영역 간의 대기 시간이 짧은 OpenShift 클러스터와 비교하여 성능 저하를 확인할 수 있습니다(예: 동일한 위치에 있는 모든 노드). 성능이 저하되는 시간은 영역 간의 대기 시간과 스토리지를 사용하는 애플리케이션 동작(예: 쓰기 트래픽)에 따라 달라집니다. Metro-DR 클러스터 구성으로 중요한 애플리케이션을 테스트하여 필요한 서비스 수준에 맞는 애플리케이션 성능이 충분한지 확인하십시오.
5.1. 영역 Aware 샘플 애플리케이션 설치
ReadWriteMany(RWX) PVC(영구 볼륨 클레임)는 ocs-storagecluster-cephfs 스토리지 클래스를 사용하여 생성됩니다. 여러 Pod에서 새로 생성된 RWX PVC를 동시에 사용합니다. 사용되는 애플리케이션을 File Uploader라고 합니다.
애플리케이션이 사이트 중단 시 계속 사용할 수 있도록 토폴로지 영역에 분산되는 방법에 대한 데모입니다.
이 데모는 이 애플리케이션에서 파일을 저장하기 위해 동일한 RWX 볼륨을 공유하므로 가능합니다. Red Hat OpenShift Data Foundation은 영역 인식 및 고가용성을 갖춘 Metro-DR 확장 클러스터로 구성되어 있기 때문에 영구 데이터 액세스에도 사용할 수 있습니다.
새 프로젝트를 생성합니다.
$ oc new-project my-shared-storage
file-uploader라는 예제 PHP 애플리케이션을 배포합니다.
$ oc new-app openshift/php:7.3-ubi8~https://github.com/christianh814/openshift-php-upload-demo --name=file-uploader
출력 예:
Found image 4f2dcc0 (9 days old) in image stream "openshift/php" under tag "7.2-ubi8" for "openshift/php:7.2- ubi8" Apache 2.4 with PHP 7.2 ----------------------- PHP 7.2 available as container is a base platform for building and running various PHP 7.2 applications and frameworks. PHP is an HTML-embedded scripting language. PHP attempts to make it easy for developers to write dynamically generated web pages. PHP also offers built-in database integration for several commercial and non-commercial database management systems, so writing a database-enabled webpage with PHP is fairly simple. The most common use of PHP coding is probably as a replacement for CGI scripts. Tags: builder, php, php72, php-72 * A source build using source code from https://github.com/christianh814/openshift-php-upload-demo will be cr eated * The resulting image will be pushed to image stream tag "file-uploader:latest" * Use 'oc start-build' to trigger a new build --> Creating resources ... imagestream.image.openshift.io "file-uploader" created buildconfig.build.openshift.io "file-uploader" created deployment.apps "file-uploader" created service "file-uploader" created --> Success Build scheduled, use 'oc logs -f buildconfig/file-uploader' to track its progress. Application is not exposed. You can expose services to the outside world by executing one or more of the commands below: 'oc expose service/file-uploader' Run 'oc status' to view your app.빌드 로그를 보고 애플리케이션이 배포될 때까지 기다립니다.
$ oc logs -f bc/file-uploader -n my-shared-storage
출력 예:
Cloning "https://github.com/christianh814/openshift-php-upload-demo" ... [...] Generating dockerfile with builder image image-registry.openshift-image-regis try.svc:5000/openshift/php@sha256:d97466f33999951739a76bce922ab17088885db610c 0e05b593844b41d5494ea STEP 1: FROM image-registry.openshift-image-registry.svc:5000/openshift/php@s ha256:d97466f33999951739a76bce922ab17088885db610c0e05b593844b41d5494ea STEP 2: LABEL "io.openshift.build.commit.author"="Christian Hernandez <christ ian.hernandez@yahoo.com>" "io.openshift.build.commit.date"="Sun Oct 1 1 7:15:09 2017 -0700" "io.openshift.build.commit.id"="288eda3dff43b02f7f7 b6b6b6f93396ffdf34cb2" "io.openshift.build.commit.ref"="master" " io.openshift.build.commit.message"="trying to modularize" "io.openshift .build.source-location"="https://github.com/christianh814/openshift-php-uploa d-demo" "io.openshift.build.image"="image-registry.openshift-image-regi stry.svc:5000/openshift/php@sha256:d97466f33999951739a76bce922ab17088885db610 c0e05b593844b41d5494ea" STEP 3: ENV OPENSHIFT_BUILD_NAME="file-uploader-1" OPENSHIFT_BUILD_NAMESP ACE="my-shared-storage" OPENSHIFT_BUILD_SOURCE="https://github.com/christ ianh814/openshift-php-upload-demo" OPENSHIFT_BUILD_COMMIT="288eda3dff43b0 2f7f7b6b6b6f93396ffdf34cb2" STEP 4: USER root STEP 5: COPY upload/src /tmp/src STEP 6: RUN chown -R 1001:0 /tmp/src STEP 7: USER 1001 STEP 8: RUN /usr/libexec/s2i/assemble ---> Installing application source... => sourcing 20-copy-config.sh ... ---> 17:24:39 Processing additional arbitrary httpd configuration provide d by s2i ... => sourcing 00-documentroot.conf ... => sourcing 50-mpm-tuning.conf ... => sourcing 40-ssl-certs.sh ... STEP 9: CMD /usr/libexec/s2i/run STEP 10: COMMIT temp.builder.openshift.io/my-shared-storage/file-uploader-1:3 b83e447 Getting image source signatures [...]Push successful이 표시되면 명령 프롬프트가 tail 모드에서 반환됩니다.참고new-app 명령은 git 리포지토리에서 직접 애플리케이션을 배포하고 OpenShift 템플릿을 사용하지 않으므로 기본적으로 OpenShift 경로 리소스가 생성되지 않습니다. 경로를 수동으로 생성해야 합니다.
애플리케이션 스케일링
애플리케이션을 4개의 복제본으로 스케일링하고 서비스를 노출하여 애플리케이션 영역을 인식하고 사용할 수 있도록 합니다.
$ oc expose svc/file-uploader -n my-shared-storage
$ oc scale --replicas=4 deploy/file-uploader -n my-shared-storage
$ oc get pods -o wide -n my-shared-storage
몇 분 내에 4개의 file-uploader Pod가 있어야 합니다.
Running상태인 4개의 file-uploader Pod가 있을 때까지 위의 명령을 반복합니다.PVC를 생성하여 애플리케이션에 연결합니다.
$ oc set volume deploy/file-uploader --add --name=my-shared-storage \ -t pvc --claim-mode=ReadWriteMany --claim-size=10Gi \ --claim-name=my-shared-storage --claim-class=ocs-storagecluster-cephfs \ --mount-path=/opt/app-root/src/uploaded \ -n my-shared-storage
이 명령은 다음과 같습니다.
- PVC를 생성합니다.
- 볼륨 정의를 포함하도록 애플리케이션 배포를 업데이트합니다.
- 애플리케이션 배포를 업데이트하여 볼륨 마운트를 지정된 마운트 경로에 연결합니다.
- 4개의 애플리케이션 포드를 사용하여 새 배포를 생성합니다.
볼륨을 추가한 결과를 확인합니다.
$ oc get pvc -n my-shared-storage
출력 예:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE my-shared-storage Bound pvc-5402cc8a-e874-4d7e-af76-1eb05bd2e7c7 10Gi RWX ocs-storagecluster-cephfs 52s
ACCESS MODE가 RWX로 설정되어 있습니다.4개의
file-uploaderPod는 모두 동일한 RWX 볼륨을 사용합니다. 이 액세스 모드가 없으면 OpenShift에서 동일한 PV(영구 볼륨)에 여러 포드를 안정적으로 연결하려고 시도하지 않습니다. ReadWriteOnce (RWO) PV를 사용하는 배포를 확장하려고 하면 Pod가 동일한 노드에 배치될 수 있습니다.
5.2. Deploy to be Zone Aware 수정
현재 file-uploader Deployment는 영역을 인식하지 않으며 동일한 영역의 모든 Pod를 예약할 수 있습니다. 이 경우 사이트 중단이 발생하면 애플리케이션을 사용할 수 없습니다. 자세한 내용은 Pod 토폴로지 분배 제약 조건을 사용하여 Pod 배치 제어를 참조하십시오.
애플리케이션 배포 구성에 포드 배치 규칙을 추가하여 애플리케이션 영역을 인식하도록 합니다.
다음 명령을 실행하고 출력을 검토합니다.
$ oc get deployment file-uploader -o yaml -n my-shared-storage | less
출력 예:
[...] spec: progressDeadlineSeconds: 600 replicas: 4 revisionHistoryLimit: 10 selector: matchLabels: deployment: file-uploader strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: annotations: openshift.io/generated-by: OpenShiftNewApp creationTimestamp: null labels: deployment: file-uploader spec: # <-- Start inserted lines after here containers: # <-- End inserted lines before here - image: image-registry.openshift-image-registry.svc:5000/my-shared-storage/file-uploader@sha256:a458ea62f990e431ad7d5f84c89e2fa27bdebdd5e29c5418c70c56eb81f0a26b imagePullPolicy: IfNotPresent name: file-uploader [...]토폴로지 영역 레이블을 사용하도록 배포를 편집합니다.
$ oc edit deployment file-uploader -n my-shared-storage
시작및종료사이에 다음 새 행을 추가합니다(이전 단계의 출력에 표시됨):[...] spec: topologySpreadConstraints: - labelSelector: matchLabels: deployment: file-uploader maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule - labelSelector: matchLabels: deployment: file-uploader maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: ScheduleAnyway nodeSelector: node-role.kubernetes.io/worker: "" containers: [...]출력 예:
deployment.apps/file-uploader edited
배포를 0개의 Pod로 축소 한 다음 포드 4 개로 돌아갑니다. 이는 포드 배치 측면에서 배포가 변경되었기 때문에 필요합니다.
- Pod가 0 개로 축소
$ oc scale deployment file-uploader --replicas=0 -n my-shared-storage
출력 예:
deployment.apps/file-uploader scaled
- Pod 최대 4 개 확장
$ oc scale deployment file-uploader --replicas=4 -n my-shared-storage
출력 예:
deployment.apps/file-uploader scaled
4개의 포드가 datacenter1 및 datacenter2 영역의 4개 노드에 분산되어 있는지 확인합니다.
$ oc get pods -o wide -n my-shared-storage | egrep '^file-uploader'| grep -v build | awk '{print $7}' | sort | uniq -c출력 예:
1 perf1-mz8bt-worker-d2hdm 1 perf1-mz8bt-worker-k68rv 1 perf1-mz8bt-worker-ntkp8 1 perf1-mz8bt-worker-qpwsr
사용된 영역 레이블을 검색합니다.
$ oc get nodes -L topology.kubernetes.io/zone | grep datacenter | grep -v master
출력 예:
perf1-mz8bt-worker-d2hdm Ready worker 35d v1.20.0+5fbfd19 datacenter1 perf1-mz8bt-worker-k68rv Ready worker 35d v1.20.0+5fbfd19 datacenter1 perf1-mz8bt-worker-ntkp8 Ready worker 35d v1.20.0+5fbfd19 datacenter2 perf1-mz8bt-worker-qpwsr Ready worker 35d v1.20.0+5fbfd19 datacenter2
브라우저를 사용하여 file-uploader 웹 애플리케이션을 사용하여 새 파일을 업로드합니다.
생성된 경로를 찾습니다.
$ oc get route file-uploader -n my-shared-storage -o jsonpath --template="http://{.spec.host}{'\n'}"출력 예:
http://file-uploader-my-shared-storage.apps.cluster-ocs4-abdf.ocs4-abdf.sandbox744.opentlc.com
이전 단계의 경로를 사용하여 브라우저를 웹 애플리케이션을 가리킵니다.
웹 애플리케이션은 업로드된 모든 파일을 나열하고 새 파일을 업로드하는 기능과 기존 데이터를 다운로드하는 기능을 제공합니다. 지금, 아무것도 없습니다.
로컬 시스템에서 임의의 파일을 선택하여 애플리케이션에 업로드합니다.
- Choose file (파일 선택)을 클릭하여 임의의 파일을 선택합니다.
업로드를 클릭합니다.
그림 5.1. 간단한 PHP 기반 파일 업로드 도구

- 업로드된 파일 목록을 클릭하여 현재 업로드된 모든 파일 목록을 확인합니다.
OpenShift Container Platform 이미지 레지스트리, 수신 라우팅 및 모니터링 서비스는 영역을 인식하지 못합니다.