이 페이지는 Cloud Translation API를 통해 번역되었습니다.

12. 네트워크 부트스트랩

예상 소요 시간: 240분

작동 가능한 구성요소 소유자: PNET

기술 프로필: 배포 엔지니어

이 페이지에는 네트워크를 부트스트랩하고 스위치를 구성하는 단계가 나열되어 있습니다.

네트워크 시스템에는 다음 구성요소가 포함됩니다.

관리 네트워크: 다음 두 가지 유형의 스위치가 포함된 대역 외 관리 네트워크입니다.
- 관리 스위치
- 관리 집계 스위치
데이터 영역 네트워크: 사용자 트래픽을 전달하고 다음 세 가지 유형의 스위치를 포함하는 네트워크입니다.
- TOR (top-of-rack) 스위치
- 집계 스위치
- 보더 리프 스위치

스위치의 현재 펌웨어가 예상 버전이 아닌 경우 네트워크 부트스트랩은 스위치를 Google Distributed Cloud (GDC) 오프라인 버전의 예상 스위치 OS 버전으로 가져오려고 시도합니다.

12.1. 시작하기 전에

스위치는 기본 설정으로 제공될 수 있습니다. 시작하기 전에 모든 스위치를 재설정하여 기존 구성을 삭제하세요. 이렇게 하려면 직렬 콘솔을 사용하여 연결하고 다음 명령어를 실행합니다.

write erase

기존 스위치 구성을 삭제한 후 스위치를 다시 로드합니다.

reload in 5

12.2. 네트워크 설치

네트워크 설치를 위해 다음 단계를 따르세요.

모든 스위치의 전원을 켭니다.
부트스트랩 머신에서 sudo 루트 액세스 권한으로 네트워크 부트스트랩 프로그램을 시작합니다.
```
gdcloud system network install --config PATH_TO_CELLCFG --upgrade-switch-os
```
PATH_TO_CELLCFG을 cellcfg 파일의 경로로 바꿉니다.

참고: --config-file-only 플래그를 추가하여 네트워크 구성 파일만 생성할 수 있습니다. 플래그 없이 네트워크를 이미 부트스트랩한 후에는 실행하지 마세요
1. 이 명령어가 실패하고 다음 오류 메시지가 표시되면
```
root@bootstrapper:~/hams/gdc/output/cellcfg# gdcloud system network install --config /root/hams/gdc/output/cellcfg --upgrade-switch-os
Error: failed to initialize KIND: could not determine harbor address (no match between local and docker hostnames): could not find a match
```
2. init 명령어를 다시 실행하여 이 오류를 해결합니다.
```
gdcloud system network init --config PATH_TO_CELLCFG
```
스위치를 켠 상태로 유지합니다. 스위치는 부트스트랩 머신에서 자동으로 원격으로 설치하기 위해 PowerOn Auto Provisioning (POAP) 부팅 시퀀스를 거칩니다.
부트스트랩 프로그램 로그를 모니터링하여 스위치가 다음 순서로 작동하는지 확인합니다.
1. 관리 스위치 1
2. 기타 관리 스위치 및 관리 집계 스위치
3. 데이터 네트워크 스위치
부트스트랩 로그를 계속 모니터링합니다. 위 단계를 완료하면 스위치가 연결됩니다. 부트스트랩 프로그램은 API를 통해 관리 스위치와 데이터 스위치에 추가 구성을 설치합니다.
부트스트랩 로그에 Successfully bootstrapped all switches. 메시지가 표시될 때까지 기다립니다.

12.3. 부트스트랩 세부정보

다음과 같이 POAP 부팅 시퀀스를 사용하여 네트워크의 모든 스위치를 부트스트랩합니다.

부트스트랩 머신을 관리 스위치에 연결합니다.
관리 집계 스위치를 관리 스위치에 연결합니다.
나머지 스위치를 동일한 랙에 연결합니다.
관리 집계 스위치를 다른 랙에 연결합니다.
다른 모든 스위치를 연결합니다.

부트스트랩 머신은 ./cellcfg 경로에 있는 스위치의 YAML 파일로 스위치 구성을 생성합니다. 모든 스위치는 PowerOn Auto Provisioning (POAP) 부팅 시퀀스를 사용하여 구성을 수신합니다. 하드웨어 3.0에서 네트워크 스위치는 최종 구성이 포함된 POAP 파일을 수신합니다. 스위치가 POAP를 완료하면 스위치가 자동으로 다시 시작됩니다.

다시 시작한 후 스위치는 ./cellcfg 경로에 있는 스위치의 YAML 파일과 정렬되어야 합니다. 부트스트랩 머신은 모든 스위치에 요청을 전송하여 스위치 연결 및 구성이 성공적으로 이루어지도록 합니다.

12.4. 부트스트랩 후 경로 구성

네트워크 부트스트랩 프로세스 후 부트스트래퍼의 경로를 구성하여 예정된 부트스트랩 작업을 준비합니다.

12.4.1. 데이터 플레인 게이트웨이 찾기

데이터 영역 게이트웨이는 데이터 영역 네트워크의 게이트웨이 IP 주소입니다. 데이터 영역 네트워크의 다른 서비스와 통신하도록 게이트웨이 IP 주소를 설정합니다.

데이터 플레인 게이트웨이 IP 주소를 찾으려면 다음 단계를 따르세요.

cellcfg 폴더에서 kub-ipam.yaml 파일로 이동합니다.

이름이 control-plane-subnet인 SubnetClaim 리소스를 찾습니다.

yq eval -r '
select(.kind == "SubnetClaim" and .metadata.name == "control-plane-subnet") |
.spec.ipv4Spec.staticReservedIpRanges[] |
select(.type == "GatewayReservation") |
.ipRange.startIPAddress
' PATH_TO_KUB_IPAM_FILE

PATH_TO_KUB_IPAM_FILE을 cellcfg/kub-ipam.yaml 파일의 경로로 바꿉니다.

spec.ipv4Spec 섹션에서 게이트웨이 IP 주소를 찾아 type: GatewayReservation로 나열합니다. 예를 들어 데이터 플레인 인터페이스의 게이트웨이 IP 주소는 172.19.0.1입니다.

# Source: kub-ipam-assets/templates/subnet_claims.yaml
apiVersion: system.private.gdc.goog/v1alpha1
kind: SubnetClaim
metadata:
  name: control-plane-subnet
  namespace: root
  labels:
    subnetclaims.system.private.gdc.goog/usage: "server"
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  category: ExternalOverlayNetwork
  overlayNetwork: External
  cidrClaimName: control-plane-cidr
  ipv4Spec:
    staticReservedIpRanges:
      - ipRange:
          size: 1
          startIPAddress: 172.19.0.1
        type: GatewayReservation

12.4.2. 부트스트래퍼에서 경로 스크립트 만들기

경로를 만드는 스크립트를 만듭니다.

bash << 'EOF'
#!/bin/bash

SCRIPT_PATH="/usr/local/sbin/add-routes.sh"
SERVICE_PATH="/usr/lib/systemd/system/add-routes.service"
MGMT_GATEWAY=MGMT_GATEWAY
MGMT_CIDR=MGMT_CIDR
MGMT_INTERFACE=MGMT_INTERFACE
BOND_GATEWAY=DATA_GATEWAY

rm -rf "$SCRIPT_PATH" 2>/dev/null
touch "$SCRIPT_PATH"
rm -rf "$SERVICE_PATH" 2>/dev/null
touch "$SERVICE_PATH"

echo -e '#!/bin/bash\n' > "$SCRIPT_PATH"
echo "ip route del $MGMT_CIDR via $MGMT_GATEWAY dev $MGMT_INTERFACE proto static" >> "$SCRIPT_PATH"
echo "ip route add $MGMT_CIDR via $MGMT_GATEWAY dev $MGMT_INTERFACE proto static" >> "$SCRIPT_PATH"
echo "ip route del default via $BOND_GATEWAY dev bond0 proto static" >> "$SCRIPT_PATH"
echo "ip route add default via $BOND_GATEWAY dev bond0 proto static" >> "$SCRIPT_PATH"

chmod +x "$SCRIPT_PATH"

echo -e "[Unit]\nDescription=Add Routes Service\nAfter=network.target\n\n[Service]\nType=simple\nExecStart=/usr/local/sbin/add-routes.sh\n\n[Install]\nWantedBy=default.target" > "$SERVICE_PATH"

systemctl daemon-reload
systemctl enable add-routes.service
systemctl restart add-routes.service

echo -e "\n ### add-routes.sh script file path ###"
ls -l $SCRIPT_PATH
echo -e "\n ### add-routes.service file path ###"
ls -l $SERVICE_PATH
echo -e "\n ### add-routes.service status ###"
systemctl status add-routes.service
echo -e "\n ### Show if add-routes.service is enabled at boot ###"
systemctl is-enabled add-routes.service
echo -e "\n ### Show the just added route to ens15f0 ###"
ip route show | grep ens15f0
echo -e "\n ### Show the just added default route  ###"
ip route show | grep default
EOF

다음을 바꿉니다.

MGMT_GATEWAY: 관리 IP, CIDR, 게이트웨이 주소 찾기 섹션의 게이트웨이 주소입니다.
MGMT_CIDR: 관리 IP, CIDR, 게이트웨이 주소 찾기 섹션의 관리 CIDR
MGMT_INTERFACE: 관리 인터페이스 이름의 예는 ens15f0입니다. cellcfg/serv-core.yaml의 MAC 주소를 사용하여 관리 네트워크에 사용되는 인터페이스를 식별할 수 있습니다.
DATA_GATEWAY: 데이터 플레인 게이트웨이 찾기 섹션의 게이트웨이 IP 주소입니다.

이 스니펫은 다음과 같이 systemd 서비스와 스크립트를 만듭니다.

SCRIPT_PATH="/usr/local/sbin/add-routes.sh
SERVICE_PATH="/usr/lib/systemd/system/add-routes.service

systemd 서비스는 시스템을 재부팅한 후 경로를 유지해야 합니다. 추가되는 경로는 다음과 같습니다.

bond0 인터페이스를 통한 데이터 네트워크의 기본 경로입니다.
관리 인터페이스를 통한 관리 네트워크 경로입니다.

12.5. 다중 영역 연결 설정

GDC 인스턴스가 기존 다중 영역 유니버스에 참여하는 경우 각 영역에 대해 다중 영역 상호 연결 구성의 단계를 따라 기존 영역과 현재 배포 영역 간에 네트워크 연결을 설정합니다.

12.6. 문제 해결

네트워크 부트스트랩 문제를 해결하려면 네트워크 부트스트랩 문제 해결을 참고하세요.

12.7. 잠재적 문제

버전이 9.3.10 미만으로 미리 로드된 네트워크 스위치는 부트스트랩에 실패할 수 있습니다.

자세한 내용은 알려진 문제를 참고하세요.