동적 확장 실행

이 페이지에서는 스토리지 및 컴퓨팅 리소스를 추가하여 시스템을 동적으로 확장하는 프로세스를 설명합니다. 다음 유형의 확장 프로그램에 대한 안내가 제공됩니다.

수평 서버 랙 확장: 영역에 새 랙을 추가합니다. 이 랙에는 컴퓨팅 노드, 콘솔, ToR (top-of-rack) 스위치, 관리 (MGMT) 스위치가 포함됩니다.
세로 서버 확장: 빈 확장 슬롯이 있는 랙에 서버 확장 블록을 추가합니다.
수직 파일 및 블록 스토리지 확장: 기존 스토리지 클러스터에 빈 확장 슬롯이 있는 랙에 스토리지 노드를 추가합니다. 동일한 스토리지 스위치에 연결된 스토리지 노드는 동일한 클러스터에 속합니다.

다양한 유형의 동적 확장에 대한 자세한 내용은 동적 확장 개요를 참고하세요.

시작하기 전에

영역을 변경하기 전에 다음이 준비되어 있어야 합니다.

하드웨어 검사를 수행하고 OEM과 함께 승인합니다 . 랙 검사의 안내를 따릅니다.
KUBECONFIG 생성에 따라 제어 영역 노드의 관리자 클러스터에 대한 KUBECONFIG를 생성합니다. 이 가이드의 모든 kubectl 단계에 생성된 KUBECONFIG 구성 파일을 사용합니다.
루트 클러스터의 현재 Google Distributed Cloud (GDC) 에어 갭 버전이 1.13.1 이상인지 확인합니다.
```
kubectl --kubeconfig $KUBECONFIG get org root -n gpc-system
```
GDC tar 파일을 다운로드합니다. 자세한 내용은 파일 다운로드를 참고하세요.
새 가전제품의 펌웨어 준비:
1. GDC 하드웨어의 패킷 스위칭 기기입니다. 자세한 내용은 스위치를 참고하세요.
2. 수동 ONTAP 업그레이드의 안내에 따라 ONTAP 파일 및 블록 스토리지를 업데이트합니다.
gdcloud system doctor를 사용하여 GDCH 시스템이 정상인지 확인합니다. gdcloud system doctor 명령어를 사용할 수 없는 경우 네트워크 설치 확인의 대체 방법을 사용합니다.

수평 서버 랙 확장 실행

수평 서버 랙 확장을 통해 컴퓨팅 노드, 콘솔, ToR 및 관리 스위치로 구성된 새 랙을 영역에 추가합니다. 이 섹션에 설명된 단계는 단일 랙에 적용됩니다. 랙이 여러 개인 경우 각 랙에 이 단계를 적용합니다.

재설정 작업 실행

다음 장비를 안전하게 재설정해야 합니다.

보안 재설정 직렬 콘솔 서버를 실행합니다. 각 배포마다 직렬 콘솔이 다를 수 있으므로 Google에 문의하여 안내를 받으세요.
Raritan 배전 장치 (PDU)에서 보안 재설정을 실행합니다.
1. 시스템 컨트롤러에서 Raritan PDU로 USB-b 케이블을 연결합니다.
2. 로컬 직렬 콘솔에서 reset factorydefaults 명령어를 사용하여 PDU를 초기화합니다.
3. 이제 PDU가 admin/legrand로 설정됩니다.
보안 삭제의 안내에 따라 보안 재설정을 실행하고, 펌웨어를 업데이트하고, ToR 및 MGMT 스위치를 PowerOn Auto Provisioning (POAP)으로 재설정합니다.
각 서버에 연결하여 보안 삭제를 수동으로 실행합니다.

아티팩트 준비

필요한 구성 파일과 맞춤 리소스를 적용하려면 다음 단계를 따르세요.

gdcloud system assets add 명령어를 사용하여 ZonalExpansion YAML 파일, 하드웨어 CustomResources, 하드웨어 SubcomponentOverride 리소스를 생성합니다.

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af

사용된 각 파일의 FILE_PATH를 바꿉니다. 각 파일이 다른 위치에 있는 경우 이 경로가 다를 수 있습니다.

ZonalExpansion 커스텀 리소스는 추가된 모든 객체를 추적하고 모든 객체의 상태를 보고합니다.

ZonalExpansion YAML 파일을 검토할 때는 다음 안내를 따르세요.

name 필드는 az-ae-expansion와 같이 설명적이어야 합니다.
assets 필드에는 새 확장 랙의 모든 새 어플라이언스가 포함되어야 합니다.

다음은 ZonalExpansion 리소스의 예시입니다.

apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
  name: file
  namespace: gpc-system
spec:
  assets:
  - kind: ManagementSwitch
    name: az-ae-mgmtsw01
  - kind: ManagementSwitch
    name: az-ae-mgmtsw02
  - kind: TORSwitch
    name: az-ae-torsw01
  - kind: TORSwitch
    name: az-ae-torsw02
  - kind: TORSwitch
    name: az-ae-bm01

코드형 인프라 (IAC) 도구를 사용하여 ZonalExpansion 맞춤 리소스를 적용합니다. 자세한 내용은 코드형 인프라 설정을 참고하세요. 또는 IAM-R0004 런북을 따르고 kubectl를 사용하여 이 작업을 실행합니다.
ZonalExpansion 및 NonCompliantDeviceSet 리소스가 생성되었는지 확인합니다.
1. ZonalExpansion 리소스의 상태를 확인합니다.
```
kubectl --kubeconfig $KUBECONFIG get -A zonalexpansion -o yaml
```
  이 단계에서 프리플라이트 검사는 ReasonAssetsNotExisted이라는 이유로 실패해야 합니다.
2. NonCompliantDeviceSet 리소스는 noncompliantassets-이 접두사로 붙은 이름으로 존재해야 합니다.
3. 애셋 목록은 ZonalExpansion 커스텀 리소스의 assets 필드와 동일해야 합니다.
OLT-R0003의 안내에 따라 애셋을 업데이트합니다.
새 랙의 ToR 및 MGMT 스위치를 기존 랙의 집계 스위치에 연결합니다.
스위치를 베이스 랙에 물리적으로 연결합니다.

서버 부트스트랩 완료

이 단계는 대부분 자동화되어 있지만 일부 단계는 필요합니다. 부트스트랩 진행 상황을 모니터링하고 실패 사례를 처리해야 합니다.

컨트롤러는 조건 PreflightCheck=True이 충족되면 부트스트랩 절차를 자동으로 시작합니다.
NetworkBootstrapSucceed=True 조건이 ZonalExpansion 커스텀 리소스에 게시되었는지 확인합니다. 이 조건은 ZonalExpansion.Status.PNETBootstrapStatus 위치에 있습니다.
스위치가 NonCompliantDeviceSet 목록에서 삭제되었는지 확인합니다.
```
kubectl --kubeconfig $KUBECONFIG get noncompliantdeviceset noncompliantassets-EXPANSION_NAME -A -o yaml
```
EXPANSION_NAME을 영역 확장 커스텀 리소스의 이름으로 바꿉니다.

반환된 YAML 파일의 Spec.Assets 필드에 스위치가 없는지 확인합니다. 이렇게 삭제하면 GDC가 다른 어플라이언스 부트스트랩 절차를 허용하도록 네트워크 ACL을 업데이트할 수 있습니다. 업데이트된 두 네트워크 ACL은 quarantine-mgmt-switch-acl과 quarantine-data-switch-acl입니다.

서버의 모든 베이스보드 관리 컨트롤러 (BMC) IP 주소를 나열하고 iLO IP 주소가 새 베어메탈 머신에 할당되었으며 부트스트랩을 시작할 수 있는지 확인합니다.

kubectl --kubeconfig $KUBECONFIG get servers -n gpc-system -o=custom-columns=SERVER:.metadata.name,BMC_IP:.spec.bmc.ip

출력 예시:

 SERVER       BMC_IP
 yz-aa-bm01   10.128.136.2
 yz-aa-bm02   10.128.136.3
 yz-aa-bm03   10.128.136.4
 yz-ab-bm01   10.128.136.66
 yz-ab-bm02   10.128.136.67
 yz-ab-bm03   10.128.136.68
 yz-ac-bm01   10.128.136.130
 yz-ac-bm02   10.128.136.131
 yz-ac-bm03   10.128.136.132
 yz-ac-bm04   10.128.136.133
 yz-ac-bm05   10.128.136.134
 yz-ac-bm06   10.128.136.135
 yz-ac-bm07   10.128.136.136
 yz-ac-bm08   10.128.136.137
 yz-ac-bm09   10.128.136.138
 yz-ac-bm10   10.128.136.139
 yz-ac-bm11   10.128.136.140
 yz-ac-bm12   10.128.136.141
 yz-ac-bm13   10.128.136.142
 yz-ac-bm14   10.128.136.143
 yz-ac-bm15   10.128.136.144
 yz-ac-bm16   10.128.136.145
 yz-ac-bm17   10.128.136.146
 yz-ac-bm18   10.128.136.147

GDC는 보안 삭제, 확인, BIOS 설정 업데이트, 기타 부트스트랩 절차를 실행하기 위해 서버를 병렬로 부트스트랩합니다.

ServerBootstrapSucceeded=True 조건이 ZonalExpansion 커스텀 리소스에 게시되었는지 확인합니다. 이 조건은 ZonalExpansion.Status.SERVBootstrapStatus 위치에서 찾을 수 있습니다.
- 부트스트랩이 성공하면 서버 베어메탈 호스트 상태가 Available 또는 Provisioned 상태가 됩니다.
- CLI 상세도 수준이 4인 경우 아직 준비되지 않은 서버 목록과 함께 "Not all servers in the ZonalExpansion are bootstrapped"와 같은 로그가 표시됩니다.

이제 서버가 NonCompliantDeviceSet 목록에서 삭제되었는지 확인합니다.

kubectl --kubeconfig $KUBECONFIG get noncompliantdevicesets -n gpc-system "noncompliantassets-EXPANSION_NAME" -o yaml

ExpansionSucceeded=True 조건이 ZonalExpansion 커스텀 리소스에 게시되었는지 확인합니다. 이 조건은 ZonalExpansion.Status.Conditions 위치에 있습니다.

NonCompliantDeviceSet 목록이 삭제되었는지 확인합니다.

kubectl --kubeconfig $KUBECONFIG get noncompliantdeviceset noncompliantassets-EXPANSION_NAME -A

예상 출력:

`Error from server (NotFound): noncompliantdevicesets.system.private.gdc.goog "noncompliantassets-EXPANSION_NAME" not found`

세로 서버 확장 실행

수직 서버 확장을 통해 빈 확장 슬롯이 있는 랙에 서버 확장 블록을 추가합니다. 이 확장 프로그램에 관한 많은 안내가 수평 컴퓨팅 확장 프로그램과 유사합니다. 세로 서버 랙 확장을 수행하려면 다음 단계를 따르세요.

용량 6개 노드를 차지하는 표준 서버 블록 또는 용량 3개 노드를 사용하는 GPU 서버 블록을 물리적으로 설치합니다. 랙당 여러 블록을 추가할 수 있습니다. 경고: mgmtsw 또는 aggsw 스위치에 케이블을 연결하지 마세요. 자세한 내용은 스위치를 참고하세요.
전원 공급 장치를 제외한 케이블 연결은 실행하지 마세요. 이 단계를 통해 서버 전원 켜기 프로세스에서 서버가 도착 시 오프라인이 아닌지 확인할 수 있습니다.

gdcloud system assets add 명령어를 사용하여 ZonalExpansion YAML 파일과 하드웨어 SubcomponentOverride 리소스를 생성합니다.

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af

사용된 각 파일의 FILE_PATH를 바꿉니다. 각 파일이 다른 위치에 있는 경우 이 경로가 다를 수 있습니다.

ZonalExpansion YAML 파일을 검토할 때는 다음 안내를 따르세요.

name 필드는 az-ae-expansion와 같이 설명적이어야 합니다.
assets 필드에는 새 확장 랙의 모든 새 어플라이언스가 포함되어야 합니다.

다음은 ZonalExpansion 리소스의 예시입니다.

apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
  name: file
  namespace: gpc-system
spec:
  assets:
  - kind: ManagementSwitch
    name: az-ae-mgmtsw01
  - kind: ManagementSwitch
    name: az-ae-mgmtsw02
  - kind: TORSwitch
    name: az-ae-torsw01
  - kind: TORSwitch
    name: az-ae-torsw02
  - kind: TORSwitch
    name: az-ae-bm01

방금 만든 ZonalExpansion 커스텀 리소스를 클러스터에 적용합니다.
ZonalExpansion 및 NonCompliantDeviceSet 리소스가 생성되었는지 확인합니다.
1. ZonalExpansion 리소스의 상태를 확인합니다. 이 단계에서 프리플라이트 검사는 ReasonAssetsNotExisted이라는 이유로 실패해야 합니다.
2. NonCompliantDeviceSet 리소스는 noncompliantassets-이 접두사로 붙은 이름으로 존재해야 합니다.
3. 애셋 목록은 ZonalExpansion 커스텀 리소스의 assets 필드와 동일해야 합니다.
OLT-R0003의 안내에 따라 애셋을 업데이트합니다.
OLT-R0001 런북에 따라 격리 스위치 ACL이 실행 중인지 확인합니다.
아직 완료하지 않은 경우 서버의 케이블을 연결합니다. Hewlett Packard Enterprise (HPE)에서 제공하는 케이블 연결 파일을 따릅니다.
서버 부트스트랩 프로세스가 시작되고 성공적으로 완료되는지 확인합니다. 자세한 내용은 서버 부트스트랩 완료를 참고하세요.

세로 파일 및 블록 스토리지 확장 실행

이 안내에는 수직 또는 단일 랙 스토리지 노드 확장을 수행하는 데 필요한 단계가 포함되어 있습니다. 스토리지 노드 확장은 기존 랙의 스토리지 기능을 확장하기 위해 새 ONTAP 스토리지 노드를 추가할 때 실행됩니다. 새 스토리지 기기의 케이블 연결 안내는 제공되지 않으며, 기존 클러스터에서 새 스토리지 노드를 삭제, 업그레이드, 추가하는 절차만 제공됩니다.

스토리지 노드 확장을 위한 설정 실행

다음 단계에 따라 스토리지 노드 확장을 위해 클러스터를 준비하세요.

KUBECONFIG 생성에 따라 제어 영역 노드의 관리자 클러스터에 대한 KUBECONFIG를 생성합니다. 이 가이드의 모든 kubectl 단계에 생성된 KUBECONFIG 구성 파일을 사용합니다.

노드 확장을 위한 초기 설정을 실행하는 동안 저장소 조정자를 사용 중지하려면 SubcomponentOverride 리소스를 적용하세요.

kubectl --kubeconfig $KUBECONFIG apply -f - <<EOF
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
    name: file-storage-sub-override
    namespace: root
spec:
    subComponentRef: "file-storage"
    backend:
        operableParameters:
            controller:
                enableReconcilers: ""
                disableReconcilers: "*"
EOF

재정의가 작동하고 file-storage 조정자가 사용 중지되었는지 확인합니다.
```
kubectl --kubeconfig $KUBECONFIG describe deployment file-storage -n
file-system | grep reconcilers
```
다음과 같이 표시되어야 합니다.
```
--enable-reconcilers=
--disable-reconcilers=*
```
이 상태가 표시되지 않으면 SubcomponentOverride 리소스가 적용될 때까지 몇 분 정도 기다린 후 이 확인을 다시 실행합니다. 몇 분 후에도 SubcomponentOverride가 적용되지 않으면 GDC 엔지니어링 지원팀에 문의하세요.

gdcloud system assets add 명령어를 사용하여 ZonalExpansion YAML 파일과 하드웨어 SubcomponentOverride 리소스를 생성합니다.

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af
```
Replace FILE_PATH for each of the files used. Note, this path might be different if each file is in a different location.

Use the following guidance when reviewing the `ZonalExpansion` YAML file:

The `name` field must be descriptive, such as aj-ad-expansion.
The `assets` field must include all new appliances in the new expansion rack.
Here is an example of a `ZonalExpansion` resource:

```sh
apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
name: file
namespace: gpc-system
spec:
assets:
- kind: StorageNode
    name: aj-ad-stge03-01
- kind: StorageNode
    name: aj-ad-stge03-02
```

방금 만든 ZonalExpansion 커스텀 리소스를 클러스터에 적용합니다.
ZonalExpansion 및 NonCompliantDeviceSet 리소스가 생성되었는지 확인합니다.
1. ZonalExpansion 리소스의 상태를 확인합니다. 이 단계에서 프리플라이트 검사는 ReasonAssetsNotExisted이라는 이유로 실패해야 합니다.
2. NonCompliantDeviceSet 리소스는 noncompliantassets-이 접두사로 붙은 이름으로 존재해야 합니다.
3. 애셋 목록은 ZonalExpansion 맞춤 리소스의 애셋 필드와 동일해야 합니다.
IaC 도구를 사용하여 다음 하드웨어 애셋 SubcomponentOverride 리소스를 루트 관리자 클러스터에 적용합니다.
- file/file-storage.yaml
- inv/inv-core.yaml
참고: 생성된 SubcomponentOverride에는 클러스터에 이미 적용된 재정의가 포함되지 않습니다. 현재 SubcomponentOverride를 캡처하고 생성된 각 SubcomponentOverride에 추가하여 재정의가 손실되지 않도록 합니다.

새 노드가 클러스터에 추가되었는지 확인합니다.

kubectl --kubeconfig $KUBECONFIG get storagenodes -n gpc-system

최근 연령 값이 추가된 새 노드 커스텀 리소스가 표시됩니다.

  NAME              MGMTIP           INTERCONNECTIP   MODEL      AGE
  aj-ad-stge01-01   172.22.243.129   169.254.0.1      AFF-A250   37d
  aj-ad-stge01-02   172.22.243.130   169.254.0.3      AFF-A250   37d
  aj-ad-stge03-01   172.22.243.133   169.254.0.9      AFF-A400   20d
  aj-ad-stge03-02   172.22.243.134   169.254.0.11     AFF-A400   20d

describe 명령어를 사용하여 두 노드에 관한 정보를 가져옵니다. 이후 단계에 필요한 정보가 포함되어 있기 때문입니다.
```
kubectl --kubeconfig $KUBECONFIG describe storagenode NODE_NAME -n gpc-system
```
NODE_NAME을 생성된 각 노드의 이름으로 바꿉니다.

출력 예시:
```
NAME              MGMTIP           INTERCONNECTIP   MODEL      AGE
aj-ad-stge03-02   172.22.243.134   169.254.0.11     AFF-A400   20d
```

스토리지 노드 확장 프로세스 완료

다음 단계에 따라 스토리지 노드 확장 프로세스를 완료하세요.

새 스토리지 노드를 수동으로 업그레이드합니다. 각 노드에 대해 시스템 컨트롤러에서 파일을 제공하는 ONTAP 수동 업그레이드의 단계를 따릅니다.
새 스토리지 노드의 보안 삭제를 실행합니다. 새 ONTAP 노드의 경우 ONTAP 재설정의 단계에 따라 노드를 재설정합니다.
새 스토리지 노드를 초기화합니다. 이전 단계에서 설명한 새로 추가된 StorageNode 맞춤 리소스의 정보를 사용합니다. 각 노드에 대해 ONTAP 어플라이언스 초기화의 단계를 실행합니다.

참고: cellcfg 단계를 실행하지 마세요. 대신 이전 단계에서 캡처한 값을 사용하세요.
ONTAP 설정에 따라 새 노드에서 현재 클러스터로 케이블을 연결합니다.
기존 클러스터에 새 노드 클러스터 추가 실행의 안내에 따라 클러스터에 새 노드를 추가합니다.

동적 확장 문제 해결

서비스 매뉴얼의 다음 런북을 사용하여 동적 확장 문제를 해결하세요.

OLT-R0001
OLT-R0002
OLT-R0003