15.1. 네트워크 요구사항
GRID, 관리자, 클라이언트 네트워크를 구성하려면 다음 이미지를 참고하여 SG1000 및 SG6060의 케이블 연결 다이어그램을 확인하세요.
15.1.1. Admin Node SG1000
SG1000에 관리 노드가 최소 2개 있어야 합니다.
각 관리자 노드에는 다음 각각에 주소가 하나씩 총 4개의 IP 주소가 있어야 합니다.
- BMC 네트워크
- 관리 네트워크
- 클라이언트 네트워크
- 그리드 네트워크
다음과 같은 경우 서브넷이 3개 있어야 합니다.
- 관리 네트워크
- BMC 네트워크
클라이언트 네트워크와 그리드 네트워크, 각 서브넷의 서브넷 마스크는 최대 30비트여야 합니다.
15.1.2. 스토리지 노드 SG6060 및 SG6000
SG6060 및 SG6000 모델의 경우 스토리지 노드가 3개 이상 있어야 합니다.
각 스토리지 노드에는 다음 각각에 주소가 하나씩 총 5개의 IP 주소가 있어야 합니다.
- BMC 네트워크(관리)
- 관리 네트워크(mgmt)
- 그리드 네트워크
- 스토리지 컨트롤러 네트워크 (mgmt) 참고: 스토리지 컨트롤러 네트워크에는 IP 주소가 두 개 있어야 합니다.
다음 각각에 대해 서브넷이 두 개 있어야 합니다.
- BMC 네트워크
- 관리 네트워크
- 스토리지 컨트롤러 네트워크입니다.
- 그리드 네트워크
다음 표에는 관리자 노드와 스토리지 노드의 IP 주소 수가 나와 있습니다.
| 필요한 IP 수 | 관리 네트워크 | 클라이언트 네트워크 | 그리드 네트워크 |
|---|---|---|---|
| 관리 노드 | 2 | 1 | 1 |
| 스토리지 노드 | 4 | 0 | 1 |
다음 세 개의 서브넷이 있어야 합니다.
- 관리 네트워크
- 클라이언트 네트워크
- 그리드 네트워크
각 서브넷의 서브넷 마스크는 최대 30비트여야 합니다.
15.1.3. 네트워크 세부정보
15.1.3.1. 분산 클라우드 관리 플레인 네트워크:
분산 클라우드 대역 외 (OOB) 관리 네트워크에는 객체 스토리지 베이스보드 관리 컨트롤러 (BMC) 네트워크와 관리 네트워크가 포함됩니다. 네트워크가 mgmtsw에 연결됩니다.
다음 각 항목에 OOB BMC IP 주소가 있어야 합니다.
- SG1000
- SG6000
다음 각 항목에 OOB 관리 IP 주소가 있어야 합니다.
- SG1000
- SG6000
- SG6060
15.1.3.2. Distributed Cloud 데이터 영역 네트워크
데이터 영역 네트워크는 외부 객체 StorageGRID (SG1000) 클라이언트 LIF와 NetApp의 클라이언트 네트워크로 구성됩니다.
각 기기에서
SubnetClaim를 식별하는 단계는 다음을 참고하세요.- S3 API 엔드포인트:
cellconfig파일에서external-objectstorage-client-lif-subnet를 검색합니다.- 할당된 CIDR/게이트웨이 IP 주소를 지정하는 해당
SubnetClaim를 식별합니다.
SG1000 그리드 네트워크 어플라이언스 엔드포인트:
cellconfig파일에서objectstorage-admin-nodes-lif-subnet를 검색합니다.- 할당된 CIDR/게이트웨이 IP 주소를 지정하는 해당
SubnetClaim를 식별합니다.
SG6060 그리드 네트워크 어플라이언스 엔드포인트:
cellconfig파일에서objectstorage-storage-nodes-lif-subnet를 검색합니다.- 할당된 CIDR/게이트웨이 IP 주소를 지정하는 해당
SubnetClaim를 식별합니다.
15.2. 준비
15.2.1. 정보 수집
예상 시간: 5~10분
이 섹션을 계속하기 전에 네트워크 부트스트랩 및 구성이 분산 클라우드 인스턴스를 완료하고 운영자가 가장 정확하거나 최신 cellconfig 파일에 액세스하거나 부트스트랩에 액세스할 수 있는지 확인합니다.
15.2.1.1. 저장소 하드웨어 기기 정보 수집
Distributed Cloud 인스턴스는 랙의 하드웨어 기기를 식별하기 위해 고정된 명명 규칙을 따릅니다. 특히 다음 객체 스토리지 기기에
- 관리 노드(SG1000):
<cell>-<rack>-objsadm[node-number]예를 들어af-ae-objsadm01는 관리자 노드를 나타냅니다. - 스토리지 컴퓨팅 컨트롤러 노드 (SG6000-CN):
<cell>-<rack>-objs[node-number]예를 들면af-ae-objs01입니다. - 스토리지 컨트롤러 랙(E2860):
<cell>-<rack>-objs[node-number]-s1예를 들면af-ae-objs01-s1입니다. - 스토리지 노드 컨트롤러(SG6060):
<cell>-<rack>-objs[node-number]-s1-[controller number]. 예를 들면af-ae-objs01-s1-01및af-ae-objs01-s1-02입니다.
15.2.1.2. 관리 플레인 네트워크 정보 수집
네트워크 부트스트랩 및 구성 중에 운영자는 관리 플레인의 서브넷을 만들어야 합니다. 객체 스토리지 시스템에는 부트스트랩 프로세스 중에 다음 정보가 필요합니다.
- 관리 서브넷입니다.
- 관리 게이트웨이 IP 주소입니다.
- 관리 서브넷에 예약된 IP 주소 16개, 관리 노드당 IP 주소 2개, 스토리지 노드당 IP 주소 4개
SubnetClaim <cell>-<rack>-mgmtsw01-objs-os-subnet에서 관리 게이트웨이 IP 주소를 찾습니다. <cell> 및 <rack>은 '스토리지 하드웨어 기기 정보 수집' 단계에서 식별된 것과 동일합니다. 예를 들면 af-ae-mgmtsw01-objs-os-subnet입니다.
kubectl get subnetclaim -n root <cell>-<rack>-mgmtsw01-objs-os-subnet -o jsonpath='{.status.ipv4SubnetStatus.reservedIpRanges[?(.type == "GatewayReservation")].ipRange.startIPAddress}'
명령어 값을 MANAGEMENT_SWITCH_GATEWAY에 저장합니다.
15.2.1.3. 데이터 영역 네트워크 정보 수집
계속하기 전에 네트워크 부트스트랩 및 구성 중에 객체 스토리지 시스템에 대해 서브넷 3개를 프로비저닝했는지 확인합니다.
다음 서브넷이 있는지 확인합니다.
-
objectstorage-admin-nodes-lif-subnet -
objectstorage-storage-nodes-lif-subnet -
external-objectstorage-client-lif-subnet
SubnetClaim 이름과 함께 다음 명령어를 실행합니다.
kubectl -n root get SubnetClaim SUBNET_CLAIM_NAME
다음과 같이 출력이 표시됩니다.
NAME CIDRCLAIM OVERLAY-NETWORK IPV4-CIDR IPV6-CIDR VLAN READY VLANREADY
objectstorage-admin-nodes-lif-subnet objectstorage-admin-nodes-lif-cidr ObjectStorage 10.7.7.0/24 7 True True
다음 필드가 있는지 확인합니다.
VLANREADY: TrueVLANREADY: True
15.2.1.4. 종속 항목 정보 수집
객체 스토리지 시스템은 분산 클라우드에서 다음 핵심 서비스와 인프라를 사용합니다.
- NTP
- 하드웨어 보안 모듈 (HSM)
- DNS
15.2.1.5. TO-BE-FILLED 필드 업데이트
obj-cellobj.yaml 파일에서 TO-BE-FILLED 값을 확인하고 업데이트합니다.
다음을 실행하여 값이 YAML 파일에 없는지 확인합니다.
cat OBJ_CELLOBJ_YAML_PATH | grep "TO-BE-FILLED"
15.2.2. 로컬 연결을 통한 구성 관리 네트워크
예상 시간: 30~45분
이 하위 섹션에서는 각 StorageGRID 어플라이언스 노드의 관리 네트워크를 설정합니다. 관리 네트워크가 구성되면 부트스트래퍼에서 관리 네트워크의 IP를 사용하여 StorageGRID 노드에 액세스합니다.
모든 ObjectStorage 기기에 대해 다음 단계를 따르세요.
-
af-ae-objsadm01 -
af-ae-objsadm02 -
af-ae-objs01 -
af-ae-objs02 -
af-ae-objs03
StorageGRID 기기를 부트스트랩하려면 관리 네트워크 포트 6의 크래시 카트를 사용하여 관리 노드 2개와 스토리지 노드 3개를 포함한 각 기기에 연결하고 https://169.254.0.1:8443를 방문하여 관리 네트워크에서 관리 IP 주소를 설정합니다.
이더넷 케이블을 사용하여 크래시 카트를 서비스 어플라이언스의 가장 오른쪽 RJ-45 포트에 직접 연결합니다. 다음 다이어그램은 관리 및 스토리지 노드의 포트 6을 예로 보여줍니다.
크래시 카트에서 웹브라우저를 엽니다.
각 머신에서
https://169.254.0.1:8443로 이동합니다.StorageGRID Appliance Installer의 메뉴 표시줄에서 Configure Networking > Link Configuration을 클릭합니다. 관리자 네트워크가 사용 설정되어 있는지 확인합니다.
관리 네트워크의 IP 주소를 구성하려면 네트워킹 구성 > IP 구성을 선택합니다.
관리 네트워크 섹션까지 아래로 스크롤하고 IP 할당에서 고정을 선택하고 노드의 해당 관리 IP 주소(
managementIP)를 입력합니다. 각 노드의 관리 IP는obj-cellobj.yaml파일에서 확인할 수 있습니다. 예를 들면 다음과 같습니다.ObjectStorageAdminNode (SG1000):
apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1 kind: ObjectStorageAdminNode metadata: creationTimestamp: null name: af-ae-objsadm01 spec: network: bmcIP: 10.251.188.11/24 clientIP: 10.251.113.2/28 dataIP: 10.1.0.66/26 managementIP: 10.251.188.10/24 siteName: objectstorage-siteObjectStorageStorageNode (SG6000):
apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1 kind: ObjectStorageStorageNode metadata: creationTimestamp: null name: af-ae-objs01 spec: network: bmcIP: 10.251.243.34/24 controllerAManagementIP: 10.251.243.35/24 controllerBManagementIP: 10.251.243.36/24 dataIP: 10.1.0.132/26 managementIP: 10.251.243.33/24 siteName: objectstorage-site
게이트웨이를
MANAGEMENT_SWITCH_GATEWAY로 설정합니다.다음 예시 이미지는
obj-cellobj.yaml파일에 할당된 관리 IP 주소를 사용하여af-ae-objs01를 구성하는 방법을 보여줍니다.
저장을 클릭하고 IP 주소가 업데이트되는지 확인합니다.
부트스트래퍼에서 관리 IP 주소를 핑하여 연결할 수 있는지 확인합니다.
- 부트스트래퍼에서 관리 IP 주소를 핑하여 연결 가능한지 확인합니다.
- 모든 노드에 관리 네트워크의 IP 주소가 있으면 관리 IP 주소를 사용하여 StorageGRID 노드 설치 GUI에 액세스합니다.
문제해결:
노드를 핑할 수 없는 경우:
- 이전 3단계에서 StorageGRID 노드 설치 UI에 액세스하고 대화상자 배너에 오류가 표시되는지 확인합니다. 오류를 해결해 보세요. 필요한 경우 엔지니어에게 문의합니다.
- 네트워킹 구성 > IP 구성으로 이동합니다. 올바른 관리 네트워크 섹션이 올바른 고정 IP 및 게이트웨이로 구성되어 있는지 확인합니다. 경우에 따라 StorageGRID 노드가 확인 후 관리 네트워크 구성을 완전히 등록하지 않습니다.
- 5~8단계를 다시 실행하고 관리자 노드 네트워크를 확인합니다.
객체 스토리지 시스템의 설치를 계속하려면 각 노드에서 StorageGRID 노드 설치 GUI에 액세스해야 합니다.
15.2.3. StorageGRID 업그레이드
예상 시간: 1~1.5시간
StorageGRID를 업그레이드하기 전에 StorageGRID 소프트웨어 버전을 확인하세요. 고급 > StorageGRID 소프트웨어 업로드로 이동합니다. 현재 StorageGRID 버전이 표시됩니다.
번들로 제공되는 StorageGRID 설치 버전을 확인합니다.
gdcloud artifacts tree oci | grep object-storage/os
샘플 출력은 다음과 비슷합니다.
│ │ │ └── gpc-system-object-storage/os:11.8.0
├── gpc-system-object-storage/os:sha256-d4cb75f91f43a92cb580db98faae12e87ec49d2b27c7db8a056d6411ac3b6044.sig
이 예시에서는 버전이 아티팩트에 11.8.0로 태그됩니다.
SG_INSTALL_VERSION에 버전 값을 저장합니다.
번들로 제공되는 StorageGRID 펌웨어 버전을 확인합니다.
gdcloud artifacts tree oci | grep object-storage/firmware
샘플 출력은 다음과 비슷합니다.
│ │ │ ├── gpc-system-object-storage/firmware:3.8.1
├── gpc-system-object-storage/firmware:sha256-20a664504c342b5f14188114fad7a1e7d40abc042690bb0f776aa67cecff52e1.sig
이 예시에서는 버전이 아티팩트에 3.8.1로 태그됩니다.
SG_FIRMWARE_VERSION에 버전 값을 저장합니다.
노드의 버전이 SG_INSTALL_VERSION이 아니면 다음 단계로 계속 진행하여 StorageGRID 설치 버전을 업그레이드하거나 다운그레이드합니다. 현재 버전이 SG_INSTALL_VERSION인 경우 SANtricity 업그레이드 섹션으로 이동합니다.
15.2.3.1. 펌웨어 업그레이드하기
모든 StorageGRID 노드에 대해 다음 단계를 따르세요.
-
af-ae-objsadm01 -
af-ae-objsadm02 -
af-ae-objs01 -
af-ae-objs02 -
af-ae-objs03
번들에서 펌웨어 이미지를 가져옵니다.
gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/firmware:SG_FIRMWARE_VERSION tar -xvzf storage/gpc-system-object-storage/firmware.tar.gz이 파일은
storagegrid_firmware_install/에서 확인할 수 있습니다.StorageGRID 노드에서 StorageGRID 어플라이언스 설치 프로그램으로 이동합니다. 고급 > 펌웨어 업그레이드를 선택합니다. 선택한 펌웨어 버전의 펌웨어 이미지
storagegrid_SG_FIRMWARE_VERSION_firmware_image.bin.tar.bz2와 체크섬storagegrid_SG_FIRMWARE_VERSION_firmware_checksum.bin.sha1을 업로드합니다. 업로드 후 StorageGRID는 자동으로 파일의 유효성 검사를 시작합니다. 유효성 검사는 일반적으로 5~10분 정도 걸립니다.
녹색 체크표시가 두 개 표시되면 비활성 파티션 업그레이드를 클릭합니다.
Successfully updated the firmware on the inactive partition메시지를 수신한 후 현재 펌웨어 섹션을 확인하여 비활성 파티션이 실제로 올바른 버전인지 확인합니다.재부팅과 파티션 스왑을 두 번 클릭합니다.
노드가 재부팅을 완료하면 1단계와 2단계를 반복하여 다른 파티션의 펌웨어를 업그레이드합니다. 활성 파티션은 선택한 버전을 포함하고 비활성 파티션은 이전 버전을 포함합니다.
15.2.3.2. StorageGRID 소프트웨어 업그레이드
모든 노드의 펌웨어가 올바른 버전으로 업그레이드되면 두 관리 노드에서 소프트웨어를 선택한 버전으로 업그레이드합니다. 스토리지 노드는 관리자 노드의 소프트웨어를 모방하고 가져오므로 업그레이드할 필요가 없습니다.
SG1000의 관리 노드에서 다음 안내를 따르세요.
-
af-ae-objsadm01 -
af-ae-objsadm02
번들에서 설치 이미지를 가져옵니다.
gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/os:SG_INSTALL_VERSION tar -xvzf storage/gpc-system-object-storage/os.tar.gz파일은
storagegrid_os_install/에서 확인할 수 있습니다.Advanced(고급) -> Upload StorageGRID Software(StorageGRID 소프트웨어 업로드)로 이동합니다. 삭제를 클릭하여 현재 소프트웨어를 삭제하고 새 소프트웨어 패키지
storagegrid_SG_INSTALL_VERSION_webscale_os_image.deb와 해당 체크섬storagegrid_SG_INSTALL_VERSION_webscale_os_checksum.deb.md5을 다음과 같이 업로드합니다.
소프트웨어 업로드가 완료되면 노드의 소프트웨어가 선택한 버전으로 업데이트되었는지 확인합니다.
15.2.4. SANtricity 업그레이드
예상 시간: 1~1.5시간
SANtricity를 업그레이드하기 전에 SANtricity 소프트웨어 버전을 확인하세요. SANtricity UI로 이동하여 지원 > 업그레이드 센터 > 업그레이드 시작을 클릭합니다. 현재 SANtricity 버전이 표시됩니다.
번들로 제공되는 SANtricity 설치 버전을 확인합니다.
gdcloud artifacts tree oci | grep object-storage/santricity
샘플 출력은 다음과 비슷합니다.
│ │ │ └── gpc-system-object-storage/santricity:11.70.5R1
├── gpc-system-object-storage/santricity:sha256-b145edeb8b24cac420862e7ef09224009aa51da6c6508f5a113753cc07db6ec5.sig
이 예시에서는 버전이 아티팩트에 11.70.5R1로 태그됩니다.
SANTRICITY_OS_VERSION에 버전 값을 저장합니다.
SANtricity 버전이 SANTRICITY_OS_VERSION보다 낮은 경우 다음 단계로 진행하여 SANtricity OS 버전을 업그레이드합니다. 그렇지 않으면 설치로 이동합니다.
15.2.4.1. SANtricity OS 업그레이드
각 스토리지 노드에 대해 SANtricity UI에서 다음 안내를 따르세요.
번들에서 설치 이미지를 가져옵니다.
gdcloud artifacts extract oci santricity \ --image-name=gpc-system-object-storage/santricity:SANTRICITY_OS_VERSION tar -xvzf santricity/gpc-system-object-storage/santricity.tar.gz업그레이드 파일은
santricity/SANTRICITY_OS_VERSION/에서 확인할 수 있습니다.지원 > 업그레이드 센터로 이동합니다. SANtricity OS 소프트웨어 업그레이드에서 업그레이드 시작을 클릭합니다. 찾아보기를 클릭하여 SANtricity OS 소프트웨어 파일을 선택합니다. 다음과 같이 새 소프트웨어 패키지
RCB_SANTRICITY_OS_VERSION_santricity_os_image.dlp를 업로드합니다.
시작을 클릭하고 작업을 실행할 것인지 확인합니다.
업그레이드가 완료되면 버전이 업데이트되었는지 확인합니다.
15.3. 설치
15.3.1. 보안 비밀 만들기
예상 시간: 15~30분
보안 비밀을 만들기 위한 값을 가져오려면 cellcfg 디렉터리를 사용하세요.
objectstoragestoragenodes의 이름을 가져옵니다.$ CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}") $ sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' CELLCFG_PATH/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'샘플 출력:
# CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}") # sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' ./cellcfg/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}' ah-ac-objs01 ah-ac-objs02 ah-ac-objs03스토리지 노드의 BMC IP 주소를 가져옵니다.
echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /bmcIP/p" $CELL_ID-obj-cellobj.yaml | grep bmcIP | awk '{print $2}' | cut -d'/' -f1):8443이전 명령어의 출력에 있는 링크에서 SANtricity 시스템 관리자에 로그인합니다. 이전에 비밀번호를 설정하지 않은 경우 비밀번호를 만들고 로그인합니다.
- SANtricity 비밀번호를 분실한 경우 StorageGRID E2860 직렬 콘솔을 통해 재설정합니다. E2860 디스크 어레이 직렬 포트에 연결하려면 터미널 설정을 115200 8N1로 설정합니다.
두 컨트롤러의 SANtricity 시스템 관리자에서 NTP 서버 주소를 구성합니다.
NTP 서버 주소 가져오기
kubectl get ntpserver -n ntp-system -o custom-columns=NAME:.metadata.name,MANAGEMENT-IP:.status.managementIP ```SANtricity 시스템 관리자에서 Hardware를 선택합니다.
그래픽에 드라이브가 표시되면 선반 뒷면 표시를 클릭합니다. 그래픽이 드라이브 대신 컨트롤러를 표시하도록 변경됩니다.
구성하려는 컨트롤러를 클릭합니다. 컨트롤러의 컨텍스트 메뉴가 표시됩니다.
NTP 서버 구성을 선택합니다. 네트워크 시간 프로토콜 (NTP) 서버 구성 대화상자가 열립니다.
컨트롤러 (A 또는 B)에서 NTP를 사용 설정하고 싶습니다를 선택합니다. 대화상자에 추가 선택사항이 표시됩니다.
NTP 서버 주소 수동 지정을 선택합니다. 이전 명령어로 가져온 IP 중 하나를 사용하여 기본 NTP 서버 주소를 입력합니다.
저장을 클릭합니다.
cell.yaml 파일에서 각 스토리지 노드의 SANtricity 사용자 인증 정보를 포함하는 보안 비밀을 업데이트합니다. 보안 비밀이 없으면 다음 템플릿에 따라 보안 비밀을 추가합니다.
apiVersion: v1 kind: Secret metadata: creationTimestamp: null name: <STORAGE_NODE_NAME>-santricity namespace: gpc-system stringData: password: 'PASSWORD' username: 'admin' type: Opaque이전 단계에 나열된 각 스토리지 노드의 비밀을 만듭니다.
kubectl create secret generic \ --namespace=gpc-system STORAGE_NODE_NAME-santricity \ --from-literal=username=admin \ --from-literal=password=PASSWORD
유효성 검사:
이전 단계에 나열된 각 스토리지 노드에서 다음 명령어를 실행합니다. 이전 단계에서 설정된 Santricity 사용자 이름을 출력합니다. 관리자를 검증합니다.
kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.username}' | base64 -d; echo이전 단계에 나열된 각 스토리지 노드에서 다음 명령어를 실행합니다. Santricity 비밀번호를 출력합니다.
kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.password}' | base64 -d; echo다음 명령어를 실행하여 Santricity Management UI의 URL을 가져옵니다. 사용자 이름과 비밀번호를 사용하여 Santricity에 로그인합니다.
echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /controllerAManagementIP/p" $CELL_ID-obj-cellobj.yaml | grep controllerAManagementIP | awk '{print $2}' | cut -d'/' -f1):8443
문제해결:
유효성 검사 1단계 또는 2단계를 실행할 때 시크릿이 발견되지 않으면 kubectl create secret 단계를 다시 실행합니다.
Santricity Management UI에 로그인할 수 없는 경우 다음 단계를 따르세요.
- StorageGRID E2860 직렬 콘솔을 통해 관리자 사용자 인증 정보를 재설정합니다.
- 마지막 단계를 제외한 이전 단계를 모두 실행합니다.
각 노드의 기존 Santricity 보안 비밀을 삭제합니다.
kubectl delete secret -n gpc-system STORAGE_NODE_NAME-santricity마지막 단계를 실행하여 Santricity 보안 비밀을 다시 만듭니다.
15.3.2. 객체 스토리지 부트스트랩
객체 스토리지 부트스트랩 프로세스는 첫 번째 영역과 조인 영역 간에 다릅니다. 구체적인 상황에 따라 관련 섹션을 참고하세요.
중요: 계속 진행하기 전에 앵커 영역의 전역 API 부트스트래핑이 완료되었는지 확인하세요.
15.3.2.1. 첫 번째 영역에서 객체 스토리지 부트스트랩
다음 명령어를 실행하여 객체 스토리지를 부트스트랩합니다.
gdcloud system objectstorage install --config /CELLCFG_PATH --first-zone --enable-objectstorage-hsm -v 5
15.3.2.2. 조인 영역에서 객체 스토리지 부트스트랩
문제해결:
- Google Cloud CLI 명령어가 시간 초과되거나 오류를 반환하면 반환된 문제를 해결합니다.
- 오류에 관한 자세한 내용은 로그인
gpc-system/obj-infra-cluster-cm-backend-controller포드를 확인하세요.
15.3.2.3. 조인 영역에서 객체 스토리지 부트스트랩
예상 시간: 30~60분
조인 영역에서 객체 스토리지를 부트스트랩하려면 앵커 영역과 조인 영역의 객체 스토리지 리컨실러 간에 조정이 필요합니다. 부트스트랩 시간 동안 리컨실러를 위한 두 영역 간의 보안 및 제어된 통신 채널이 없으므로 IO는 두 영역 간의 객체 스토리지 리컨실러를 위한 보안 통신을 수동으로 촉진해야 합니다.
- 앵커 영역의 루트 관리자 영역 클러스터 및 전역 클러스터에서 클러스터 관리자 사전 정의된 역할을 자신에게 부여합니다. 자세한 내용은 IAM 런북을 참고하세요.
또는 앵커 영역에 다음 두 역할 바인딩을 적용합니다.
전역 API에서 다음을 실행합니다.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: mz-admin-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: mz-bootstrap-global-backend-controllers-role
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: fop-cluster-admin@example.com
루트 관리자 클러스터에서 다음을 실행합니다.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-admin-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: fop-cluster-admin@example.com
앵커 영역에서 명령어를 실행하여 DNS 서버 IP를 가져오고 나중에 사용할 수 있도록 기록합니다.
sh kubectl --kubeconfig /ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH get service gpc-coredns-external-udp -n dns-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}'조인 영역의 DNS 스텁 리졸버를 설정하여 앵커 영역과 연결합니다.
systemd-resolved 사용 중지 및 중지
sh systemctl disable systemd-resolved.service --nowresolv.conf 파일이 있으면 삭제합니다.
sh rm -f /etc/resolv.conf앵커 영역의 DNS 서버 IP를 조인 영역의 resolv.conf에 씁니다.
sh vim /etc/resolv.conf/etc/resolv.conf 파일 콘텐츠의 예:sh nameserver 10.200.40.0
조인 영역에
TokenRequestYAML 파일을 만듭니다.gdcloud system multi-zone create-token-request --zone JOINING_ZONE_NAME --client-type obj-join --cluster kind --namespace gpc-system --output-file TOKEN_REQUEST_YAML_PATH섹션 끝에 있는 참고에 설명된 대로
JOINING_ZONE_NAME을 고객 접수 설문지의 영역 이름으로 바꿉니다.TokenRequest YAML 파일을 앵커 영역으로 전송합니다.
scp TOKEN_REQUEST_YAML_PATH ANCHOR_ZONE_NODE_IP:TOKEN_REQUEST_YAML_PATH앵커 영역의 루트 관리자 전역 클러스터에 TokenRequest YAML을 적용합니다.
kubectl --kubeconfig /GLOBAL_ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_REQUEST_YAML_PATH앵커 영역에 토큰 YAML 파일을 만듭니다.
gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace gpc-system --output-file TOKEN_YAML_PATH토큰 YAML 파일을 조인 영역으로 전송합니다.
scp TOKEN_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:TOKEN_YAML_PATH참여 영역의 KIND 클러스터에 토큰 YAML을 적용합니다.
kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_YAML_PATH앵커 영역에 ObjectStorageBootstrap YAML 파일을 만듭니다.
gdcloud system objectstorage create-bootstrap --output-file OBJECT_STORAGE_BOOTSTRAP_YAML_PATHObjectStorageBootstrap YAML 파일을 조인하는 영역으로 전송합니다.
scp OBJECT_STORAGE_BOOTSTRAP_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:OBJECT_STORAGE_BOOTSTRAP_YAML_PATH참여 영역의 KIND 클러스터에 ObjectStorageBootstrap YAML 파일을 적용합니다.
kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f OBJECT_STORAGE_BOOTSTRAP_YAML_PATH조인 영역에서 객체 스토리지를 부트스트랩합니다.
gdcloud system objectstorage install --config /CELLCFG_PATH --add-zone --enable-objectstorage-hsm -v 5