הוספה או הסרה של צמתים באשכול vSphere

במאמר הזה מוסבר איך להוסיף צומת אחד או יותר של Compute Engine ללא מערכת הפעלה לאשכול vSphere קיים (הרחבת אשכול) ואיך להסיר צומת אחד או יותר מאשכול (דחיסת אשכול) ב-VMware Cloud Foundation (VCF) 9.1 ב-VMware solution on Google Cloud. הרחבה או כיווץ של אשכול כשצריך להגדיל או להקטין את קיבולת האחסון של המחשוב ושל vSAN באשכול קיים בדומיין הניהול או בדומיין של עומס העבודה של VI. התהליך זהה בין אם מוסיפים או מסירים צומת אחד או כמה צמתים: מפרטים צומת אחד או יותר במשתנה הסביבה ADD_HOSTS או REMOVE_HOSTS.

סיכום הארכיטקטורה

כשמוסיפים או מסירים צמתים באשכול vSphere קיים, תהליך העבודה משתמש בארכיטקטורה הבאה:

  • הוספת צמתים: כל צומת חדש הוא מכונה פיזית (bare-metal) שאתם פורסים באותו אזור, באותה מדיניות מיקום ובאותו סוג מכונה כמו הצמתים הקיימים באשכול.z3-highmem-192-highlssd-metal לכל צומת יש ממשק רשת ראשי (nic0) ברשת המשנה לניהול ESXi של רשת ה-VPC, וממשקי רשת דינמיים עם תיוג של VLAN ל-vMotion, ל-vSAN ול-NSX Tunnel Endpoint‏ (TEP). הצומת מצטרף לקבוצות הקיימות של נקודות הקצה ברשת (NEG) באזור. לאחר מכן, אתם מפעילים את הצומת ב-SDDC Manager עם מאגר הרשת של האשכול ומוסיפים אותו לאשכול.
  • הסרת צמתים: קודם מסירים את הצומת מהאשכול ב-VCF, מה שמעביר את המכונות הווירטואליות של עומס העבודה ומפנה את נתוני ה-vSAN של המארח. לאחר מכן, אתם מוציאים משימוש את המארח מ-SDDC Manager ומסירים אותו מקבוצות ה-NEG האזוריות, לפני שאתם מוחקים את המכונה הבסיסית של Compute Engine ללא מערכת הפעלה.
  • התאמה של כתובות IP: כמו ביצירת אשכול, VCF מקצה כתובות IP של vMotion ו-vSAN ממאגר הרשת של האשכול, ו-NSX מקצה כתובות IP של TEP (vmk10) ממאגר כתובות ה-IP של NSX. אתם מתאימים את כרטיסי ה-NIC הדינמיים של Compute Engine בצמתים החדשים לכתובות ה-IP שהוקצו ל-VCF, ומשאירים את כל האימותים של VCF מופעלים.
  • אין שינויים במכשיר: הוספה או הסרה של צומתי אשכול לא דורשת רשומות חדשות של Cloud DNS, שירותים לקצה העורפי, כללי מדיניות של זמינות גבוהה (HA) או כללי העברה למכשירי ניהול.

לפני שמתחילים

לפני שמוסיפים או מסירים צמתים, צריך לוודא שהדרישות בסעיפים הבאים מתקיימות ולהגדיר את משתני הסביבה.

בדיקת הדרישות של הסביבה

מוודאים שהסביבה עומדת בדרישות הבאות:

  • הרשאות: יש לכם את התפקידים הנדרשים של ניהול זהויות והרשאות גישה (IAM) בפרויקט היעד, כולל אדמין של Compute‏ (roles/compute.admin), אדמין של DNS‏ (roles/dns.admin) וגישה לסודות של Secret Manager‏ (roles/secretmanager.secretAccessor).
  • פרטי כניסה ב-Secret Manager: אם שיניתם או החלפתם את הסיסמאות של root, ‏SDDC Manager, ‏vCenter Server או NSX Manager ב-VCF אחרי הפריסה הראשונית, Secret Manager לא מתעדכן באופן אוטומטי. לפני שמריצים את הפקודות שבמסמך הזה, צריך לעדכן את הסודות התואמים ב-Secret Manager או לספק את הסיסמאות המעודכנות ישירות, כדי שהן יתאימו לפרטי הכניסה הפעילים של VCF.
  • תקינות האשכול והדומיין: האשכול והדומיין שלו תקינים (vCenter Server,‏ vSAN,‏ NSX Manager,‏ SDDC Manager ו-VCF Operations) ואין בהם משימות שנכשלו.

  • כדי להוסיף צמתים:

    • בפרויקט יש מספיק מכסה של z3 במכונות Bare Metal באזור ובאזור (zone) היעד.
    • הצמתים החדשים משתמשים באותו סוג מכונה כמו הצמתים הקיימים באשכול (z3-highmem-192-highlssd-metal ל-vSAN Express Storage Architecture (ESA)) ומוקצים למדיניות המיקום הקיימת של האשכול (כל מדיניות מיקום שייכת לאשכול אחד בלבד).
    • לכל צומת חדש יש התקני NVMe local SSD בלי מחיצות קיימות.
    • אם בארגון שלכם נאכפת מדיניות הארגון constraints/compute.trustedImageProjects או שנעשה שימוש בגבולות גזרה לשירות של VPC Service Controls, ודאו שהפרויקט שלכם מאפשר גישה לתמונות בפרויקט smve-prod-public-images (projects/999037279871). מידע נוסף זמין במאמר ניהול הקיבולת של הצמתים.

    • רשתות מבוססות-VLAN: כדי לתמוך ברשתות מבוססות-VLAN, בפתרון של VMware צריך להגדיר את המאפיין Resolve Subnet Mask של רשתות המשנה של רשת ה-VPC לערך Broadcast primary range only with learning. פותחים כרטיס תמיכה במרכז התמיכה של מסוףGoogle Cloud ומציינים את הפרטים הבאים:

      • המוצר: Google Cloud VMware Engine
      • עדיפות: P2
      • קטגוריה: קישוריות רשת
      • ההשפעה על העסק: שאלה טכנית כללית
      • לספק פרטים נוספים: Allowlist L2 network connectivity for my project, יחד עם מזהה הפרויקט, מספר הפרויקט, והאזור והתחום של הפריסה.

      מידע נוסף על תמיכה ברשתות מבוססות-VLAN זמין במאמר אמולציה של שכבה 2: שידור ARP ולמידת MAC בהתאמה אישית.

  • כדי להסיר צמתים:

    • בצמתים שנותרו יש מספיק קיבולת מחשוב ואחסון ב-vSAN לעומסי העבודה הפעילים.
    • אחרי הסרת הצומת, באשכול נשארים לפחות שלושה צמתים (המינימום ל-vSAN עם סבילות לכשל אחד (FTT=1)) או מספר המארחים המינימלי שנדרש לפי דרישות המדיניות של האחסון הפעיל (ראו סבילות לכשלים ומספר המארחים ב-vSAN).

  • ‫Jumpbox VM: יש לכם גישה ל-Jumpbox VM שמותקנים בו ה-CLI של gcloud,‏ curl ו-jq, ויש לו קישוריות לרשת ה-VPC (לדוגמה, ברשת המשנה bm-gcp-demo).

בדיקת הפרמטרים של סביבת ההמרה לדוגמה

הפקודות במסמך הזה משתמשות בפרמטרים לדוגמה הבאים:

פרמטר קלט ערך לדוגמה תיאור
מזהה הפרויקט, האזור והתחום PROJECT_ID / us-east4 / us-east4-b אותו פרויקט, אזור ותחום כמו של אשכול היעד
מספר לקוח demo המזהה שמשמש בשמות של משאבים קיימים
אשכול היעד ‫cl02 (esxi-h7, esxi-h8, esxi-h9) אשכול קיים בדומיין הניהול או בדומיין של עומס עבודה ב-VI
מדיניות מיקום bm-cl02 מדיניות קיימת למיקום קבוצות באשכול
מאגר רשתות ו-VDS cl02-np01 / cl02-vds-01 מאגר הרשת הקיים ו-vSphere Distributed Switch‏ (VDS) של האשכול
מאגר כתובות IP של NSX TEP cl02-tep-pool מאגר כתובות IP קיים של NSX באשכול
NSX Manager nsx01.vmware.gve ‫NSX Manager של הדומיין של האשכול (או nsx05.vmware.gve לדומיין של עומס העבודה wld01 עם מכונה ייעודית של NSX)
סוג המכונה z3-highmem-192-highlssd-metal סוג מכונה זהה לזה של הצמתים הקיימים באשכול
רשת VPC ורשתות משנה (מזהה VLAN) ‫bm-demo; bm-mgmt-demo (ללא תיוג), bm-vmotion-demo (2), bm-vsan-demo (3), bm-nsx-demo (4) רשת VPC קיימת ותת-רשתות של שכבה 2
קבוצות NEG של אזור bm-mgmt-demo, bm-nsx-tep-demo קבוצות NEG קיימות של ניהול ו-NSX TEP
SDDC Manager sddcm.vmware.gve (192.168.0.3) מכשיר SDDC Manager קיים
סיסמת ESXi root esxi-root-password סוד קיים ב-Secret Manager שמכיל את הסיסמה של ESXi root

תכנון כתובות IP ושמות מארחים

בדוגמה הבאה מוסיפים שני צמתים (esxi-h10 ו-esxi-h11) לאשכול cl02, ואז מסירים אחד מהם (esxi-h11). כדי להוסיף או להסיר צומת אחד, צריך לכלול רק את הצומת הזה במערך משתני הסביבה:

מארח ESXi כתובת ה-IP של הניהול (nic0) vMotion (VLAN 2)‎ vSAN (VLAN 3) NSX TEP (VLAN 4) דומיין זמינות פעולה
esxi-h10 192.168.0.164 192.168.2.24 192.168.3.24 192.168.4.24 4 הוספה
esxi-h11 192.168.0.165 192.168.2.25 192.168.3.25 192.168.4.25 5 הוספה ואז הסרה

פיזור הצמתים של האשכול בין תחומי הזמינות במסגרת מדיניות המיקום של האשכול: מכיוון שהצמתים הקיימים (esxi-h7 עד esxi-h9) משתמשים בתחומי הזמינות 1 עד 3, הצמתים החדשים משתמשים בתחומי הזמינות 4 ו-5.

אימות המכסה האזורית

לפני שאתם מקצים צומתי Bare Metal או יוצרים אשכול, ודאו שיש לפרויקט מספיק מכסות אזוריות וגלובליות ב-Compute Engine. מוסיפים את המשאבים של כל האשכולות הקיימים באזור לערכים המצטברים הבאים, לפני שמשווים אותם למכסת הפרויקט:

מדד המכסה המשאבים הנדרשים לכל צומת Bare Metal המשאבים שנדרשים לאשכול עם 3 צמתים
compute.googleapis.com/cpus_per_vm_family של Z3 ‫192 מעבדי vCPU ‫3 × 192 = 576 מעבדי vCPU
compute.googleapis.com/local_ssd_total_storage_per_vm_family של Z3 72 TB 3 × 72 TB = 216 TB
compute.googleapis.com/hyperdisk_balanced_total_storage 128 GB ‫3 × 128GB‏ = 384GB
compute.googleapis.com/resource_policies 0 כשמוסיפים צמתים לאשכול קיים מדיניות אחת למיקום מרווח לכל אשכול
compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha 0 כשמוסיפים צמתים או אשכולות בלי מכשירים חדשים ‫1 לכל VIP של מכשיר ניהול VCF חדש או נקודת קצה (endpoint) של NSX Edge

במאמר מכסות ומגבלות מפורטות כל המכסות הנדרשות, ומוסבר איך להציג אותן או לבקש להגדיל אותן.

הגדרה של משתני סביבה

מגדירים את משתני הסביבה הבאים במעטפת של ה-jumpbox. מפרטים את הצמתים שרוצים להוסיף במשתנה הסביבה ADD_HOSTS ואת הצמתים שרוצים להסיר במשתנה הסביבה REMOVE_HOSTS (רשומה אחת או יותר בכל אחד):

export PROJECT_ID="PROJECT_ID"
export REGION="us-east4"
export ZONE="us-east4-b"
export CUSTOMER_ID="demo"
export VPC_NETWORK="bm-${CUSTOMER_ID}"
export DOMAIN="vmware.gve"
export DNS_ZONE="dns-zone-${CUSTOMER_ID}"
export REV_DNS_ZONE="rev-dns-zone-${CUSTOMER_ID}"
export MGMT_SUBNET="bm-mgmt-${CUSTOMER_ID}"
export VMOTION_SUBNET="bm-vmotion-${CUSTOMER_ID}"
export VSAN_SUBNET="bm-vsan-${CUSTOMER_ID}"
export TEP_SUBNET="bm-nsx-${CUSTOMER_ID}"
export MGMT_NEG="bm-mgmt-${CUSTOMER_ID}"
export TEP_NEG="bm-nsx-tep-${CUSTOMER_ID}"
export CLUSTER_NAME="cl02"
export PLACEMENT_POLICY="bm-${CLUSTER_NAME}"          # Existing placement policy of the cluster
export NETWORK_POOL_NAME="${CLUSTER_NAME}-np01"        # Existing network pool of the cluster
export VDS_NAME="${CLUSTER_NAME}-vds-01"               # Existing VDS of the cluster
export MACHINE_TYPE="z3-highmem-192-highlssd-metal"    # Same machine type as existing nodes
export ESXI_IMAGE_FAMILY="astra-vcf-9-1-x"
export ESXI_IMAGE_PROJECT="smve-prod-offline-depot"
export SDDC_MANAGER="sddcm.vmware.gve"                 # 192.168.0.3
export VCF_USER="admin@local"
export VCF_PASSWORD="VCF_ADMIN_PASSWORD"
export ESXI_PASSWORD_SECRET="esxi-root-password"
export NSX_MANAGER="nsx01.vmware.gve"                  # NSX Manager of the cluster's domain
export MTU=8896

# Nodes to add: name mgmt_ip vmotion_ip vsan_ip tep_ip availability_domain
ADD_HOSTS=(
  "esxi-h10 192.168.0.164 192.168.2.24 192.168.3.24 192.168.4.24 4"
  "esxi-h11 192.168.0.165 192.168.2.25 192.168.3.25 192.168.4.25 5"
)

# Nodes to remove (short hostnames)
REMOVE_HOSTS=(esxi-h11)

# Retrieve an SDDC Manager API token (re-run when the token expires)
TOKEN=$(curl -s -X POST "https://${SDDC_MANAGER}/v1/tokens" \
    -H "Content-Type: application/json" \
    -d "{\"username\":\"${VCF_USER}\",\"password\":\"${VCF_PASSWORD}\"}" | jq -r '.accessToken')

לפני שמריצים את הפקודות, מחליפים את הערכים הבאים:

  • ‫PROJECT_ID: מזהה פרויקט היעד ב- Google Cloud.
  • ‫VCF_ADMIN_PASSWORD: סיסמת האדמין של SDDC Manager.

מוודאים שאף אחת מכתובות ה-IP המתוכננות לא נמצאת בשימוש על ידי כללי העברה או מכונות קיימים:

gcloud compute forwarding-rules list --project="${PROJECT_ID}" --regions="${REGION}" \
    --format="table(name,IPAddress,subnetwork.basename())"
gcloud compute instances list --project="${PROJECT_ID}" --zones="${ZONE}" \
    --format="table(name,networkInterfaces[].networkIP.list())"

הוספת צמתים לאשכול

כדי להרחיב אשכול vSphere קיים על ידי הוספת צמתים של Bare Metal, צריך לבצע את השלבים שבקטעים הבאים.

יצירת רשומות DNS

מכיוון שהתחומים המנוהלים של Cloud DNS להעברה ולהיפוך כבר קיימים, צריך ליצור רשומות להעברה (A) ולהיפוך (PTR) רק לצמתים החדשים:

for entry in "${ADD_HOSTS[@]}"; do
  read -r HOST MGMT_IP _ <<< "${entry}"
  gcloud dns record-sets create "${HOST}.${DOMAIN}." \
      --rrdatas="${MGMT_IP}" --type=A --ttl=300 \
      --zone="${DNS_ZONE}" --project="${PROJECT_ID}"
  REV=$(echo "${MGMT_IP}" | awk -F. '{print $4"."$3"."$2"."$1".in-addr.arpa."}')
  gcloud dns record-sets create "${REV}" \
      --rrdatas="${HOST}.${DOMAIN}." --type=PTR --ttl=300 \
      --zone="${REV_DNS_ZONE}" --project="${PROJECT_ID}"
done

# Verify DNS records
gcloud dns record-sets list --zone="${DNS_ZONE}" --project="${PROJECT_ID}" \
    --filter="name~'esxi-h1[01]'"

יצירת מכונות Bare Metal

יוצרים כל צומת חדש במדיניות המיקום הקיימת של האשכול עם ה-NIC הראשי לניהול ESXi (nic0) ו-NIC דינמיים עם תיוג של VLAN ל-vMotion (VLAN 2), ל-vSAN (VLAN 3) ול-NSX TEP (VLAN 4).

for entry in "${ADD_HOSTS[@]}"; do
  read -r HOST MGMT_IP VMOTION_IP VSAN_IP TEP_IP AD <<< "${entry}"
  # Create boot disk
  gcloud compute disks create "${HOST}" \
      --image-project="${ESXI_IMAGE_PROJECT}" \
      --image-family="${ESXI_IMAGE_FAMILY}" \
      --type=hyperdisk-balanced --interface=NVME --size=128GB \
      --guest-os-features=IDPF \
      --zone="${ZONE}" --project="${PROJECT_ID}"

  # Create bare-metal ESXi host
  gcloud compute instances create "${HOST}" \
      --zone="${ZONE}" \
      --machine-type="${MACHINE_TYPE}" \
      --can-ip-forward \
      --resource-policies="${PLACEMENT_POLICY}" \
      --availability-domain="${AD}" \
      --hostname="${HOST}.${DOMAIN}" \
      --disk="name=${HOST},boot=yes,auto-delete=yes" \
      --labels=gcve-node=true \
      --tags=mm-gcve-node \
      --deletion-protection \
      --maintenance-policy=TERMINATE \
      --restart-on-failure \
      --network-performance-configs=total-egress-bandwidth-tier=TIER_1 \
      --project="${PROJECT_ID}" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${MGMT_SUBNET},no-address,private-network-ip=${MGMT_IP}" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${VMOTION_SUBNET},no-address,private-network-ip=${VMOTION_IP},vlan=2" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${VSAN_SUBNET},no-address,private-network-ip=${VSAN_IP},vlan=3" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${TEP_SUBNET},no-address,private-network-ip=${TEP_IP},vlan=4"
done

# Verify instance creation and network interfaces
gcloud compute instances list --project="${PROJECT_ID}" --zones="${ZONE}" \
    --filter="resourcePolicies~${PLACEMENT_POLICY}" \
    --format="table(name,status,networkInterfaces[].vlan.list(),networkInterfaces[].networkIP.list())"

עדכון החברות ב-NEG

כל הצמתים של אשכול באזור מסוים חייבים להיות שייכים לאותה קבוצת נקודות קצה ברשת (NEG) של רשת המשנה באזור. מוסיפים את הצמתים החדשים ל-NEG של הניהול ול-NSX TEP NEG. לא צריך לשנות את כללי המדיניות של הזמינות הגבוהה או את כללי ההעברה:

for entry in "${ADD_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  for NEG in "${MGMT_NEG}" "${TEP_NEG}"; do
    gcloud compute network-endpoint-groups update "${NEG}" \
        --zone="${ZONE}" --add-endpoint="instance=${HOST}" --project="${PROJECT_ID}"
  done
done

# Verify NEG endpoints
for NEG in "${MGMT_NEG}" "${TEP_NEG}"; do
  gcloud compute network-endpoint-groups list-network-endpoints "${NEG}" \
      --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkEndpoint.instance,networkEndpoint.ipAddress)"
done

איפוס סיסמת הבסיס של ESXi

מאפסים את הסיסמה של root בכל צומת חדש כך שתתאים לסיסמת ESXi של root שמאוחסנת ב-Secret Manager. בהמשך תשתמשו באותו סוד כדי להפעיל את הצמתים. אם שיניתם או החלפתם את הסיסמאות של ESXi root או VCF אחרי הפריסה הראשונית, עדכנו את הסוד התואם ב-Secret Manager לפני שתריצו את הפקודות האלה.

כדי לאפס את הסיסמה של root בכל צומת חדש, מריצים את הפקודות הבאות מהמכונה הווירטואלית של ה-jumpbox ומזינים את הסיסמה הראשונית של root ב-ESXi כשמוצגת בקשה לעשות זאת:

ESXI_ROOT_PASSWORD=$(gcloud secrets versions access latest \
    --secret="${ESXI_PASSWORD_SECRET}" --project="${PROJECT_ID}")

for entry in "${ADD_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  ssh -o StrictHostKeyChecking=no "root@${HOST}.${DOMAIN}" \
      "esxcli system account set -i root -p '${ESXI_ROOT_PASSWORD}' -c '${ESXI_ROOT_PASSWORD}'"
done

הוספת כתובות ה-IP החדשות למאגר הרשת ולמאגר ה-TEP

מאגר הרשת של האשכול (cl02-np01) ומאגר ה-NSX TEP‏ (cl02-tep-pool) מכילים בהתחלה רק את כתובות ה-IP של צומתי האשכול הקיימים. מוסיפים את כתובות ה-IP המדויקות של ה-NIC הדינמי של Compute Engine של הצמתים החדשים לשני המאגרים, כדי ש-VCF ו-NSX יקצו כתובות IP מהקבוצה שכבר מוגדרת ב-NIC של Compute Engine.

  1. עדכון מאגר הרשת (vMotion ו-vSAN): מוסיפים את כתובות ה-IP של vMotion ו-vSAN של הצמתים החדשים למאגר הרשת של cl02-np01 באמצעות VCF Operations או SDDC Manager API:

    פעולות VCF

    ב-VCF Operations, עוברים אל Network pool management, בוחרים את מאגר הרשתות cl02-np01, עורכים את הרשתות vMotion ו-vSAN ומוסיפים את טווחי כתובות ה-IP של הצמתים החדשים.

    SDDC Manager API

    מריצים את הפקודות הבאות כדי להוסיף למאגר הרשת טווח אחד של כתובת IP אחת לכל צומת חדש:

    POOL_ID=$(curl -s "https://${SDDC_MANAGER}/v1/network-pools" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r --arg n "${NETWORK_POOL_NAME}" '.elements[] | select(.name==$n) | .id')
NETWORKS=$(curl -s "https://${SDDC_MANAGER}/v1/network-pools/${POOL_ID}/networks" \
    -H "Authorization: Bearer ${TOKEN}")
VMOTION_NET_ID=$(echo "${NETWORKS}" | jq -r '.elements[] | select(.type=="VMOTION") | .id')
VSAN_NET_ID=$(echo "${NETWORKS}" | jq -r '.elements[] | select(.type=="VSAN") | .id')

for entry in "${ADD_HOSTS[@]}"; do
  read -r HOST MGMT_IP VMOTION_IP VSAN_IP _ <<< "${entry}"
  curl -s -X POST "https://${SDDC_MANAGER}/v1/network-pools/${POOL_ID}/networks/${VMOTION_NET_ID}/ip-pools" \
      -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
      -d "{\"start\":\"${VMOTION_IP}\",\"end\":\"${VMOTION_IP}\"}"
  curl -s -X POST "https://${SDDC_MANAGER}/v1/network-pools/${POOL_ID}/networks/${VSAN_NET_ID}/ip-pools" \
      -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
      -d "{\"start\":\"${VSAN_IP}\",\"end\":\"${VSAN_IP}\"}"
done

# Verify the network pool IP ranges
curl -s "https://${SDDC_MANAGER}/v1/network-pools/${POOL_ID}/networks" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r '.elements[] | [.type, (.ipPools | map(.start + "-" + .end) | join(","))] | @tsv'

  2. עדכון מאגר כתובות ה-IP של NSX TEP: ב-NSX Manager (המארח NSX_MANAGER), נכנסים אל Networking > IP Address Pools, עורכים את מאגר כתובות ה-IP של cl02-tep-pool ומוסיפים את כתובות ה-IP של ה-TEP של הצמתים החדשים לטווחי ה-IP של רשת המשנה (192.168.4.24–192.168.4.25 בדוגמה הזו), תוך שמירה על הגדרת שער הכניסה ל-192.168.4.1. מאמתים את הגדרת המאגר המעודכנת:

    NSX_PW="NSX_ADMIN_PASSWORD"
curl -s -u "admin:${NSX_PW}" "https://${NSX_MANAGER}/policy/api/v1/infra/ip-pools" \
    | jq -r '.results[] | [.id, .display_name] | @tsv'

TEP_POOL_ID="TEP_POOL_ID"   # ID of cl02-tep-pool from the preceding output
curl -s -u "admin:${NSX_PW}" \
    "https://${NSX_MANAGER}/policy/api/v1/infra/ip-pools/${TEP_POOL_ID}/ip-subnets" \
    | jq '.results[] | {cidr, gateway_ip, allocation_ranges}'

    לפני שמריצים את הפקודות, מחליפים את הערכים הבאים:

    • ‫NSX_ADMIN_PASSWORD: הסיסמה של NSX Manager admin (זמינה מנקודת הקצה של SDDC Manager /v1/credentials או מ-VCF Operations).
    • ‫TEP_POOL_ID: המזהה של מאגר כתובות ה-IP של cl02-tep-pool.

הפעלת הצמתים

מפעילים את הצמתים החדשים במלאי של SDDC Manager באמצעות VCF Operations או SDDC Manager API:

פעולות VCF

  1. ב-VCF Operations, עוברים אל Inventory ‏ > Hosts ‏ > Commission Hosts.
  2. בוחרים את מאגר הרשתות cl02-np01 ואת סוג האחסון vSAN ESA.
  3. מזינים את ה-FQDN של המארח החדש ואת פרטי הכניסה ל-root.
  4. מאשרים את טביעות האצבע של ה-SSL, מאמתים את המארחים ולוחצים על Commission.

SDDC Manager API

מריצים את הפקודות הבאות כדי לאמת את המארחים ולהפעיל אותם, ואז דוגמים את סטטוס המשימה עד שמוחזר הערך Successful:

ADD_FQDNS=$(for entry in "${ADD_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"; echo "${HOST}.${DOMAIN}"
done | jq -R . | jq -s .)

HOSTS_JSON=$(jq -n --argjson f "${ADD_FQDNS}" --arg p "${ESXI_ROOT_PASSWORD}" \
    --arg np "${POOL_ID}" --arg npn "${NETWORK_POOL_NAME}" \
    '$f | map({fqdn: ., username: "root", password: $p, storageType: "VSAN_ESA",
               networkPoolId: $np, networkPoolName: $npn})')

# 1. Validate hosts
curl -s -X POST "https://${SDDC_MANAGER}/v1/hosts/validations" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" -d "${HOSTS_JSON}"

# 2. Commission hosts and poll until Successful
TASK_ID=$(curl -s -X POST "https://${SDDC_MANAGER}/v1/hosts" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${HOSTS_JSON}" | jq -r '.id')
curl -s "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" -H "Authorization: Bearer ${TOKEN}" | jq -r '.status'

אם בטביעת האצבע של ה-SSL של המארח מוצג שם אישור פנימי (לא FQDN), מריצים את הפקודה esxcli network ip dns search add -d vmware.gve במארח, מריצים מחדש את הסקריפט /var/lib/vmware/osdata/init.sh, ואז מריצים את הפקודה /sbin/generate-certificates ומפעילים מחדש את השירותים rhttpproxy ו-hostd.

בדיקת ההתאמה של כתובת ה-IP לפני ההרחבה

חשוב להשאיר את כל האימותים של vSAN,‏ vMotion וקישוריות הרשת מופעלים ב-SDDC Manager. בדיקות האימות האלה עוברות רק כשכתובות ה-IP של vmk1 ו-vmk2 ש-VCF מקצה לכל צומת חדש תואמות לכתובות ה-IP של ה-NIC הדינמי של Compute Engine.

  1. מוודאים שכתובות ה-IP במאגר שלא נמצאות בשימוש תואמות לכתובות ה-IP של כרטיסי הרשת החדשים של Compute Engine: משווים בין טווחי המאגרים ברשת לבין כתובות ה-IP שמארחים קיימים כבר משתמשים בהן, וכרטיסי הרשת של Compute Engine של הצמתים החדשים. כתובות ה-IP היחידות במאגר שלא נמצאות בשימוש על ידי מארחים קיימים צריכות להיות כתובות ה-IP של הצמתים החדשים:

    # List vMotion and vSAN IP addresses already used by hosts
curl -s "https://${SDDC_MANAGER}/v1/hosts" -H "Authorization: Bearer ${TOKEN}" | jq -r '
  .elements | sort_by(.fqdn)[] | [.fqdn,
    (([.ipAddresses[]? | select(.type=="VMOTION") | .ipAddress] | first) // "-"),
    (([.ipAddresses[]? | select(.type=="VSAN")    | .ipAddress] | first) // "-")] | @tsv'

# List Compute Engine dynamic NIC IPs of the new nodes (VLAN 2 = vMotion, 3 = vSAN, 4 = TEP)
for entry in "${ADD_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  echo "== ${HOST}"
  gcloud compute instances describe "${HOST}" --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkInterfaces[].name,networkInterfaces[].vlan,networkInterfaces[].networkIP)"
done

  2. מוודאים ש-SDDC Manager לא עוקף אימותים: במכשיר SDDC Manager (בתור root), מוודאים שהקובץ application.properties לא מכיל מאפייני validation.disable.*:

    # Must return no output. If any validation.disable.* line is present, remove it
# and run: systemctl restart domainmanager
grep -n 'validation.disable' /etc/vmware/vcf/domainmanager/application.properties

הרחבת האשכול

מוסיפים את הצמתים שהוקצו לאשכול היעד באמצעות VCF Operations או SDDC Manager API:

פעולות VCF

ב-VCF Operations (או בממשק המשתמש של SDDC Manager), פותחים את הדומיין של האשכול, בוחרים את האשכול cl02, בוחרים באפשרות Actions > Add Host, בוחרים את הצמתים שהוקצו, ממפים את הממשק vmnic0 ל-uplink של uplink1 ב-VDS של האשכול ושולחים את תהליך העבודה. עוברים אל Fleet Management > Tasks כדי לעקוב אחרי המשימה ולתעד את המזהה שלה (מגדירים את המשתנה TASK_ID לערך הזה בשביל החלק הבא).

SDDC Manager API

מריצים את הפקודות הבאות כדי לאמת את מפרט ההרחבה ולהרחיב את האשכול:

CLUSTER_ID=$(curl -s "https://${SDDC_MANAGER}/v1/clusters" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r --arg c "${CLUSTER_NAME}" '.elements[] | select(.name==$c) | .id')

HOST_SPECS=$(curl -s "https://${SDDC_MANAGER}/v1/hosts?status=UNASSIGNED_USEABLE" \
    -H "Authorization: Bearer ${TOKEN}" \
    | jq --argjson f "${ADD_FQDNS}" --arg vds "${VDS_NAME}" '
        [.elements[] | select(.fqdn as $x | $f | index($x))
         | {id, hostNetworkSpec: {vmNics: [{id: "vmnic0", uplink: "uplink1", vdsName: $vds}]}}]')
echo "${HOST_SPECS}" | jq 'length'   # Must equal the number of ADD_HOSTS

EXPANSION_SPEC=$(jq -n --argjson h "${HOST_SPECS}" \
    '{clusterExpansionSpec: {hostSpecs: $h, deployWithoutLicenseKeys: true}}')

# 1. Validate (resolve any reported error before continuing)
curl -s -X POST "https://${SDDC_MANAGER}/v1/clusters/${CLUSTER_ID}/validations" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${EXPANSION_SPEC}" | jq '{executionStatus, resultStatus}'

# 2. Expand the cluster and poll the task
TASK_ID=$(curl -s -X PATCH "https://${SDDC_MANAGER}/v1/clusters/${CLUSTER_ID}" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${EXPANSION_SPEC}" | jq -r '.id')
curl -s "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" -H "Authorization: Bearer ${TOKEN}" | jq -r '.status'

כשמרחיבים אשכול, SDDC Manager מקצה כתובות IP של vMotion ו-vSAN ממאגר הרשת בלי לשמור על סדר המארחים. אם SDDC Manager מקצה לצומת חדש כתובת IP שונה מה-NIC הדינמי שלו ב-Compute Engine, המשימה מושהית בשלב האימות של הקישוריות ל-vSAN ול-vMotion. משאירים את המשימה במצב "נכשלה", מבצעים את השלבים שמפורטים בקטע התאמת כרטיסי ה-NIC הדינמיים של vMotion ו-vSAN ומנסים שוב לבצע את אותה משימה. אל תתחילו בקשת הרחבה חדשה לצמתים האלה: אחרי הרחבה שנכשלה, הצמתים כבר לא במצב unassigned, ומנהל SDDC דוחה בקשת הרחבה חדשה.

התאמת כרטיסי ה-NIC הדינמיים של vMotion ו-vSAN

אם משימת הרחבת האשכול מושהית בשלב האימות של הקישוריות ל-vSAN ול-vMotion, צריך לבצע את השלבים שבקטע הזה. אם המשימה עוברת את השלב הזה, מריצים רק את שלב 1 כדי לאשר את ההתאמה, ואז ממשיכים אל התאמת כרטיסי ה-NIC הדינמיים של NSX TEP.

  1. קוראים את כתובות ה-IP שהוקצו ל-VCF ומשווים אותן לכרטיסי ה-NIC של Compute Engine: מריצים את שתי הפקודות משלב 1 של בדיקת ההתאמה של כתובות ה-IP לפני ההרחבה. רק הצמתים החדשים נכללים בהיקף.

  2. קודם מוחקים את כל כרטיסי ה-NIC הדינמיים שלא תואמים, ואז מוסיפים אותם בחזרה: מוחקים כל כרטיס NIC דינמי שלא תואם (הממשק nic0.2 ל-vMotion והממשק nic0.3 ל-vSAN) בכל צומת חדש לפני שמוסיפים מחדש ממשק כלשהו. אחרת, כתובות ה-IP שהוחלפו נכשלות עם השגיאה IP_IN_USE:

    # Example: VCF swapped the IP addresses of esxi-h10 and esxi-h11
HOST="esxi-h10"
VCF_VMOTION_IP="192.168.2.25"
VCF_VSAN_IP="192.168.3.25"

# 2a. Delete mismatched NICs (run on all mismatched nodes before running 2b)
gcloud compute instances network-interfaces delete "${HOST}" \
    --network-interface=nic0.2 --zone="${ZONE}" --project="${PROJECT_ID}" --quiet
gcloud compute instances network-interfaces delete "${HOST}" \
    --network-interface=nic0.3 --zone="${ZONE}" --project="${PROJECT_ID}" --quiet

# 2b. Add the dynamic NICs back with the VCF-allocated IP addresses
gcloud compute instances network-interfaces add "${HOST}" \
    --parent-nic-name=nic0 --vlan=2 \
    --network="${VPC_NETWORK}" --subnetwork="${VMOTION_SUBNET}" \
    --private-network-ip="${VCF_VMOTION_IP}" --no-address \
    --zone="${ZONE}" --project="${PROJECT_ID}"
gcloud compute instances network-interfaces add "${HOST}" \
    --parent-nic-name=nic0 --vlan=3 \
    --network="${VPC_NETWORK}" --subnetwork="${VSAN_SUBNET}" \
    --private-network-ip="${VCF_VSAN_IP}" --no-address \
    --zone="${ZONE}" --project="${PROJECT_ID}"

  3. מנסים שוב לבצע את המשימה שנכשלה: ב-VCF Operations, עוברים אל Fleet Management.

    Tasks כדי לנסות שוב את משימת ההרחבה, או להריץ את פקודת ה-API הבאה של SDDC Manager:

    curl -s -X PATCH "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d '{"status": "RETRY"}'

    אם המשימה נכשלת שוב, חוזרים על שלבים 1 ו-2 לפני שמנסים שוב.

התאמת כרטיסי ה-NIC הדינמיים של NSX TEP

אחרי ש-NSX מגדיר את הצמתים החדשים כצומתי תעבורה, מאמתים ומתאימים את ה-NIC הדינמיים של VLAN 4 NSX TEP (vmk10) בצמתים החדשים.

  1. אחזור כתובות ה-IP של TEP שהוקצו ל-NSX: שולחים שאילתה ל-NSX Manager (או מריצים את הפקודה esxcli network ip interface ipv4 get -i vmk10 בכל מארח ESXi):

    # Map transport node ID to hostname
curl -s -u "admin:${NSX_PW}" "https://${NSX_MANAGER}/api/v1/transport-nodes" \
    | jq -r '.results[] | [.id, .display_name] | @tsv'

# Map transport node ID to TEP device and IP address
curl -s -u "admin:${NSX_PW}" "https://${NSX_MANAGER}/api/v1/transport-nodes/state" \
    | jq -r '.results[] | [.transport_node_id, .state,
        ([.host_switch_states[]?.endpoints[]? | .device_name + "=" + .ip] | join(","))] | @tsv'

  2. יצירה מחדש של כרטיסי ה-NIC של ה-TEP שלא תואמים: משווים בין כתובות ה-IP של vmk10 שהוקצו ל-NSX לבין כרטיס ה-NIC של ה-TEP (VLAN 4) ב-Compute Engine של כל צומת חדש. רק הצמתים החדשים נכללים בהיקף. אל תשנו את כרטיסי ה-NIC של ה-TEP בצמתים הקיימים. בכל הצמתים החדשים שלא תואמים, קודם מנתקים כל צומת מה-TEP NEG ומוחקים את הממשק nic0.4 בכל הצמתים שלא תואמים. לאחר מכן מוסיפים מחדש את הממשק nic0.4 ומחברים מחדש את הצמתים ל-TEP NEG:

    # Example: Compute Engine has 192.168.4.24 on esxi-h10, but NSX assigned 192.168.4.25
HOST="esxi-h10"
CURRENT_TEP_IP="192.168.4.24"
NSX_TEP_IP="192.168.4.25"

# 2a. Detach the node from the TEP NEG
gcloud compute network-endpoint-groups update "${TEP_NEG}" \
    --zone="${ZONE}" --project="${PROJECT_ID}" \
    --remove-endpoint="instance=${HOST},ip=${CURRENT_TEP_IP}"

# 2b. Delete the mismatched TEP NIC on all mismatched nodes first
gcloud compute instances network-interfaces delete "${HOST}" \
    --network-interface=nic0.4 --zone="${ZONE}" --project="${PROJECT_ID}" --quiet

# 2c. Re-add nic0.4 with the NSX-allocated IP address
gcloud compute instances network-interfaces add "${HOST}" \
    --parent-nic-name=nic0 --vlan=4 \
    --network="${VPC_NETWORK}" --subnetwork="${TEP_SUBNET}" \
    --private-network-ip="${NSX_TEP_IP}" --no-address \
    --zone="${ZONE}" --project="${PROJECT_ID}"

# 2d. Re-attach the node to the TEP NEG
gcloud compute network-endpoint-groups update "${TEP_NEG}" \
    --zone="${ZONE}" --project="${PROJECT_ID}" \
    --add-endpoint="instance=${HOST}"

אימות הרחבת האשכול

אחרי שמשימת הרחבת האשכול מסתיימת, מוודאים את הדברים הבאים:

  • ‫vCenter Server: הצמתים החדשים מחוברים ותקינים באשכול cl02, ואין התראות רשת.
  • ‫vSAN: באשכול cl02, עוברים אל Monitor ‏ > vSAN ‏ > Skyline Health ומוודאים שכל בדיקות התקינות עברו בהצלחה, ושהקיבולת של מאגר הנתונים כוללת את הצמתים החדשים.
  • ‫NSX Manager: עוברים אל System > Fabric > Hosts ומוודאים שבכל צומת חדש מופיעים הסטטוסים Success ו-Up, ושהמנהרות של שכבת-העל פועלות.
  • ‫VCF Operations: הצמתים החדשים מוקצים לאשכול cl02 ואין משימות שנכשלו ברשימת המשימות.

ממעטפת מארח ESXi (לדוגמה, esxi-h10), מאמתים את הקישוריות של מסגרת ג'מבו (MTU של 8896 פחות כותרת IP/ICMP של 28 בייטים = 8868 בייטים):

esxcli network ip interface ipv4 get                        # Verify vmk0, vmk1, vmk2, and vmk10 IPs
vmkping -S vmotion -I vmk1 -d -s 8868 192.168.2.21          # vMotion (netstack might be default)
vmkping -I vmk2 -d -s 8868 192.168.3.21                     # vSAN
vmkping ++netstack=vxlan -I vmk10 -d -s 8868 192.168.4.21   # NSX TEP

מספר המארחים ומספר הכשלים ש-vSAN יכול לסבול

אתם יכולים להיעזר בטבלה הבאה כדי לקבוע כמה צמתים נדרשים לאשכול כשמוסיפים צמתים, או כמה צמתים צריך לשמור כשמסירים צמתים:

כשלים שניתן לסבול סכימת מיקום הנתונים מספר המארחים המינימלי
FTT=1 ‫RAID-1 (שיקוף) או RAID-5 (קידוד מחיקה) ‫3 (מומלץ 4 או יותר כדי לבנות מחדש אחרי כשל במארח או במהלך תחזוקה)
FTT=2 ‫RAID-1 (שיקוף) 5
FTT=2 ‫RAID-6 (קידוד מחיקה) 6

הסרת צמתים מאשכול

השלמת הבדיקות לפני ההסרה

לפני שמסירים צמתים מאשכול, צריך לוודא את הדברים הבאים:

  • מספר המארחים: אחרי הסרת הצומת, באשכול נשארים לפחות שלושה צמתים, ולפחות מספר המארחים המינימלי שמופיע בקטע מספר המארחים ו-vSAN failures to tolerate, שנדרש לפי דרישות מדיניות האחסון הפעילות.
  • קיבולת: ב-vCenter Server, באשכול cl02, עוברים אל Monitor‏ > vSAN‏ > Data Migration Pre-check לכל צומת שרוצים להסיר (עם האפשרות Full data migration) ומוודאים שלצמתים הנותרים יש מספיק קיבולת vSAN וקיבולת מחשוב.
  • תקינות: בדיקת התקינות של vSAN Skyline עוברת ללא שגיאות, ואין משימות שנכשלו ב-VCF Operations או ב-SDDC Manager.

  • מנהיגי מדיניות HA: ודאו שאף שירות לקצה העורפי לא משתמש בצומת שאתם מסירים כמנהיג מדיניות ה-HA שלו. אם שירות לקצה העורפי משתמש באחד מהצמתים האלה בתור ה-leader, צריך לעדכן את ה-leader לצומת שנותר (המארח שמריץ את המכונה הווירטואלית של המכשיר אחרי ההעברה):

    gcloud compute backend-services list --regions="${REGION}" --project="${PROJECT_ID}" \
    --format="table(name,haPolicy.leader.networkEndpoint.instance)"

# Run only if a node being removed is an HA policy leader (example: move rbs-vc02-demo to esxi-h0)
NEG_LINK=$(gcloud compute network-endpoint-groups describe "${MGMT_NEG}" \
    --zone="${ZONE}" --project="${PROJECT_ID}" --format="value(selfLink)")
gcloud compute backend-services update "rbs-vc02-${CUSTOMER_ID}" \
    --ha-policy-leader-backend-group="${NEG_LINK}" --ha-policy-leader-instance=esxi-h0 \
    --region="${REGION}" --project="${PROJECT_ID}"

הסרת הצמתים מהאשכול

מסירים את צומתי היעד מהאשכול ב-VCF. ‫VCF מעביר כל צומת למצב תחזוקה, מעביר את המכונות הווירטואליות שלו ומפנה את נתוני ה-vSAN שלו. אפשר להסיר את הצמתים באמצעות VCF Operations או SDDC Manager API:

פעולות VCF

ב-VCF Operations (או בממשק המשתמש של SDDC Manager), פותחים את הדומיין של האשכול, בוחרים את האשכול cl02, בוחרים באפשרות Actions‏ > Remove Host, בוחרים את הצמתים שרוצים להסיר ומאשרים.

SDDC Manager API

מריצים את הפקודות הבאות כדי לאמת את מפרט הדחיסה ולהסיר את המארחים מהאשכול:

CLUSTER_ID=$(curl -s "https://${SDDC_MANAGER}/v1/clusters" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r --arg c "${CLUSTER_NAME}" '.elements[] | select(.name==$c) | .id')

REMOVE_FQDNS=$(for HOST in "${REMOVE_HOSTS[@]}"; do echo "${HOST}.${DOMAIN}"; done | jq -R . | jq -s .)

COMPACTION_SPEC=$(curl -s "https://${SDDC_MANAGER}/v1/hosts" -H "Authorization: Bearer ${TOKEN}" \
    | jq --argjson f "${REMOVE_FQDNS}" '
        {clusterCompactionSpec: {hosts: [.elements[] | select(.fqdn as $x | $f | index($x)) | {id}]}}')
echo "${COMPACTION_SPEC}" | jq '.clusterCompactionSpec.hosts | length'   # Must equal the number of REMOVE_HOSTS

# 1. Validate the compaction specification
curl -s -X POST "https://${SDDC_MANAGER}/v1/clusters/${CLUSTER_ID}/validations" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${COMPACTION_SPEC}" | jq '{executionStatus, resultStatus}'

# 2. Remove the hosts and poll the task until Successful
TASK_ID=$(curl -s -X PATCH "https://${SDDC_MANAGER}/v1/clusters/${CLUSTER_ID}" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${COMPACTION_SPEC}" | jq -r '.id')
curl -s "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" -H "Authorization: Bearer ${TOKEN}" | jq -r '.status'

הוצאת הצמתים משימוש

אחרי שמסירים את הצמתים מהאשכול, צריך להוציא אותם משימוש במלאי של SDDC Manager באמצעות VCF Operations או SDDC Manager API:

פעולות VCF

ב-VCF Operations, נכנסים ל-Inventory > Hosts, בוחרים את הצמתים שלא הוקצו ולוחצים על Decommission (למידע נוסף, קראו את המאמר Decommission hosts במסמכי התיעוד של VMware Cloud Foundation).

SDDC Manager API

מריצים את הפקודות הבאות כדי לשלוח בקשה להוצאה משימוש ולדגום את המשימה עד שהיא מחזירה את הערך Successful:

DECOMMISSION_SPEC=$(echo "${REMOVE_FQDNS}" | jq 'map({fqdn: .})')
TASK_ID=$(curl -s -X DELETE "https://${SDDC_MANAGER}/v1/hosts?skipFailedHosts=false" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${DECOMMISSION_SPEC}" | jq -r '.id')
curl -s "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" -H "Authorization: Bearer ${TOKEN}" | jq -r '.status'

# Verify that the nodes are no longer listed in the inventory
curl -s "https://${SDDC_MANAGER}/v1/hosts" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r '.elements[] | [.fqdn, .status] | @tsv'

מסירים את הצמתים מה-NEG.

מסירים את הצמתים שהוצאו משימוש מה-NEG לניהול ומה-NSX TEP NEG:

for HOST in "${REMOVE_HOSTS[@]}"; do
  for NEG in "${MGMT_NEG}" "${TEP_NEG}"; do
    gcloud compute network-endpoint-groups update "${NEG}" \
        --zone="${ZONE}" --remove-endpoint="instance=${HOST}" --project="${PROJECT_ID}"
  done
done

# Verify NEG endpoints
for NEG in "${MGMT_NEG}" "${TEP_NEG}"; do
  gcloud compute network-endpoint-groups list-network-endpoints "${NEG}" \
      --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkEndpoint.instance,networkEndpoint.ipAddress)"
done

אם ה-CLI של gcloud דוחה את ההסרה מה-TEP NEG בלי כתובת IP מפורשת, צריך לכלול את כתובת ה-IP של נקודת הקצה (כפי שמוצגת בפקודת האימות) בדגל --remove-endpoint: --remove-endpoint="instance=HOST,ip=TEP_IP".

מחיקת המכונות ללא מערכת הפעלה (bare-metal)

מבטלים את ההגנה מפני מחיקה בכל מארח שהוצא משימוש, ומוחקים את המכונה ללא מערכת הפעלה של Compute Engine (המערכת מוחקת באופן אוטומטי את דיסק האתחול יחד עם המכונה):

for HOST in "${REMOVE_HOSTS[@]}"; do
  # Clear deletion protection, and then delete the instance and its boot disk
  gcloud compute instances update "${HOST}" --no-deletion-protection \
      --zone="${ZONE}" --project="${PROJECT_ID}"
  gcloud compute instances delete "${HOST}" \
      --zone="${ZONE}" --project="${PROJECT_ID}" --quiet
done

# Verify remaining instances in the placement policy
gcloud compute instances list --project="${PROJECT_ID}" --zones="${ZONE}" \
    --filter="resourcePolicies~${PLACEMENT_POLICY}" --format="table(name,status)"

ניקוי רשומות DNS ומאגרי IP

מוחקים את רשומות ה-DNS להעברה (A) וההפוכות (PTR) ב-Cloud DNS של הצמתים שהוסרו:

for HOST in "${REMOVE_HOSTS[@]}"; do
  MGMT_IP=$(gcloud dns record-sets describe "${HOST}.${DOMAIN}." --type=A \
      --zone="${DNS_ZONE}" --project="${PROJECT_ID}" --format="value(rrdatas[0])")
  REV=$(echo "${MGMT_IP}" | awk -F. '{print $4"."$3"."$2"."$1".in-addr.arpa."}')
  gcloud dns record-sets delete "${REV}" --type=PTR --zone="${REV_DNS_ZONE}" --project="${PROJECT_ID}"
  gcloud dns record-sets delete "${HOST}.${DOMAIN}." --type=A --zone="${DNS_ZONE}" --project="${PROJECT_ID}"
done

כתובות ה-IP של vMotion,‏ vSAN ו-TEP של הצמתים שהוסרו הופכות שוב לפנויות במאגר הרשת ובמאגר NSX TEP. אתם יכולים לשמור את כתובות ה-IP האלה לצומת עתידי (על ידי הקצאת אותן כתובות IP של Compute Engine NIC לצומת העתידי) או להסיר אותן מהמאגרים כדי ש-VCF ו-NSX לא יקצו אותן לצומת עתידי שכרטיסי ה-NIC שלו ב-Compute Engine משתמשים בכתובות IP שונות.

אימות הסרת הצומת

אחרי שמסיימים את תהליך העבודה להסרת הצומת, צריך לוודא את הדברים הבאים:

  • ‫vCenter Server: באשכול cl02 מוצגים רק הצמתים שנותרו, כולם מחוברים ותקינים, וב-vSphere HA וב-DRS לא מדווחות שגיאות.
  • ‫vSAN: בדיקות Skyline Health עוברות וכל האובייקטים הווירטואליים תואמים (לאשכול cl02, עוברים אל Monitor > vSAN > Virtual Objects).
  • ‫NSX Manager: הצמתים שהוסרו לא מופיעים יותר כצומתי תעבורה, והצמתים שנותרו מופיעים כ-Up.
  • ‫VCF Operations ו-SDDC Manager: הצמתים שהוסרו לא נמצאים יותר במלאי המארחים, ואין משימות שנכשלו.
  • ‫Google Cloud: המכונות ללא מערכת הפעלה, דיסקי האתחול, נקודות הקצה של ה-NEG ורשומות ה-DNS של הצמתים שהוסרו נמחקים.

פתרון בעיות בהרחבת אשכולות ובהסרת צמתים

בטבלה הבאה מפורטות בעיות נפוצות, הסיבות להן והפתרונות שלהן כשמוסיפים או מסירים צמתים באשכול vSphere:

שגיאה מטרה רזולוציה
הרחבת האשכול נכשלת בבדיקת הקישוריות של vSAN ו-vMotion; צמתים חדשים מדווחים על מצב לא תקין כשמרחיבים אשכול, SDDC Manager מקצה כתובות IP של vmk1 ו-vmk2 ממאגר הרשת בלי לשמור על סדר המארחים. להשאיר את האימותים מופעלים. מוסיפים למאגר הרשת רק את כתובות ה-IP של הצמתים החדשים. אם המשימה מושהית בבדיקת הקישוריות, מתאימים את ה-NIC הדינמיים ומנסים שוב את אותה משימה.
סטטוס המארח של NSX הוא Degraded או שהמנהרות מושבתות בצמתים החדשים ‫NSX Manager מקצה כתובות IP של TEP (vmk10) ממאגר ה-IP באופן אקראי, כך שהן לא בהכרח תואמות ל-TEP NIC של Compute Engine. מתאימים את כרטיסי ה-NIC הדינמיים של NSX TEP, כמו שמתואר בקטע התאמת כרטיסי ה-NIC הדינמיים של NSX TEP.
‫NSX לא יכול להכין את הצמתים החדשים במאגר כתובות ה-IP של NSX TEP באשכול אין כתובות IP פנויות. מוסיפים את כתובות ה-IP של ה-TEP של הצמתים החדשים למאגר כתובות ה-IP של ה-TEP, ואז מנסים שוב לבצע את המשימה.
‫SDDC Manager דוחה בקשת הרחבה חדשה לאותם צמתים אם משימת ההרחבה נכשלת, הצמתים נשארים מחוץ למצב UNASSIGNED_USEABLE. מנסים שוב את המשימה שנכשלה (PATCH /v1/tasks/TASK_ID עם {"status": "RETRY"}) במקום לשלוח בקשת הרחבה חדשה.
הפעלת צומת נכשלת כי הצומת כבר הופעל אי אפשר להזמין מארח פעמיים. ממשיכים בהרחבת האשכול, או משביתים קודם את הצומת אם צריך להפעיל אותו מחדש (לדוגמה, עם מאגר רשת אחר).
שגיאה מסוג IP_IN_USE כשמוסיפים מחדש NIC דינמי שני צמתים החליפו כתובות IP, או שכתובת IP מתוכננת חופפת לצומת אחר. לפני שמוסיפים מחדש ממשק, צריך למחוק את כל ה-NIC הדינמיים שלא תואמים בכל הצמתים החדשים, ולאמת את תוכנית כתובות ה-IP.
אימות הסרת הצומת נכשל הסרת הצמתים מקטינה את האשכול לפחות מארחים מהגודל המינימלי שלו, או שלצמתים שנותרו אין מספיק קיבולת. צריך להסיר פחות צמתים או להוסיף קודם קיבולת, ולא להשתמש במאפיין "force": true.
‫gcloud CLI מסרב למחוק את המכונה ללא מערכת הפעלה ההגנה מפני מחיקה מופעלת במכונה. מריצים את הפקודה gcloud compute instances update HOST --no-deletion-protection לפני שמוחקים את המכונה.
תחומי תקלות שגויים ב-vSAN אחרי הוספת צמתים יצרתם צמתים חדשים במדיניות מיקום אחרת, או ששני אשכולות משתפים מדיניות מיקום. יוצרים צמתים חדשים במדיניות המיקום של האשכול ומפיצים אותם בין דומיינים של זמינות.
שגיאות vSAN, זמן קצוב לתפוגה של vMotion או פרגמנטציה של שכבת NSX ה-MTU שהוגדר גדול מה-MTU של רשת ה-VPC (8896 בייטים). צמתים חדשים יורשים את ה-VDS והמאגרים של האשכול. צריך להשאיר את ה-MTU מוגדר ל-8896 בייטים בכל הרכיבים.
טביעת האצבע או האישור של ה-SSL של המארח מציגים שם פנימי דומיין החיפוש של ה-DNS לא מוגדר במארח. מריצים את הפקודה esxcli network ip dns search add -d vmware.gve, מריצים מחדש את הסקריפט /var/lib/vmware/osdata/init.sh, ואז מריצים את הפקודה /sbin/generate-certificates ומפעילים מחדש את השירותים rhttpproxy ו-hostd.
המארחים לא יכולים לשלוח פינג לשער של רשת המשנה (.1) Google Cloud לא מגיב לבקשות ICMP echo בכתובות ה-IP של השער של רשת המשנה. התנהגות צפויה; אפשר להתעלם מאזהרות הפינג של השער.

המאמרים הבאים