예상 소요 시간: 7시간
작동 가능한 구성요소 소유자: KUB/SERV/OBJ/FILE/PNET기술 프로필: 배포 엔지니어
이 가이드에서는 내부 클러스터와 조직 인프라 클러스터의 제어 영역 역할을 하는 루트 관리자 클러스터를 만듭니다.
19.1. 라우팅 구성 설정
부트스트래퍼 서버 설치 중에 정적 경로가 추가되었는지 확인합니다. 정적 경로가 누락된 경우 부트스트래퍼에 정적 경로를 추가합니다.
DATA_CIDR=$(kubectl get cidrclaim -n gpc-system instance-external-cidr -o jsonpath={.spec.ipv4Spec.staticCidrBlocks[0]})
DATA_GATEWAY=$(kubectl get subnetclaims -n root control-plane-subnet -o jsonpath={.status.ipv4SubnetStatus.gateway})
ip route replace ${DATA_CIDR} via ${DATA_GATEWAY}
이 경로는 부트스트래퍼의 데이터 플레인 인터페이스에서 루트 관리자 클러스터의 API 서버에 대한 액세스를 제공합니다. GDC의 API 서버에 대한 자세한 내용은 전역 및 영역 API 서버를 참고하세요.
19.2. 루트 관리자 클러스터 만들기
다음 명령어는 컨트롤 플레인 노드가 3개인 루트 관리자 클러스터를 만듭니다. 기본 테넌트 모드는 멀티 테넌트 모드입니다.
gdcloud system admin-cluster install -v=3 \
--tenant-mode=multi \
--root-admin-node-count=3 \
--generate-admin-yaml \
--addon-manager-manifests-set harbor.postgresqlHA.enabled=true \
--addon-manager-manifests-set harbor.productionEnvironment.enabled=true \
--addon-manager-manifests-set storage.mode=ontap \
--addon-manager-manifests-set gpuFeature.enabled=true \
--addon-manager-manifests-set rootAdmin.controller.adminLBPoolSize=23 \
--addon-manager-manifests-set rootAdmin.controller.systemLBPoolSize=60 \
--addon-manager-manifests-set network.noInternalSubnet=false \
--addon-manager-manifests-set minStage=FEATURE_THRESHOLD
루트 관리자 클러스터를 만들려면 클러스터 CR의 구성 파일이 필요합니다. 구성 파일은 기본적으로 자동으로 생성됩니다. --generate-admin-yaml 플래그를 false로 설정하고 --admin-yaml-path가 타겟 구성 경로를 가리키도록 지정하여 맞춤 클러스터 구성을 허용할 수도 있습니다.
루트 관리자 클러스터 설치가 완료되면 루트 관리자 클러스터의 kubeconfig가 /root/release/root-admin/root-admin-kubeconfig에 저장됩니다.
클러스터 설치 후 사용자 관리자 사용자 인터페이스 (UI)의 URL이 출력됩니다. 나중에 작업에서 사용할 수 있도록 기억해 둡니다. 다음 명령어를 사용하여 검색할 수도 있습니다.
gdcloud system admin-cluster describe
19.3. 루트 관리자 클러스터에 구성요소 배포
다음 명령어는 작동 가능한 구성요소 수명 주기 템플릿을 루트 관리자 클러스터에 배포합니다.
gdcloud system component deploy --kubeconfig KUBECONFIG --names=* --pivot-from=/root/.kube/config
19.4. 루트 관리자의 기능 게이트 구성
production와 다른 기능 단계 기준이 있는 경우 OOPS-P0072에 따라 기준에 맞게 기능 게이트를 업데이트해야 합니다.
19.5. 부트스트래퍼에서 스텁 리졸버 구성
다음 명령어를 사용하여 부트스트래퍼에서 DNS 스텁 리졸버를 설정합니다. 이 스텁 리졸버는 콘솔에 액세스하는 데 필요합니다.
gdcloud system dns install
이 구성은 다음 다이어그램과 같이 부트스트래퍼에서 모든 조직의 도메인 이름을 확인할 수 있도록 합니다.
19.6. iLo IP 주소 설정
다음 단계에서는 관리자 노드의 ILO IP 주소를 static로 설정합니다.
ADMIN_NODE=NODE NAME
RACK=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.metadata.labels.system\.private\.gdc\.goog/rack-name}')
ILO_IP=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.ip}')
ILO_GATEWAY=$(kubectl --kubeconfig KUBECONFIG get subnetclaims -n root $RACK-mgmtsw01-server-bmc-subnet -o jsonpath='{.status.ipv4SubnetStatus.gateway}')
BMC_CREDS=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.credentialsRef.name}')
ILO_USER=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.username}' | base64 --decode)
ILO_PASS=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.password}' | base64 --decode)
echo Target Server: $ADMIN_NODE
echo ILO IP: $ILO_IP
echo ILO Gateway: $ILO_GATEWAY
echo ILO Username: $ILO_USER
echo ILO Password: $ILO_PASS
클러스터의 정보를 기반으로 위의 정보가 올바른지 확인합니다. 앞의 정보가 정확하면 다음 명령어를 실행합니다.
DHCP를 사용 중지합니다.
curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"DHCPv4": {"DHCPEnabled": false}}' | jq '.'예상 결과:
MessageId: iLO.2.15.ResetRequiredIP 주소와 게이트웨이를 구성합니다.
curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"IPv4Addresses":[{"Address":"'${ILO_IP}'","Gateway":"'${ILO_GATEWAY}'","SubnetMask":"255.255.255.0"}],"IPv4StaticAddresses": [{"Address": "'${ILO_IP}'", "Gateway": "'${ILO_GATEWAY}'", "SubnetMask": "255.255.255.0"}]}' | jq .예상 결과:
MessageId: Base.1.4.SuccessiLO 관리자를 재설정합니다.
curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" https://${ILO_IP}/redfish/v1/Managers/1/Actions/Manager.Reset --data '{"ResetType":"ForceRestart"}' -X POST | jq .예상 결과:
MessageId: iLO.2.15.ResetInProgress이더넷 설정이 적용되었는지 확인합니다. 응답이 멈추면 재설정이 완료되지 않은 것입니다. 현재 curl 명령어를 취소한 후 20초 동안 기다렸다가 다시 시도하세요.
curl --insecure -u ${ILO_USER}:${ILO_PASS} https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 -X GET | jq .
각 단계의 HTTP 반환이 예상 결과와 일치하는지 확인하여 성공을 확인합니다.
클러스터에 있는 모든 루트 관리자 노드에 이전 단계를 반복합니다.
19.7. OI 네트워크 및 Google Distributed Cloud (GDC) 에어 갭 연결 설정
이 섹션에서는 Operations Suite 인프라 (OI)와 Distributed Cloud 네트워크가 연결을 설정하도록 구성 파일을 프로비저닝하는 방법을 설명합니다.
이러한 단계에서는 일부 Distributed Cloud 파일에 대한 액세스와 런타임 네트워크 정보를 가져오기 위한 Distributed Cloud 인스턴스의 루트 관리자 클러스터에 대한 연결이 필요합니다.
19.7.1. 시작하기 전에
배포 프로세스의 이 단계에서는 다음이 모두 충족되어야 합니다.
두 OIR 스위치 모두 케이블로 연결되고, 전원이 켜지고, 적절한 버전으로 업그레이드되고, 기본 및 ACL 구성이 적용됩니다.
두 OIF 방화벽 모두 케이블로 연결되고, 전원이 켜지고, 적절한 버전으로 업그레이드되고, FIPS-CC 모드가 사용 설정되고, 기본 구성이 적용됩니다.
전체 Distributed Cloud 연결 프로비저닝을 완료하려면 Distributed Cloud 인스턴스가 네트워크 부트스트랩을 완료하고 종류 클러스터에서 루트 관리자 클러스터로 이동해야 합니다.
19.7.2. 환경 준비
다음 정보를 수집하고 환경 변수를 설정하여 다음 단계를 위한 환경을 준비합니다.
OI는 로컬 또는 원격으로 두 가지 방법으로 연결할 수 있습니다.
로컬 연결은 동일한 데이터 센터의 랙 간 광섬유 연결을 사용하여 OI를 Distributed Cloud에 직접 연결합니다.
원격 연결은 장거리 전송을 사용하여 다른 위치에 연결됩니다.
이 사양은 Distributed Cloud 인터커넥트 구성을 프로비저닝하는 데 필요한 interconnect.yaml 파일에 제공할 수 있습니다.
이 파일에는 GDC 인터커넥트를 구성하는 데 필요한 모든 정보가 포함되어 있습니다.
19.7.2.1. 상호 연결 YAML 사양
| 속성 |
설명 |
예 |
|---|---|---|
zones[ ] map |
OI 배포가 연결해야 하는 Distributed Cloud 셀에 관한 정보입니다. 분산 클라우드 셀 목록에 연결하려면 각 영역에 있는 각 분산 클라우드 셀의 정보가 포함된 zones 목록을 지정합니다.
영역 옵션 |
예:zones: |
19.7.2.2. 영역 옵션
interconnect.yaml 파일에서 Distributed Cloud 셀에 관한 정보를 전달합니다.
| 속성 |
설명 |
사용량 |
|---|---|---|
zoneName문자열 |
OI 배포가 연결되어야 하는 Distributed Cloud 셀 약어입니다. | zones: |
uplinkSpeeduint32 |
(선택사항) 연결의 업링크 속도를 제공합니다(10 또는 100).
|
값:10, 100기본값: 10uplinkSpeed: 100 |
localInstanceint |
ocit.yaml 파일의 OI 배포 사이트 InstanceID입니다.로컬 연결은 Operations Suite Infrastructure Core Rack (OIR) 사이트를 동일한 데이터 센터의 랙 간 광섬유 연결을 사용하여 Distributed Cloud에 직접 연결합니다. |
zones: |
remoteInstance[ ] int |
ocit.yaml 파일에서 OI 배포 사이트의 InstanceID(s)원격 연결은 장거리 전송을 사용하여 다른 위치에 연결됩니다. 모든 OIR 사이트의 구성이 지정된 Distributed Cloud 셀에 연결되도록 remoteInstance 값 목록을 제공할 수 있습니다.
|
zones: zones: |
로컬 연결인 경우 interconnect.yaml 파일을 다음과 같이 구성합니다.
zones:
- zoneName: ah
uplinkSpeed: 100
localInstanceID: 1
cellCfg: /path/to/cellcfg
원격 연결인 경우 interconnect.yaml 파일을 다음과 같이 구성합니다.
zones:
- zoneName: ah
uplinkSpeed: 100
remoteInstanceIDs:
- 2
cellCfg: /path/to/cellcfg
다중 사이트 OI 배포의 경우 interconnect.yaml 파일을 다음과 같이 지정합니다.
zones:
- zoneName: ah
uplinkSpeed: 100
localInstanceID: 1
remoteInstanceIDs:
- 2
cellCfg: /path/to/cellcfg
19.7.3. 스위치 구성 생성
이 단계에서는 Distributed Cloud에 연결을 프로비저닝하기 위해 네트워크 기기에 적용할 패치 구성을 생성합니다.
occonfigtool generate cell config -c /path/to/interconnect.yaml -o path/to/ocit.yaml
이렇게 하면 각 사이트에 대해 다음 구성 파일이 생성됩니다.
| 구성 파일 | 기기 | 함수 |
|---|---|---|
| occoresw101.incremental | occoresw101 | Distributed Cloud 인스턴스에 연결하기 위해 기기를 패치하는 구성 |
| occoresw101.acl | occoresw101 | 분산 클라우드 네트워크를 사용하여 트래픽 시행을 위해 ACL을 패치하는 구성입니다. |
| occoresw102.incremental | occoresw102 | Distributed Cloud 인스턴스에 연결하기 위해 기기를 패치하는 구성 |
| occoresw102.acl | occoresw102 | 분산 클라우드 네트워크를 사용하여 트래픽 시행을 위해 ACL을 패치하는 구성입니다. |
| ocsw101.incremental | ocs1w01 | Distributed Cloud 인스턴스에 연결하기 위해 기기를 패치하는 구성 |
| ocsw101.acl | ocsw101 | 분산 클라우드 네트워크를 사용하여 트래픽 시행을 위해 ACL을 패치하는 구성입니다. |
| ocsw102.incremental | ocsw102 | Distributed Cloud 인스턴스에 연결하기 위해 기기를 패치하는 구성 |
| ocsw102.acl | ocsw102 | 분산 클라우드 네트워크를 사용하여 트래픽 시행을 위해 ACL을 패치하는 구성입니다. |
19.7.4. 방화벽 정책 생성
방화벽 규칙을 생성하려면 occonfigtool가 루트 관리자 클러스터의 Kubernetes API에 액세스해야 합니다. KUBECONFIG 환경 변수가 root-admin-kubeconfig로 설정되어 있는지 확인합니다.
export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
export OCIT_CONFIG_FILE=/path/to/ocit.yaml
다음을 실행하여 방화벽 규칙을 생성합니다.
occonfigtool generate fwrules -o ${OCIT_CONFIG_FILE:?}
| 구성 파일 | 기기 | 함수 |
|---|---|---|
| firewall-rules.base | occorefw01 | Distributed Cloud 인스턴스에 연결하기 위해 기기를 패치하는 구성 |
19.7.5. 구성 적용
출력 파일을 사용하여 이전 단계에서 스위치 및 방화벽에 사용한 것과 동일한 절차를 사용하여 각 네트워크 기기에 구성을 적용합니다.
19.8. Distributed Cloud RoutePolicy 리소스 업데이트
Distributed Cloud는 경로 정책을 사용하여 라우팅 테이블에 공지할 수 있는 네트워크를 적용합니다.
OI를 외부 네트워크로 추가할 때 새 네트워크를 예상하도록 RoutePolicy CR을 업데이트해야 합니다.
이를 위해서는 kubectl을 사용하여 root-admin-cluster에 액세스해야 합니다. 적절한 KUBECONFIG 변수가 설정되어 있는지 확인합니다.
export KUBECONFIG=/root/deploy/root-admin/root-admin-kubeconfig
확인하려면 다음을 실행하세요.
kubectl get routepolicy -n gpc-system
다음과 같거나 비슷한 출력이 표시됩니다.
NAME AGE
customerpeering-routepolicy 19d
datacenter-routepolicy 19d
mgmtnetworkoperationcenter-routepolicy 19d
networkoperationcenter-routepolicy 19d
이 단계에서는 networkoperationcenter-routepolicy 및 mgmtnetworkoperationcenter-routepolicy에 중점을 둡니다.
19.8.1.1. 데이터 네트워크 경로 정책 패치
ocinfo.opscenter.local.txt에서 다음 서브넷 (네트워크 및 접두사 길이 포함)을 가져옵니다.
- OCCORE-SERVERS(다음 예에서
$OCCORE_SERVERS_NET로 사용됨) - 다음 예에서
$OC_WORKSTATIONS_NET로 사용되는 OC-WORKSTATIONS
다음 변수를 채워 경로 정책을 조정하는 데 이러한 값을 사용합니다.
export OCCORE_SERVERS_NET=$OCCORE_SERVERS_NET
export OC_WORKSTATIONS_NET=$OC_WORKSTATIONS_NET
예를 들면 다음과 같습니다.
export OCCORE_SERVERS_NET=172.21.0.0/24
export OC_WORKSTATIONS_NET=172.21.32.0/24
환경 변수가 설정되면 다음 kubectl 명령어를 실행합니다.
kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
--type=json -p="[
{
'op': 'add',
'path': '/spec/in/ipPrefixList/0',
'value': {
'action': 'Permit',
'ipPrefix': '${OCCORE_SERVERS_NET:?}',
'prefixLengthMatchers': [
{
'operator': 'LE',
'prefixLength': 32
}
]
}
}
]"
kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
--type=json -p="[
{
'op': 'add',
'path': '/spec/in/ipPrefixList/0',
'value': {
'action': 'Permit',
'ipPrefix': '${OC_WORKSTATIONS_NET:?}',
'prefixLengthMatchers': [
{
'operator': 'LE',
'prefixLength': 32
}
]
}
}
]"
출력 예시:
routepolicy.system.private.gdc.goog/networkoperationcenter-routepolicy patched
19.8.1.2. 패치 관리 네트워크 라우팅 정책
ocinfo.opscenter.local.txt에서 다음 서브넷 (네트워크 및 접두사 길이 포함)을 가져옵니다.
- OCCORE-JUMPHOSTS(다음 예에서
$OCCORE_JUMPHOSTS_NET로 사용됨) - 다음 예시에서
$OCCORE_ILOS_NET로 사용되는 OCCORE-ILOS
다음 변수를 채워 경로 정책을 조정하는 데 이러한 값을 사용합니다.
export OCCORE_JUMPHOSTS_NET=$OCCORE_JUMPHOSTS_NET
export OCCORE_ILOS_NET=$OCCORE_ILOS_NET
예를 들면 다음과 같습니다.
export OCCORE_JUMPHOSTS_NET=172.21.2.0/27
export OCCORE_ILOS_NET=172.21.2.32/27
환경 변수가 설정되면 다음 kubectl 명령어를 실행합니다.
kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
--type=json -p="[
{
'op': 'add',
'path': '/spec/in/ipPrefixList/0',
'value': {
'action': 'Permit',
'ipPrefix': '${OCCORE_JUMPHOSTS_NET:?}',
'prefixLengthMatchers': [
{
'operator': 'LE',
'prefixLength': 32
}
]
}
}
]"
kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
--type=json -p="[
{
'op': 'add',
'path': '/spec/in/ipPrefixList/0',
'value': {
'action': 'Permit',
'ipPrefix': '${OCCORE_ILOS_NET:?}',
'prefixLengthMatchers': [
{
'operator': 'LE',
'prefixLength': 32
}
]
}
}
]"
출력 예시:
routepolicy.system.private.gdc.goog/mgmtnetworkoperationcenter-routepolicy patched
19.9. OI Distributed Cloud 네트워크 연결 확인
배포 시점에서 다음이 충족되어야 합니다.
occoresw101및occoresw102이 모두base,acl,incremental,incremental-acl구성 파일로 재구성됩니다.ocsw101와ocsw102모두base,acl,incremental,incremental-acl구성 파일로 구성됩니다.occorefw101및occoref102는 모두base및firewall-rules.base구성 파일로 구성됩니다.- 데이터 센터와 운영 센터 간의 업링크가 연결되어 작동합니다.
- Distributed Cloud 간의 물리적 업링크가 확인됩니다.
위의 조건 중 하나라도 충족되지 않으면 현재 상태에 따라 다음 출력이 크게 달라질 수 있으며 프로덕션에서 예상되는 동작이 생성되지 않을 수 있습니다.
19.9.1. 예상 출력
다음 스니펫은 다음 명령어의 알려진 양호한 환경의 출력을 보여줍니다.
show ip bgp summary vrf allshow ip bgp vrf allshow ip route vrf allshow lldp neighbors
이러한 스니펫은 동일한 명령어를 사용하여 프로덕션 환경과 비교하는 데 사용할 수 있습니다.
19.9.2. 키 유효성 검사
다음은 출력에서 확인해야 할 주요 사항입니다.
Idle,Active또는Closing상태인 BGP 세션이 없습니다.- 모든 BGP 세션에
0보다 큰State/PrxRcd값이 표시됩니다. - 모든 BGP 세션에 지속적으로 증가하는
Up/Down타이머가 표시됩니다. - 분산 클라우드
externalCIDR접두사 (CIQ에 있음)는GDCH-DATA,GDCH-DATA-TRANSIT,OC-WORKSTATIONS,OCCORE-SERVERSVRF의 라우팅 테이블과 BGP 테이블에 있습니다. - Distributed Cloud
oobManagementCIDRs(CIQ에 있음)는GDCH-MGMT,GDCH-MGMT-TRANSIT,HW-INFRAVRF의 라우팅 테이블과 BGP 테이블에 있습니다.
19.9.3. OCCORESW
다음 표는 Distributed Cloud 인터커넥트의 각 occore switch에서 예상되는 출력을 보여줍니다.
이 단계를 진행하기 전에 모든 네트워크 유효성 검사를 완료해야 합니다.
여기에 설명된 BGP 인접 항목과 경로가 앞에서 언급한 BGP 인접 항목과 경로와 함께 있어야 합니다.
모든 스위치에서 출력을 검증합니다.
| VRF |
BGP 인접 항목 |
BGP 이웃에서 수신된 예상 경로 |
BGP 이웃에 공지된 예상 경로 |
|---|---|---|---|
| GDCH-DATA-TRANSIT | AGGSW01 |
|
|
| GDCH-DATA-TRANSIT | AGGSW02 |
|
|
| GDCH-DATA-TRANSIT | OCCOREFW를 OC-DATA VRF에 사용하는 헤어핀 BGP 세션 |
|
|
| OC-DATA | OCSW01 BGP 세션 |
|
|
| OC-DATA | OCSW02 BGP 세션 |
|
|
| OC-DATA | OCCORESW BGP 세션 |
|
|
| GDCH-MGMT-TRANSIT | MGMTAGGSW01 |
|
|
| GDCH-MGMT-TRANSIT | MGMTAGGSW02 |
|
|
| GDCH-MGMT-TRANSIT | OCCOREFW를 HW-INFRA VRF에 사용하여 헤어핀된 BGP 세션 |
|
19.9.4. OCSW
다음 표는 Distributed Cloud 상호 연결 절차를 실행한 후 각 oc switch에서 예상되는 출력을 보여줍니다.
이 단계를 진행하기 전에 모든 네트워크 유효성 검사를 완료해야 합니다.
여기에 설명된 BGP 인접 항목과 경로가 앞에서 언급한 BGP 인접 항목과 경로와 함께 있어야 합니다.
모든 스위치에서 출력을 검증합니다.
| VRF |
BGP 인접 항목 |
BGP 이웃에서 수신된 예상 경로 |
|---|---|---|
| OC-DATA | OCCORESW01 BGP 세션 |
|
| OC-DATA | OCCORESW02 BGP 세션 |
|
출력 명령어 스니펫은 Distributed Cloud 유효성 검사 표시 명령어에서 확인할 수 있습니다.
19.9.5. 멀티 사이트 OI 배포 유효성 검사
다음 섹션에서는 상호 연결된 여러 Distributed Cloud 셀을 사용하여 멀티 사이트 배포를 검증하는 방법을 자세히 설명합니다. 이 단계에서 사이트가 두 개인 토폴로지는 다음과 같습니다.
- 파란색 연결은 사이트 1이 Distributed Cloud 셀 01 및 셀 02에 연결되어 있음을 보여줍니다.
- 빨간색 연결은 사이트 2가 Distributed Cloud 셀 01 및 셀 02에 연결되어 있음을 보여줍니다.
- 녹색 연결은 사이트 1과 사이트 2의 상호 연결을 보여줍니다.
모든 스위치의 모든 사이트에서 다음 섹션에 나열된 단계를 완료해야 합니다.
19.10. OI 네트워크 최종 단계 실행
이 단계에서는 모든 구성이 생성되어 모든 기기에 적용되어야 합니다.
이제 네트워크 액세스 목록이 예상되는 특정 흐름을 허용하지만 모든 트래픽을 허용하는 기본 규칙도 있는 상태입니다.
이제 배포를 운영팀에 인계해야 합니다. Operational Suite는 고객마다 기능, 구현, 제공되는 서비스가 다릅니다. 따라서 트래픽 요구사항이 다양합니다.
운영팀에서 배포를 수락하면 ACL을 통해 네트워크 트래픽 흐름을 완전히 보호하는 것이 운영팀의 작업입니다.
이러한 작업을 수행하기 위해 운영 런북이 제공됩니다.
19.11. 객체 스토리지 업그레이드
객체 스토리지 부트스트랩 중에 노드에 지원되는 최신 부 버전의 StorageGRID가 설치되었습니다. 하지만 타겟 버전을 최신 핫픽스 패치 버전으로 업데이트해야 할 수도 있습니다.
다음 명령어를 사용하여 출시 메타데이터에서 타겟 StorageGRID 버전을 확인합니다.
kubectl get releasemetadata -o jsonpath='{.items[0].spec.infraComponents.objectStorage.storageGridOSImageVersion}'
현재 버전의 StorageGRID가 대상 버전이 아닌 경우 대상 버전으로 객체 스토리지 업그레이드를 실행합니다.
19.12. 잠재적 문제
19.12.1. 스토리지 가상 머신이 조정되지 않음
TLDR: 스토리지 가상 머신이 루트 관리자 클러스터 생성 중에 준비되지 않습니다.
문제: 루트 관리자 클러스터를 만든 후 스토리지 가상 머신 리소스가 조정되지 않고 다음과 같은 경고 이벤트가 표시됩니다.
StorageVirtualMachine Reconcile error, retrying: SVM status update failed,
error: failed to get network interface info: Get
"https://172.22.147.128/api/network/ip/interfaces?fields=%2A%2A&max_records=4096&svm.name=root-admin":
EOF
보안상의 이유로 SSL을 방지하는 스토리지 클러스터의 잘못된 구성으로 인해 이 문제가 발생할 수 있습니다.
해결 방법:
SSH를 사용하여 직렬에 연결하거나 스토리지 클러스터에 연결하고 다음을 실행합니다.
security ssl modify -server-enabled true -client-enabled true -vserver
CELL_ID-stge-clus-01
연결 후 스토리지 가상 머신 리소스가 조정될 수 있습니다.
19.12.2. 방화벽 TLS 서버 인증서 설치에서 부트스트랩이 실패함
20단계에 설명된 루트 관리자 컨트롤 플레인 부트스트랩 작업을 실행할 때 TLSServerCertification 오류가 발생할 수 있습니다.
해결 방법:
방화벽 서버 인증서 설치를 다시 시도하려면 IO 서비스 설명서 FW-R1008에 나와 있는 안내를 참고하세요. 설치가 완료되면 --start-phase 명령어와 함께 gdcloud 명령어를 사용하여 루트 관리자 부트스트랩을 계속합니다.