הוספת אשכול vSphere לדומיין

במאמר הזה מוסבר איך להוסיף אשכול vSphere לדומיין קיים של VMware Cloud Foundation (VCF) 9.1 ב-VMware solution on Google Cloud באמצעות מכונות Bare Metal של Compute Engine. כדאי להוסיף אשכול כשצריך להרחיב את קיבולת האחסון של vSAN ושל המחשוב מעבר לאשכול יחיד, לבודד עומסי עבודה או להחיל תמונות נפרדות של vSphere Lifecycle Manager ‏ (vLCM) או מדיניות אחסון של vSAN בתוך דומיין קיים. אתם יכולים להוסיף את האשכול לאחד מהדומיינים הבאים באותו פרויקט, באותה רשת של ענן וירטואלי פרטי (VPC) ובאותו אזור:

  • ‫Management domain: מוסיף אשכול שמנוהל על ידי שרת הניהול של vCenter ו-NSX Manager.
  • ‫VI workload domain: מוסיף אשכול שמנוהל על ידי שרת ה-vCenter של דומיין עומס העבודה והמכונה של NSX Manager.

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

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

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

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

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

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

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

  • הרשאות: יש לכם את התפקידים הנדרשים של ניהול זהויות והרשאות גישה (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) ואין בו משימות שנכשלו.
  • קובץ אימג' של vSphere Lifecycle Manager ‏ (vLCM): קובץ אימג' של vLCM זמין בספריית קובצי האימג' של VCF, או שאתם מתכננים לחלץ קובץ אימג' ממארח. כדי שכל המארחים יהיו מסונכרנים, צריך להשתמש באותה תמונה שבה משתמשים האשכולות הקיימים.
  • התקני אחסון: לכל מארח חדש יש התקני NVMe local SSD בלי מחיצות קיימות, כפי שנדרש ל-vSAN.
  • מספר הצמתים המינימלי: אשכול דורש לפחות שלושה צמתים של Bare Metal, שזה המינימום הנדרש ל-vSAN עם סבילות לכשל אחד (FTT=1).
  • סוג המכונה: כל הצמתים באשכול משתמשים באותו סוג מכונה (z3-highmem-192-highlssd-metal ל-vSAN Express Storage Architecture‏ (ESA)).
  • ‫Zone: האשכול החדש נמצא באותו אזור שבו נמצאים הניהול הקיים וקבוצות ה-NEG האזוריות של NSX TEP.
  • ‫Jumpbox VM: יש לכם גישה ל-Jumpbox VM שמותקנים בו ה-CLI של gcloud,‏ curl ו-jq, ויש לו קישוריות לרשת ה-VPC (לדוגמה, ברשת המשנה bm-gcp-demo).
  • מדיניות בנושא קובצי אימג' מהימנים ו-VPC Service Controls: אם הארגון שלכם אוכף את מדיניות הארגון 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 בהתאמה אישית.

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

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

פרמטר קלט ערך לדוגמה תיאור
מזהה פרויקט PROJECT_ID אותו פרויקט Google Cloud כמו דומיין היעד
אזור ותחום (zone) us-east4 / us-east4-b אותו אזור כמו קבוצות ה-NEG הקיימות באזור
מספר לקוח demo המזהה שמשמש בשמות של משאבים קיימים
דומיין היעד mgmt-domain (או wld01) דומיין ניהול קיים או דומיין עומס עבודה של VI
שם האשכול cl02 שם אשכול ה-vSphere החדש
סוג המכונה z3-highmem-192-highlssd-metal סוג מכונה הומוגני לכל הצמתים באשכול
מספר הצמתים 3 מספר הצמתים המינימלי ל-vSAN FTT=1
רשת VPC bm-demo רשת VPC קיימת
רשתות משנה (מזהה VLAN) ‫bm-mgmt-demo (ללא תיוג), bm-vmotion-demo (2), bm-vsan-demo (3), bm-nsx-demo (4) רשתות משנה קיימות בשכבה 2
קבוצות NEG של אזור bm-mgmt-demo, bm-nsx-tep-demo קבוצות NEG קיימות של ניהול ו-NSX TEP
קובץ אימג' של ESXi משפחה astra-vcf-9-1-x, פרויקט smve-prod-offline-depot אותו build של קובץ אימג' של ESXi כמו באשכולות הקיימים
דומיין ותחומים של DNS vmware.gve / dns-zone-demo, rev-dns-zone-demo תחומים מנוהלים קיימים של Cloud DNS להעברה וחיפוש הפוך
SDDC Manager sddcm.vmware.gve (192.168.0.3) מכשיר SDDC Manager קיים
סיסמת ESXi root esxi-root-password סוד קיים ב-Secret Manager שמכיל את הסיסמה של ESXi root

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

בטבלה הבאה מוצגת תוכנית כתובות ה-IP לדוגמה לשלושת מארחי ה-ESXi החדשים:

מארח ESXi כתובת ה-IP של הניהול (nic0) vMotion (VLAN 2)‎ vSAN (VLAN 3) NSX TEP (VLAN 4)
esxi-h7 192.168.0.161 192.168.2.21 192.168.3.21 192.168.4.21
esxi-h8 192.168.0.162 192.168.2.22 192.168.3.22 192.168.4.22
esxi-h9 192.168.0.163 192.168.2.23 192.168.3.23 192.168.4.23

בוחרים את דומיין היעד.

דומיין היעד שבוחרים קובע איזה שרת vCenter, מנהל NSX ואזור העברה של שכבת-על ינהלו את האשכול החדש:

פרמטר או משאב אשכול בדומיין הניהול אשכול בדומיין של עומס עבודה ב-VI
משתנה TARGET_DOMAIN mgmt-domain wld01
ניהול של vCenter Server vc01.vmware.gve vc02.vmware.gve
משתנה NSX_MANAGER ‫nsx01.vmware.gve (ניהול NSX) ‫nsx05.vmware.gve (NSX ייעודי) או nsx01.vmware.gve (NSX לניהול משותף)
משתנה TRANSPORT_ZONE overlay-tz-mgmt-nsxt אזור התעבורה של שכבת-העל של מכונת NSX בדומיין של עומס העבודה

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

לפני שאתם מקצים צומתי 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:

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}"
export NETWORK_POOL_NAME="${CLUSTER_NAME}-np01"
export TEP_POOL_NAME="${CLUSTER_NAME}-tep-pool"
export VDS_NAME="${CLUSTER_NAME}-vds-01"
export MACHINE_TYPE="z3-highmem-192-highlssd-metal"
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"  # Secret Manager secret holding the ESXi root password
export MTU=8896                                   # VPC MTU

# Target domain parameters
export TARGET_DOMAIN="mgmt-domain"                # Or wld01
export NSX_MANAGER="nsx01.vmware.gve"             # Or nsx05.vmware.gve for wld01 with a dedicated NSX instance
export TRANSPORT_ZONE="overlay-tz-mgmt-nsxt"      # Overlay transport zone of the target NSX instance

# Ordered host list: name mgmt_ip vmotion_ip vsan_ip tep_ip
CLUSTER_HOSTS=(
  "esxi-h7 192.168.0.161 192.168.2.21 192.168.3.21 192.168.4.21"
  "esxi-h8 192.168.0.162 192.168.2.22 192.168.3.22 192.168.4.22"
  "esxi-h9 192.168.0.163 192.168.2.23 192.168.3.23 192.168.4.23"
)

# TEP pool range matching the new hosts' Compute Engine TEP NIC IPs
export TEP_CIDR="192.168.4.0/24"
export TEP_GATEWAY="192.168.4.1"
export TEP_START="192.168.4.21"
export TEP_END="192.168.4.23"

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

  • ‫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())"

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

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

add_dns() {
  local name=$1 ip=$2
  gcloud dns record-sets create "${name}.${DOMAIN}." \
      --rrdatas="${ip}" --type=A --ttl=300 \
      --zone="${DNS_ZONE}" --project="${PROJECT_ID}"
  local rev
  rev=$(echo "${ip}" | awk -F. '{print $4"."$3"."$2"."$1".in-addr.arpa."}')
  gcloud dns record-sets create "${rev}" \
      --rrdatas="${name}.${DOMAIN}." --type=PTR --ttl=300 \
      --zone="${REV_DNS_ZONE}" --project="${PROJECT_ID}"
}

for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST MGMT_IP _ <<< "${entry}"
  add_dns "${HOST}" "${MGMT_IP}"
done

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

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

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

יצירת מדיניות מיקום מודעות

יוצרים את מדיניות מיקום הקבוצה:

gcloud compute resource-policies create group-placement "${PLACEMENT_POLICY}" \
    --region="${REGION}" \
    --availability-domain-count=6 \
    --collocation=COLLOCATED \
    --project="${PROJECT_ID}"

יצירת דיסקי אתחול ומכונות ESXi ללא מערכת הפעלה

יוצרים את דיסק האתחול של Google Cloud Hyperdisk Balanced ואת מכונת ה-ESXi ללא מערכת הפעלה לכל מארח באשכול:

i=0
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST MGMT_IP VMOTION_IP VSAN_IP TEP_IP <<< "${entry}"
  AD=$(( (i % 6) + 1 )); i=$((i + 1))

  # 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="name~'esxi-h[7-9]'" \
    --format="table(name,status,networkInterfaces[].vlan.list(),networkInterfaces[].networkIP.list())"

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

כל הצמתים באזור חייבים להיות שייכים לאותה קבוצת NEG אזורית של רשת המשנה, כדי שמכשירי הרשת של VCF יוכלו לנתב את התנועה בין הצמתים באשכול. מוסיפים את המארחים החדשים ל-NEG הקיים של הניהול ול-NEG של NSX TEP:

# List the NEGs in the zone (management and NSX TEP)
gcloud compute network-endpoint-groups list --zones="${ZONE}" --project="${PROJECT_ID}" \
    --format="table(name,subnetwork.basename(),networkEndpointType,size)"

ALL_NEGS=("${MGMT_NEG}" "${TEP_NEG}")
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  for NEG in "${ALL_NEGS[@]}"; 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 "${ALL_NEGS[@]}"; do
  gcloud compute network-endpoint-groups list-network-endpoints "${NEG}" \
      --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkEndpoint.instance,networkEndpoint.ipAddress)"
done

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

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

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

# 1. Read the ESXi root password from Secret Manager
ESXI_ROOT_PASSWORD=$(gcloud secrets versions access latest \
    --secret="${ESXI_PASSWORD_SECRET}" --project="${PROJECT_ID}")

# 2. Reset the root password on each new host
for entry in "${CLUSTER_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

# 3. Optional: Verify that the FQDN is set and vmk0 is configured as STATIC
ssh "root@esxi-h7.${DOMAIN}" \
    'esxcli system hostname get; esxcli network ip interface ipv4 get -i vmk0'

יצירת מאגר רשתות ייעודי

‫VCF מקצה כתובות IP של vMotion ו-vSAN ממאגר הרשתות שאתם בוחרים כשאתם מגדירים מארחים. מאגרי הרשת של האשכולות הקיימים מכילים רק את כתובות ה-IP של המארחים שלהם, לכן צריך ליצור מאגר רשת ייעודי שבו טווחי ה-IP מכילים את כתובות ה-IP המדויקות של vMotion ו-vSAN שהוקצו מראש לכרטיסי ה-NIC הדינמיים של Compute Engine במארחים החדשים. שימוש במאגר רשת ייעודי שומר על הקצאת ה-IP של VCF בתוך קבוצת כתובות ה-IP שהוקצו מראש ל-Compute Engine, כך שצריך רק להתאים את סדר המארח ל-IP מאוחר יותר אם יש אי-התאמה.

אפשר ליצור את מאגר הרשתות באמצעות VCF Operations או באמצעות SDDC Manager API:

פעולות VCF

ב-VCF Operations, נכנסים ל-Network pool management, לוחצים על Create network pool ויוצרים את מאגר הרשתות cl02-np01 עם הגדרות הרשת של vMotion (VLAN 2, 192.168.2.21–192.168.2.23) ו-vSAN (VLAN 3, 192.168.3.21–192.168.3.23) ו-MTU של 8896 בייטים.

SDDC Manager API

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

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')

curl -s -X POST "https://${SDDC_MANAGER}/v1/network-pools" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "{
      \"name\": \"${NETWORK_POOL_NAME}\",
      \"networks\": [
        { \"type\": \"VMOTION\", \"vlanId\": 2, \"mtu\": ${MTU},
          \"subnet\": \"192.168.2.0\", \"mask\": \"255.255.255.0\", \"gateway\": \"192.168.2.1\",
          \"ipPools\": [ { \"start\": \"192.168.2.21\", \"end\": \"192.168.2.23\" } ] },
        { \"type\": \"VSAN\", \"vlanId\": 3, \"mtu\": ${MTU},
          \"subnet\": \"192.168.3.0\", \"mask\": \"255.255.255.0\", \"gateway\": \"192.168.3.1\",
          \"ipPools\": [ { \"start\": \"192.168.3.21\", \"end\": \"192.168.3.23\" } ] }
      ]
    }"

# Retrieve the network pool ID for host commissioning
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')
echo "${POOL_ID}"

הזמנת המארחים

מכניסים את מארחי ה-ESXi החדשים למלאי של SDDC Manager באמצעות VCF Operations או SDDC Manager API:

פעולות VCF

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

SDDC Manager API

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

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

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

HOSTS_JSON=$(jq -n --argjson f "${HOST_FQDNS}" --arg p "${ESXI_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
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')

# 3. Poll task status until Successful
curl -s "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" -H "Authorization: Bearer ${TOKEN}" | jq -r '.status'

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

בדיקת התאמת ה-IP לפני הפריסה

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

  1. מוודאים שטווח מאגר הרשתות תואם לכתובות ה-IP של כרטיסי ה-NIC של vMotion ו-vSAN ב-Compute Engine: מוודאים שמאגר הרשתות מכיל רק את כתובות ה-IP שהוקצו מראש לכרטיסי ה-NIC הדינמיים של המארחים החדשים (192.168.2.21 עד 192.168.2.23 ו-192.168.3.21 עד 192.168.3.23 בדוגמה הזו):

    # Inspect network pool definition
curl -s "https://${SDDC_MANAGER}/v1/network-pools/${POOL_ID}" \
    -H "Authorization: Bearer ${TOKEN}" | jq '.networks[] | {type, vlanId, mtu, ipPools}'

# Inspect Compute Engine dynamic NIC IPs per new host (VLAN 2 = vMotion, 3 = vSAN, 4 = TEP)
for entry in "${CLUSTER_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. הקצאת כתובות IP בסדר עולה של שמות המארחים: מקצים מראש את כתובות ה-IP של Compute Engine בסדר עולה של שמות המארחים (esxi-h7 ← .21, ‏ esxi-h8 ← .22, ‏ esxi-h9 ← .23) כדי שקבוצת כתובות ה-IP תהיה זהה בשני הצדדים.

  3. מוודאים ש-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

    אם מוסיפים את האשכול באמצעות SDDC Manager API, לא מגדירים את המאפיין "skipValidations": true בגוף הבקשה.

  4. התאמת הגודל של מאגר ה-TEP של NSX לכתובות ה-IP של ה-NIC של ה-TEP של Compute Engine: מגדירים מאגר סטטי חדש של כתובות IP של ה-TEP של NSX לאשכול, בטווח 192.168.4.21 עד 192.168.4.23 (מהמשתנה TEP_START עד המשתנה TEP_END), שתואם לכתובות ה-IP ב-NIC הדינמיים של VLAN 4 במארחים החדשים, ומגדירים את השער ל-192.168.4.1.

הוספת האשכול

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

פעולות VCF

נכנסים ל-VCF Operations, עוברים אל Inventory, מרחיבים את VCF Instances, בוחרים את דומיין היעד (mgmt-domain או wld01) ולוחצים על Add cluster (או בממשק המשתמש של SDDC Manager, עוברים אל Workload Domains > target domain > Actions > Add Cluster). משלימים את האשף באמצעות ההגדרות הבאות:

דף האשף שדה ערך
אחסון סוג ‫vSAN, ‏ Enable vSAN ESA, ‏ vSAN HCI, הצפנת נתונים במעבר מושבתת
אשכול שם האשכול cl02
תמונה תמונת vLCM בוחרים את קובץ האימג' שבו משתמשים האשכולות הקיימים, או בוחרים באפשרות Extract an image from a host in this VCF instance (באמצעות esxi-h7).
מארחים מארחים ‫esxi-h7, ‏ esxi-h8, ‏ esxi-h9 (הופעלו כ-vSAN ESA עם מאגר הרשת cl02-np01)
vSphere Distributed Switch פרופיל ברירת מחדל (VDS יחיד) או בהתאמה אישית: קישור עולה אחד (uplink1 ← vmnic0), ‏MTU 8896, סוגי תנועה ESX Management, ‏VM Management, ‏vMotion, ‏vSAN ו-NSX
מצב מתג NSX מצב הפעולה של המתג הווירטואלי מבטלים את הבחירה באפשרות Apply the default virtual switch mode configured in NSX Manager ומגדירים את Operational Mode ל-Standard. מארחים של פתרונות VMware לא תומכים במצב ברירת המחדל (Enhanced Datapath Standard).
שכבת-על של מארח NSX הקצאת VLAN ו-IP ל-TEP ‫VLAN 4 (תואם להגדרת NSX הקיימת), מאגר כתובות IP סטטיות (לא להשתמש ב-DHCP): מאגר חדש cl02-tep-pool, ‏CIDR 192.168.4.0/24, טווח 192.168.4.21–192.168.4.23, שער 192.168.4.1
בדיקה שליחה לוחצים על סיום. עוברים אל Fleet Management > Tasks כדי לעקוב אחרי המשימה ולתעד את מזהה המשימה (TASK_ID).

SDDC Manager API

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

# 1. Retrieve target domain ID, vLCM image personality ID, and host specs
DOMAIN_ID=$(curl -s "https://${SDDC_MANAGER}/v1/domains" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r --arg d "${TARGET_DOMAIN}" '.elements[] | select(.name==$d) | .id')

curl -s "https://${SDDC_MANAGER}/v1/personalities" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r '.elements[] | [.personalityId, .personalityName] | @tsv'
IMAGE_ID="PERSONALITY_ID"   # Select the personalityId of the existing clusters' image

HOST_SPECS=$(curl -s "https://${SDDC_MANAGER}/v1/hosts" -H "Authorization: Bearer ${TOKEN}" \
    | jq --argjson f "${HOST_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 3

# 2. Construct the cluster specification (without skipValidations)
CLUSTER_SPEC=$(jq -n \
    --arg domain "${DOMAIN_ID}" --arg name "${CLUSTER_NAME}" --arg img "${IMAGE_ID}" \
    --argjson hosts "${HOST_SPECS}" --arg vds "${VDS_NAME}" --argjson mtu "${MTU}" \
    --arg tz "${TRANSPORT_ZONE}" --arg pool "${TEP_POOL_NAME}" \
    --arg cidr "${TEP_CIDR}" --arg gw "${TEP_GATEWAY}" --arg s "${TEP_START}" --arg e "${TEP_END}" '
{
  domainId: $domain,
  computeSpec: { clusterSpecs: [{
    name: $name,
    clusterImageId: $img,
    hostSpecs: $hosts,
    datastoreSpec: { vsanDatastoreSpec: { datastoreName: ($name + "-vsan"), esaConfig: { enabled: true } } },
    networkSpec: {
      vdsSpecs: [{
        name: $vds, mtu: $mtu,
        portGroupSpecs: [
          { name: ($vds + "-pg-mgmt"),    transportType: "MANAGEMENT", activeUplinks: ["uplink1"], teamingPolicy: "loadbalance_loadbased" },
          { name: ($vds + "-pg-vmotion"), transportType: "VMOTION",    activeUplinks: ["uplink1"], teamingPolicy: "loadbalance_loadbased" },
          { name: ($vds + "-pg-vsan"),    transportType: "VSAN",       activeUplinks: ["uplink1"], teamingPolicy: "loadbalance_loadbased" }
        ],
        nsxtSwitchConfig: {
          transportZones: [ { name: $tz, transportType: "OVERLAY" } ],
          hostSwitchOperationalMode: "STANDARD"
        }
      }],
      nsxClusterSpec: { nsxTClusterSpec: {
        uplinkProfiles: [{ name: ($name + "-uplink-profile"),
          teamings: [ { policy: "LOADBALANCE_SRCID", activeUplinks: ["uplink-1"] } ],
          transportVlan: 4 }],
        ipAddressPoolsSpec: [{ name: $pool,
          subnets: [{ cidr: $cidr, gateway: $gw, ipAddressPoolRanges: [ { start: $s, end: $e } ] }] }]
      }},
      networkProfiles: [{
        name: ($name + "-network-profile"), isDefault: true,
        nsxtHostSwitchConfigs: [{
          vdsName: $vds, uplinkProfileName: ($name + "-uplink-profile"), ipAddressPoolName: $pool,
          vdsUplinkToNsxUplink: [ { vdsUplinkName: "uplink1", nsxUplinkName: "uplink-1" } ]
        }]
      }]
    }
  }]}
}')

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

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

לפני שמריצים את הפקודות, מחליפים את PERSONALITY_ID בערך של personalityId בתמונת ה-vLCM של האשכול.

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

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

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

  1. קריאת כתובות ה-IP שהוקצו ל-VCF: שולחים שאילתה לנקודת הקצה /v1/hosts של SDDC Manager (או למסד הנתונים platform של SDDC Manager) כדי לבדוק אילו כתובות IP של vMotion (vmk1) ו-vSAN (vmk2) הוקצו לכל מארח ב-VCF:

    curl -s "https://${SDDC_MANAGER}/v1/hosts" -H "Authorization: Bearer ${TOKEN}" | jq -r '
  ["FQDN","STATUS","CLUSTER","MGMT_IP","VMOTION_IP","VSAN_IP"],
  (.elements | sort_by(.fqdn)[] | [
     .fqdn, (.status // "-"), (.cluster.name // .cluster.id // "-"),
     (([.ipAddresses[]? | select(.type=="MANAGEMENT") | .ipAddress] | first) // "-"),
     (([.ipAddresses[]? | select(.type=="VMOTION")    | .ipAddress] | first) // "-"),
     (([.ipAddresses[]? | select(.type=="VSAN")       | .ipAddress] | first) // "-")
  ]) | @tsv' | column -t

# Alternative (run on the SDDC Manager appliance shell):
# psql -h localhost -U postgres -d platform \
#   -c "select hostname, vmotion_ip_address, vsan_ip_address from host;"

  2. השוואה לכרטיסי ה-NIC הדינמיים של Compute Engine: מציגים את כתובות ה-IP הנוכחיות של כרטיסי ה-NIC הדינמיים בכל מארח חדש:

    for entry in "${CLUSTER_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

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

    # Example: VCF assigned esxi-h7 vMotion 192.168.2.22 and vSAN 192.168.3.22
HOST="esxi-h7"
VCF_VMOTION_IP="192.168.2.22"
VCF_VSAN_IP="192.168.3.22"

# 3a. Delete mismatched NICs (run on all mismatched hosts before running 3b)
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

# 3b. Re-add the dynamic NICs with the VCF-allocated IP addresses
# vMotion (VLAN 2)
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}"

# vSAN (VLAN 3)
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}"

  4. מנסים שוב את המשימה שנכשלה באשכול: ב-VCF Operations, עוברים אל Fleet Management > Tasks כדי לנסות שוב את המשימה, או מריצים את הפקודה הבאה של SDDC Manager API:

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

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

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

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

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

    NSX_PW="NSX_ADMIN_PASSWORD"

# 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'

    לפני שמריצים את הפקודות, מחליפים את NSX_ADMIN_PASSWORD בסיסמה של NSX Manager admin (זמינה מנקודת הקצה /v1/credentials של SDDC Manager או מניהול הסיסמאות של VCF Operations).

  2. השוואה ל-TEP NIC של Compute Engine (VLAN 4): משווים בין כתובות ה-IP של vmk10 שהוקצו ל-NSX לבין כתובות ה-IP של ה-NIC הדינמי של VLAN 4 במארחים החדשים (esxi-h7,‏ esxi-h8 ו-esxi-h9). רק המארחים החדשים נכללים בהיקף. אל תשנו את ה-TEP NIC של מארחים באשכולות אחרים.

  3. יצירה מחדש של כרטיסי רשת (NIC) של TEP שלא תואמים: בכל המארחים החדשים שלא תואמים, קודם מנתקים כל מארח מ-TEP NEG ומוחקים את הממשק nic0.4 בכל המארחים שלא תואמים. לאחר מכן מוסיפים מחדש את הממשק nic0.4 ומחברים מחדש את המארחים ל-TEP NEG:

    # Example: Compute Engine has 192.168.4.21 on esxi-h7, but NSX assigned 192.168.4.23
HOST="esxi-h7"
CURRENT_TEP_IP="192.168.4.21"
NSX_TEP_IP="192.168.4.23"

# 3a. Detach the host 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}"

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

# 3c. 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}"

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

אימות פריסת האשכול

אחרי שמשימת יצירת האשכול מסתיימת וכל כרטיסי ה-NIC הדינמיים מותאמים, בודקים את הדברים הבאים:

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

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

esxcli network ip interface ipv4 get                        # Verify vmk0, vmk1, vmk2, and vmk10 IPs
vmkping -S vmotion -I vmk1 -d -s 8868 192.168.2.22          # vMotion
vmkping -I vmk2 -d -s 8868 192.168.3.22                     # vSAN
vmkping ++netstack=vxlan -I vmk10 -d -s 8868 192.168.4.22   # NSX TEP

אופציונלי: הגדרת מספר הכשלים המותרים ב-vSAN

ב-vSAN ESA,‏ VCF יוצר ומקצה מדיניות ברירת מחדל לאחסון במאגר נתונים, על סמך סוג האשכול ומספר המארחים. כדי להגדיר את ה-FTT באופן מפורש, בוחרים מדיניות שנתמכת על ידי מספר המארחים באשכול:

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

כדי להגדיר את מדיניות ברירת המחדל לאחסון ב-vSphere Client של שרת ה-vCenter של דומיין היעד (vc01 או vc02):

  1. משביתים את ניהול המדיניות האוטומטי של אשכול ה-vSAN ESA כדי ש-vSAN לא יחליף את מדיניות ברירת המחדל בהתאמה אישית.
  2. עוברים אל Policies and Profiles > VM Storage Policies > Create, מפעילים את כללי האחסון של vSAN, ובקטע Availability בוחרים באפשרות Failures to tolerate (לדוגמה, ‎1 failure - RAID-1 (Mirroring)‎ ל-3 עד 4 מארחים, או ‎2 failures - RAID-6 (Erasure Coding)‎ ל-6 מארחים או יותר).
  3. מגדירים את המדיניות החדשה כברירת המחדל של מאגר הנתונים: בוחרים את מאגר הנתונים cl02 vSAN, עוברים אל Configure ‏ > General ‏ > Default Storage Policy ‏ > Edit ובוחרים את המדיניות החדשה.
  4. מחילים את המדיניות על מכונות וירטואליות קיימות (VM Policies > Edit VM Storage Policies). עוברים אל Monitor ‏ > vSAN ‏ > Virtual Objects באשכול cl02 כדי לוודא שהתאימות קיימת.

פתרון בעיות ביצירת אשכולות

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

שגיאה מטרה רזולוציה
אימות הקישוריות של vSAN ו-vMotion נכשל; מארחים חדשים מדווחים על מצב לא תקין כשיוצרים או מרחיבים אשכול, SDDC Manager מקצה כתובות IP של vmk1 ו-vmk2 ממאגר הרשת בלי לשמור על סדר המארחים. להשאיר את האימותים מופעלים. יוצרים מאגר רשת ייעודי שתואם לכתובות ה-IP של כרטיסי ה-NIC ב-Compute Engine, מוודאים שההתאמה בוצעה לפני הפריסה, ואם המשימה מושהית בבדיקת הקישוריות, מתאימים את כרטיסי ה-NIC הדינמיים ומנסים שוב את המשימה.
סטטוס המארח של NSX הוא Degraded או שהמנהרות מושבתות אחרי הוספת האשכול מנהל NSX מקצה כתובות IP של TEP (vmk10) ממאגר ה-IP באופן אקראי, כך שהן לא בהכרח תואמות ל-NIC של TEP ב-Compute Engine. רשתות משנה של NIC דינמי לא תומכות ב-DHCP. משתמשים במאגר ייעודי של כתובות IP של TEP שתואמות לכתובות ה-IP של TEP ב-Compute Engine, ומתאימים את כרטיסי ה-NIC הדינמיים של TEP אחרי הכנת המארח של NSX.
NSX_VDL2 סוכן או מארח מדווחים על Degraded בזמן ש-BFD פועל כתובת ה-IP של השער חסרה במאגר ה-IP של NSX TEP. מגדירים את שער רשת המשנה (192.168.4.1) במאגר כתובות ה-IP של ה-TEP.
שגיאה מסוג IP_IN_USE כשמוסיפים מחדש NIC דינמי שני מארחים החליפו כתובות IP, או שכתובת IP מתוכננת חופפת לאשכול אחר. לפני שמוסיפים מחדש ממשק, צריך למחוק את כל כרטיסי ה-NIC הדינמיים שלא תואמים בכל המארחים, ולוודא שתוכנית ה-IP לא חופפת לאשכולות קיימים.
אין תמיכה במצב מתג וירטואלי של NSX ב-VCF 9.x, מצב ברירת המחדל של המתג הווירטואלי של NSX הוא Enhanced Datapath Standard, שלא נתמך במארחים של פתרונות VMware. מבטלים את הבחירה באפשרות Apply the default virtual switch mode configured in NSX Manager ומגדירים את Operational Mode ל-Standard (או "hostSwitchOperationalMode": "STANDARD" במפרט ה-API). מידע נוסף זמין במאמר מצב מתג וירטואלי של NSX.
המארחים לא יכולים לשלוח פינג לשער של רשת המשנה (.1) Google Cloud לא מגיב לבקשות ICMP echo בכתובות ה-IP של השער של רשת המשנה. התנהגות צפויה; אפשר להתעלם מאזהרות הפינג של השער.
הגדרת סנכרון זמן (NTP) מארחים של Bare Metal משתמשים בשרת המטא-נתונים של Compute Engine לסנכרון הזמן. משתמשים בכתובת ה-IP של שרת המטא-נתונים (169.254.169.254) ישירות כשרת ה-NTP.
טביעת האצבע או האישור של המארח מציגים שם פנימי דומיין החיפוש של ה-DNS לא מוגדר במארח, או שיש נקודה בסוף שם המארח. מריצים את הפקודה esxcli network ip dns search add -d vmware.gve, מריצים מחדש את הסקריפט /var/lib/vmware/osdata/init.sh, ואז מריצים את הפקודה /sbin/generate-certificates ומפעילים מחדש את השירותים rhttpproxy ו-hostd.
הפעלת המארח נכשלה מתאם VMkernel של vmk0 עדיין משתמש ב-DHCP כי שירות ההפעלה לא המיר אותו. מריצים את הפקודה esxcli network ip interface ipv4 get -i vmk0. אם הסוג הוא DHCP, צריך להגדיר אותו כסטטי באופן ידני (לדוגמה, ב-esxi-h7: esxcli network ip interface ipv4 set -i vmk0 -t static -I 192.168.0.161 -N 255.255.255.0 -g 192.168.0.1).
שגיאות בשכפול vSAN, זמן קצוב לתפוגה של vMotion או פרגמנטציה של שכבת-על ב-NSX כברירת מחדל, ב-VCF מוגדר MTU של 9000 בייטים למתאמי VDS ו-VMkernel ולפרופילי NSX, ורשת ה-VPC משמיטה פריימים שגדולים מ-8896 בייטים. מגדירים MTU של 8896 בייטים ב-VDS, במאגר הרשת (vMotion ו-vSAN) ובפרופיל ה-NSX uplink. מידע נוסף זמין במאמר חוסר התאמה של VDS MTU.
האשף מבקש מזהה VLAN לקבוצת היציאות של שכבת-העל פרופיל ברירת המחדל של VDS דורש את מזהה ה-VLAN של שכבת-העל של מארח NSX. מזינים את מזהה ה-VLAN של ה-TEP של הגדרת ה-NSX הקיימת (4 במדריך הזה).
אין קבוצת יציאות למכונות וירטואליות של עומסי עבודה באשכול החדש פרופיל ברירת המחדל של VDS יוצר רק קבוצות של יציאות תשתית. אחרי שיוצרים את האשכול, יוצרים קבוצת יציאות מבוזרת למכונות הווירטואליות של עומסי העבודה, או משתמשים בהגדרת מתג בהתאמה אישית.
אי אפשר להוסיף מארחים עם קובץ האימג' של vLCM שנבחר תמונת ה-vLCM של האשכול שונה מה-build של ESXi שמותקן במארחים. משתמשים באותה משפחת קובצי אימג' של ESXi שבה משתמשים האשכולות הקיימים, או מחלצים את קובץ האימג' מאחד מהמארחים החדשים.

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