MORNET CLOUD & VIRTUAL INFRASTRUCTURE

ענן ושרתים וירטואליים שמתוכננים לעסק

Cloud טוב מתחיל בארכיטקטורה, לא ביצירת VM. MorNet מתכננת, מקימה ומנהלת שרתים וירטואליים, שירותי ענן, אחסון, רשתות ופתרונות עסקיים בהתאם לעומסי העבודה, רמת האבטחה, התקציב ודרישות הזמינות.

הפתרון יכול להתבסס על Microsoft Azure, תשתית IaaS מתארחת או מודל Hybrid שמחבר את הענן למשרד ולשרתים המקומיים. המטרה היא לבחור את המשאבים והשירותים שנדרשים בפועל, בלי Over-Provisioning ובלי נקודות כשל נסתרות.

ענן ושרתים וירטואליים לעסקים

Sizing נכון

CPU, RAM, דיסקים ורשת נבחרים לפי ה־Workload ולא לפי “כמה חזק אפשר לקנות”.

Security by Design

זהויות, NSG/Firewall, VPN, הרשאות, עדכונים וגיבוי מתוכננים כחלק מהארכיטקטורה.

Availability

זמינות נבנית עם Redundancy, Zones/Instances, גיבוי ו־DR בהתאם ליעדי השירות.

Cost Control

Budgets, ניטור שימוש ו־Right-Sizing כדי שהעלות החודשית תישאר חלק מהניהול ולא הפתעה.

מודלי עבודה

Public Cloud, שרת וירטואלי מתארח או Hybrid

לא כל מערכת צריכה אותה פלטפורמה. אפליקציה עסקית קטנה, שרת Domain, מערכת SQL וסביבת DR יכולים לדרוש מודלים שונים של Compute, Storage ו־Connectivity.

Microsoft Azure

IaaS מבוסס Azure עבור Windows/Linux VMs, Managed Disks, Virtual Network, VPN, Backup ויכולות זמינות ו־DR לפי הארכיטקטורה.

Hosted Virtual Server

שרת וירטואלי מתארח ב־Datacenter/Cloud Provider, כאשר נדרש מודל פשוט יותר של VM, Storage, כתובת IP ושירות מנוהל.

Hybrid Cloud

חיבור בין המשרד, Hyper-V/שרתים מקומיים ושירותי Cloud באמצעות VPN, זהויות, DNS ותכנון נתונים שמאפשר מעבר מדורג.

מעטפת הענן

מה אנחנו מתכננים ומנהלים סביב השרת הווירטואלי

VM הוא רק רכיב אחד. סביבו נדרשים רשת, אחסון, אבטחה, גיבוי, DNS, גישה וניטור. לכן השירות בנוי כארכיטקטורה ולא כ"מכונה בענן".

COMPUTE & VM SIZING

CPU ו־RAM בענן הם גם החלטת ביצועים וגם החלטת עלות

Over-Provisioning מגדיל את העלות החודשית בלי לשפר בהכרח את העבודה, בעוד Under-Sizing יכול לגרום לעומס, I/O איטי וזמני תגובה ארוכים. לכן מתחילים מהיישום ומהמדדים שלו.

בסביבה קיימת אפשר לבחון CPU, Memory, Disk I/O, Network ושעות עומס. בסביבה חדשה משתמשים בדרישות היצרן ובהערכה שמרנית, ואז מבצעים התאמות לאחר שמצטברים נתוני שימוש אמיתיים.

  • CPU לפי סוג היישום, Concurrency ושעות עומס.
  • Memory לפי מערכת ההפעלה, Database, Cache ויישומים.
  • Disk IOPS ו־Throughput לפי עומס האחסון ולא רק לפי נפח GB.
  • Network bandwidth ו־Latency לפי משתמשים, סניפים ושירותים מרוחקים.
  • בחינת Resize לאחר תקופת ניטור במקום להשאיר VM גדול רק "ליתר ביטחון".
תכנון משאבי שרת וירטואלי בענן

CLOUD NETWORKING

שרת בענן שלא מחובר נכון לרשת הופך לאי מבודד או לשירות חשוף מדי

ה־Network Design קובע איך משתמשים, סניפים, שרתים ושירותים מדברים זה עם זה. הוא כולל Addressing, Subnets, Routing, VPN, Security Rules ו־DNS.

VNet & Subnets

חלוקה ל־Address Spaces ו־Subnets שמאפשרת להפריד Frontend, Servers, Management ושירותים נוספים.

NSG & Firewall

כללי Allow/Deny ל־Inbound ו־Outbound, יחד עם Firewall או שכבות נוספות כאשר נדרשת בקרת תעבורה רחבה יותר.

Site-to-Site VPN

חיבור מוצפן בין הרשת המקומית ל־Cloud VNet כדי שהשרתים בענן יהיו חלק מתשתית הארגון.

Management Access

מצמצמים RDP/SSH ישיר לאינטרנט ובוחנים VPN, Bastion או גישה מוגבלת בהתאם לארכיטקטורה.

אחסון ענן Managed Disks ושרתים וירטואליים

STORAGE ARCHITECTURE

נפח דיסק הוא רק נתון אחד. ביצועים ושרידות חשובים לא פחות

שרת SQL, File Server ו־Domain Controller לא בהכרח צריכים אותו סוג Disk. בחירת האחסון צריכה להתחשב ב־IOPS, Throughput, Latency, גודל Block ודפוסי קריאה/כתיבה.

ב־Azure ניתן לבחור Managed Disks ברמות ביצועים ו־Redundancy שונות. כאשר נדרשת עמידות גבוהה יותר ניתן לשלב Storage/Disks עם Zone Redundancy בהתאם לשירות ולתצורה הנתמכת.

  • OS Disk ו־Data Disks לפי תפקיד השרת.
  • בחירת Tier לפי IOPS, Throughput ו־Latency.
  • Snapshot לצורכי נקודת זמן, אך לא כתחליף למדיניות Backup מלאה.
  • בדיקת Redundancy ו־Availability בהתאם ליעדי השירות.
  • ניטור Capacity וקצב גידול כדי למנוע מצב שבו מערכת נתקעת בגלל דיסק מלא.

RELIABILITY & HIGH AVAILABILITY

“השרת בענן” לא אומר שהוא חסין מהשבתה

VM יחיד הוא עדיין Instance יחיד. אם היישום דורש זמינות גבוהה, מתכננים Redundancy ברמת ה־Compute, ה־Zone, האפליקציה, הנתונים וה־DR בהתאם לתקציב ולסיכון.

Availability Zones

פיזור Instances בין אזורים פיזיים נפרדים בתוך Region כאשר היישום והאזור תומכים בכך.

Multiple Instances

יישום שתומך בכך יכול לרוץ ביותר מ־VM אחד מאחורי Load Balancer כדי לצמצם תלות ב־Instance יחיד.

Data Resilience

Storage, Database ו־Replication צריכים לעמוד באותה רמת זמינות כמו ה־Compute ולא ליצור Single Point of Failure.

Backup & DR

High Availability אינה מחליפה Backup ו־DR. כל שכבה מטפלת בסוג אחר של תקלה או אובדן שירות.

CLOUD SECURITY

Cloud Provider מאבטח את הפלטפורמה. את התצורה וה־Workload עדיין צריך לנהל

שרת וירטואלי יכול להיות מאובטח או חשוף בהתאם ל־Ports, הרשאות, מערכת ההפעלה, חשבונות מנהל, Firewall, VPN, עדכונים ו־Backup. מעבר לענן לא מבטל את הצורך ב־Hardening.

לכן אנחנו בוחנים את ה־VM כחלק ממערכת: Identity, Network, OS, Data, Backup ו־Monitoring.

  • Least Privilege וחשבונות ניהול נפרדים בהתאם לסביבה.
  • NSG/Firewall עם מינימום Ports שנדרשים לעבודה.
  • VPN/Bastion או מנגנון גישה מאובטח במקום RDP/SSH פתוח כאשר אפשר.
  • Patch Management, Endpoint/EDR והקשחות ברמת מערכת ההפעלה.
  • Backup ו־Restore שאינם תלויים רק ב־Snapshot של ה־VM.
אבטחת שרתים וירטואליים בענן

CLOUD MIGRATION

מיגרציה לענן מתחילה בתלויות, לא בהעתקת דיסק

לפני העברת שרת בודקים DNS, Active Directory, Database, Shares, כתובות IP, Firewall, רישוי, Backup, Latency וחיבורים למערכות נוספות. רק לאחר מכן בונים את סדר המעבר.

01

Discovery

שרתים, אפליקציות, Data, DNS, Users, תלות וספקים.

02

Sizing & Design

Compute, Storage, Network, Security, Backup ו־Availability.

03

Pilot

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

04

Migration

העברת Server/Data בשלבים, בדיקות ו־Cutover עם Rollback כאשר נדרש.

05

Optimize

Right-Sizing, Cost, Backup, Monitoring והסרת משאבים ישנים לאחר שהמערכת יציבה.

ניהול עלויות ענן ושרתים וירטואליים

COST MANAGEMENT

העלות של VM היא רק חלק מחשבון הענן

לצד Compute יש Storage, Backup, Public IP, Network Egress, VPN, Security ושירותים נוספים. לכן תחזית עלות צריכה לכלול את הארכיטקטורה המלאה ולא רק את מחיר ה־VM.

לאחר ההקמה בוחנים שימוש בפועל. VMs עם ניצול נמוך יכולים לעבור Resize, משאבים לא בשימוש מוסרים, ו־Reservations או Savings Plans נבחנים רק כאשר יש שימוש בסיסי יציב שמצדיק התחייבות.

  • Budget ו־Alerts בהתאם למסגרת התקציב של הארגון.
  • Cost Analysis לפי Resource Group/Service כדי להבין מאיפה מגיעה העלות.
  • Right-Sizing לאחר שמצטברים נתוני שימוש אמיתיים.
  • כיבוי/מחיקה של משאבים שלא בשימוש לאחר בדיקה.
  • Reservations/Savings Plans כאשר דפוס השימוש יציב והכדאיות ברורה.

BACKUP & DISASTER RECOVERY

Availability, Backup ו־DR הם שלושה דברים שונים

Availability מנסה לשמור את השירות פעיל בזמן תקלה. Backup מאפשר לחזור לנקודת זמן קודמת. DR מתכנן כיצד להחזיר Workload לאחר כשל משמעותי באתר, Zone או Region בהתאם לארכיטקטורה.

Azure Backup / Backup Platform

Recovery Points, Retention ושחזור VM/Files בהתאם לשירות, או Veeam/Acronis/פתרון אחר שמתאים לסביבה.

Replication / Site Recovery

Replication ו־Failover לסביבה חלופית כאשר RTO/RPO מצדיקים מנגנון DR מעבר לגיבוי רגיל.

Restore / Failover Testing

בדיקות שחזור או Test Failover כדי לוודא שהמסלול לחזרה לעבודה מתפקד לפני אירוע אמת.

CLOUD OPERATIONS

גם אחרי המיגרציה, הענן דורש תחזוקה, ניטור ותיעוד

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

  • CPU, Memory, Disk, Network ומדדי שימוש מרכזיים.
  • Alerts לתקלות, Capacity ואירועים בהתאם לכלי הניטור.
  • Patch Management ו־Hardening ברמת מערכת ההפעלה.
  • בדיקת Backup Jobs ו־Restore בהתאם למדיניות.
  • סקירת Cost ושימוש לאחר שינויים או גידול בעומס.
  • תיעוד VM, IP, DNS, Rules, Credentials/Access ו־Dependencies.
ניהול וניטור שרתים וירטואליים בענן

שאלות נפוצות

ענן ושרתים וירטואליים, מה חשוב לדעת?

בשרת מקומי הארגון מחזיק את החומרה, החשמל, האחסון והתשתית הפיזית. ב-Cloud IaaS משתמשים במשאבי Compute, Storage ו-Network אצל ספק ענן ומשלמים לפי המודל של השירות. האחריות על מערכת ההפעלה, האפליקציה והגדרות האבטחה עדיין נשארת חלק מניהול ה-Workload.
לא בהכרח. בודקים עומס, Latency, נפח אחסון, רישוי, תלות בציוד מקומי, עלויות חודשיות ודרישות זמינות. לעיתים Azure מתאים מאוד, ולעיתים Hosted VM או Hyper-V מקומי נותנים יחס נכון יותר.
Infrastructure as a Service הוא מודל שבו מקבלים משאבי תשתית וירטואליים כמו VM, דיסקים ורשת במקום לרכוש ולתחזק את החומרה הפיזית. עדיין צריך לנהל מערכת הפעלה, אבטחה, גיבוי ואפליקציות.
Virtual Network היא רשת לוגית בענן שמכילה Address Spaces ו-Subnets ומאפשרת לחבר שרתים ושירותים, להחיל Security Rules וליצור קישוריות מול רשתות אחרות.
כן. במקרים מתאימים ניתן להשתמש ב-Site-to-Site VPN כדי ליצור חיבור מוצפן בין הרשת המקומית ל-VNet בענן. כך שרתים בענן יכולים להשתלב בשירותים פנימיים וב-DNS/Active Directory בהתאם לתכנון.
Availability Zone היא מיקום פיזי נפרד בתוך Azure Region עם תשתיות חשמל, קירור ורשת עצמאיות. כדי לקבל עמידות לכשל Zone צריך לבנות את היישום וה-VMs כך שיהיו מפוזרים בין Zones ולא להסתמך על VM יחיד.
לא. VM יחיד נשאר נקודת Compute יחידה. High Availability עשויה לדרוש יותר מ-Instance אחד, פיזור בין Zones, Load Balancing וארכיטקטורת Data מתאימה, לפי היישום והיעדים.
Snapshot מספק נקודת מצב של Disk ויכול להיות שימושי לתרחישים מסוימים, אבל מדיניות Backup מלאה כוללת Retention, Recovery Points, Restore ותכנון עותקים. בסביבות Production מומלץ להגדיר Backup בהתאם ל-RPO/RTO ולא להסתמך רק על Snapshot.
מתחילים ב-Sizing נכון, מגדירים Budgets ו-Alerts, בוחנים Cost Analysis ומבצעים Right-Sizing לאחר שמצטברים נתוני שימוש. כאשר יש שימוש יציב ניתן לבדוק Reservations או Savings Plans בהתאם לכדאיות.
במקרים רבים אפשר לבצע Migration של VM או Workload לענן, אבל לפני כן צריך לבדוק מערכת הפעלה, רישוי, אפליקציות, IP/DNS, Storage, Latency ותלות בשירותים מקומיים. לעיתים נכון יותר לבנות VM חדש ולהעביר אליו את השירות.
כן, אם הארגון צריך אפשרות לחזור לנקודת זמן קודמת או להתאושש ממחיקה, תקלה או אירוע סייבר. Azure Backup ופתרונות צד שלישי יכולים לספק Recovery Points ו-Restore בהתאם לארכיטקטורה.
Backup נועד לשמור Recovery Points לשחזור נתונים או VM. Site Recovery הוא שירות Replication ו-Failover לתרחישי Disaster Recovery, שבו Workloads משוכפלים לסביבה חלופית כדי לקצר השבתה בתרחישים מתאימים.
כן. ניתן לשלב את סביבת הענן בתוך Managed IT הכולל ניטור, עדכונים, אבטחה, גיבוי, עלויות, רשת, משתמשים ותיעוד בהתאם למסגרת השירות.

MORNET CLOUD SERVICES

מתכננים שרת חדש, מעבר לענן או סביבת Hybrid?

ספרו לנו מה השרת עושה היום, כמה משתמשים עובדים מולו, כמה מידע הוא מחזיק ומה רמת הזמינות שנדרשת. נוכל להשוות בין Cloud, Hosted VM ו־On-Premises ולבנות ארכיטקטורה שמתאימה ל־Workload ולתקציב.