زیرساخت MongoDB

مقدمه و اهداف سند

در بسیاری از سازمان‌ها، دیتابیس MongoDB به‌صورت لوکال و در کنار اپلیکیشن روی همان سرور اجرا می‌شود. این رویکرد در فاز توسعه یا محیط‌های کوچک قابل قبول است، اما در محیط Production سازمانی چند مشکل جدی ایجاد می‌کند: عدم امکان مقیاس‌پذیری مستقل دیتابیس، نبود High Availability، رقابت منابع (CPU، RAM، Disk I/O) بین اپلیکیشن و دیتابیس، دشواری Backup و Restore، و مهم‌تر از همه، ریسک از دست رفتن داده در صورت خرابی سرور .

هدف این سند، ارائه راهنمای معماری برای جداسازی MongoDB از سرور و تبدیل آن به یک دیتابیس مستقل و متمرکز روی زیرساخت مجازی‌سازی PVM است. در این معماری، MongoDB روی ماشین‌های مجازی اختصاصی مستقر می‌شود، پیکربندی می‌گردد و از طریق شبکه اختصاصی دیتابیس در اختیار سرور PVM قرار می‌گیرد.

این سند مشخصاً برای شرایطی نوشته شده که دو حالت را داشته باشد :

• زیرساخت فیزیکی (سرور، سوئیچ، شبکه) توسط کارفرما تامین شده
• زیرساخت فیزیکی (سرور، سوئیچ، شبکه) توسط کارفرما تامین نشده

و تیم AVID مسئولیت طراحی و پیاده‌سازی لایه مجازی‌سازی، شبکه داخلی VMها و زیرساخت MongoDB را بر عهده دارد. از آنجا که سطح دسترسی کارفرما به لایه شبکه فیزیکی در سازمان‌های مختلف متفاوت است، سه سناریوی پیاده‌سازی جداگانه برای این معماری تعریف شده که هرکدام در ادامه به‌تفکیک بررسی می‌شوند.

💡 به زبان ساده: وقتی می‌خواهید MongoDB را روی ماشین مجازی PVM نصب کنید، مهم‌ترین چالش این نیست که MongoDB را چطور نصب کنید — بلکه این است که شبکه دیتابیس را چگونه از شبکه مدیریت جدا کنید. بسته به اینکه کارفرما چه سطحی از دسترسی شبکه را در اختیار شما بگذارد، سه سناریوی کاملاً متفاوت وجود دارد.

🔧 از دید فنی: هدف اصلی این سند، طراحی لایه ۲ و ۳ شبکه برای ترافیک MongoDB است به‌گونه‌ای که:

• ترافیک دیتابیس از شبکه Management عبور نکند
• ایزولیشن کامل بین ترافیک دیتابیس و ترافیک مدیریتی PVM برقرار باشد
• عملکرد شبکه (Latency و Throughput) برای عملیات دیتابیسی بهینه باشد
• امنیت ترافیک دیتابیسی در سطح لایه ۲ تضمین شود

پیش‌نیازهای زیرساختی

قبل از شروع استقرار، موارد زیر باید فراهم باشد:

سخت‌افزار و مجازی‌ساز (نصب MongoDB به صورت مستقل)

• انتخاب محل استقرار سرور دیتابیس: برای نصب دیتابیس دو گزینه وجود دارد:

  • 1. نصب به‌صورت یک ماشین مجازی روی همان سرور PVM موجود
  • 2. یا در صورت امکان، نصب به‌عنوان یک ماشین مجازی مستقل روی یک سرور فیزیکی جداگانه در شبکه

  گزینه دوم از نظر ایزولاسیون منابع، پایداری و جداسازی Failure Domain ارجحیت دارد؛ چرا که خرابی سرور PVM اصلی تاثیری بر دسترس‌پذیری دیتابیس نخواهد داشت.

• حداقل ۲ پورت شبکه فیزیکی روی هر سرور (یکی برای Management و یکی برای ترافیک VM)

• RAM کافی برای ماشین‌ مجازی MongoDB (حداقل ۸ گیگابایت به ازای هر نود)

• فضای دیسک کافی برای ماشین مجازی MongoDB (حداقل 200 گیگ)

• دیسک SSD/NVMe برای ذخیره‌سازی داده MongoDB

شبکه

شبکه موردنیاز برای ارتباط MongoDB با سایر Nodeها و ماشین‌های مجازی، بر اساس نوع استقرار PVM و محل قرارگیری دیتابیس تعیین می‌شود.

PVM Cluster

در صورتی که PVM به‌صورت Cluster پیاده‌سازی شده باشد و Nodeهای مختلف PVM نیاز به برقراری ارتباط شبکه‌ای با MongoDB داشته باشند، شبکه دیتابیس باید در اولویت به‌صورت فیزیکی و منطقی ایزوله از سایر شبکه‌های زیرساخت در نظر گرفته شود.

PVM Cluster — Isolated Database Network

PVM Node 0110.10.10.11

PVM Node 0210.10.10.12

PVM Node 0310.10.10.13

Core Switch

VLAN 10 · Mgmt

Trunk · 802.1Q

DB Switch

VLAN 20 · Isolated

Mongo 01Primary10.20.20.101

ACL: Only PVM → :27017

TLS Encrypted

No Internet on VLAN 20

شبکه کاملاً ایزوله دیتابیس

در این سناریو، کلاستر PVM از طریق یک شبکه کاملاً ایزوله و اختصاصی به زیرساخت دیتابیس متصل می‌شود. هدف از این طراحی، ایجاد یک مسیر ارتباطی مستقل برای ترافیک دیتابیس و جلوگیری از اختلاط ترافیک MongoDB با شبکه‌های عمومی، Management و سایر سرویس‌های سازمان است.

در این معماری، شبکه دیتابیس از لحظه خروج ترافیک از سرورهای PVM تا رسیدن به زیرساخت MongoDB دارای مسیر و کنترل‌های اختصاصی است.

به‌صورت کلی، معماری شبکه به شکل بالا خواهد بود

↓ اتصال فیزیکی مستقل برای دیتابیس

برای ایجاد حداکثر سطح ایزولاسیون، هر Node از کلاستر PVM باید دارای یک Physical Network Connection مستقل برای ترافیک دیتابیس باشد.

به این معنی که یک Physical NIC یا Physical Port مشخص از هر سرور PVM به شبکه دیتابیس اختصاص داده می‌شود.

به‌عنوان مثال:

PVM Node 1
│
├── NIC 1 → Management Network
├── NIC 2 → VM / Service Network
└── NIC 3 → Database Network

در این حالت، ترافیک دیتابیس از یک مسیر فیزیکی مستقل عبور می‌کند و با ترافیک Management یا سایر شبکه‌های PVM روی یک Physical Interface مشترک قرار نمی‌گیرد.

بنابراین، در صورت امکان، پیشنهاد می‌شود شبکه دیتابیس از همان ابتدا در سطح Physical نیز از سایر شبکه‌های PVM تفکیک شود.

---

سوئیچ ایزوله اختصاصی دیتابیس ↓

Physical Port اختصاص‌یافته به دیتابیس باید به یک Switch اختصاصی یا کاملاً ایزوله‌شده برای شبکه دیتابیس متصل شود.

به‌صورت ایده‌آل، مسیر شبکه باید به شکل زیر باشد:

PVM Node 1 ─────┐
PVM Node 2 ─────┤
PVM Node 3 ─────┤
                ▼
        ┌─────────────────┐
        │ Database Switch │
        │                 │
        │ Isolated Network│
        └────────┬────────┘
                 │
                 ▼
             MongoDB

این Switch نباید بدون نیاز، با شبکه‌های عمومی سازمان، Management Network یا سایر شبکه‌های سرویس‌ها ارتباط داشته باشد.

هدف از این جداسازی آن است که حتی در صورت وجود خطای پیکربندی در لایه‌های بالاتر، مسیر فیزیکی ترافیک دیتابیس همچنان از سایر شبکه‌ها جدا باقی بماند.

---

VLAN اختصاصی دیتابیس ↓

علاوه بر جداسازی فیزیکی، یک VLAN اختصاصی برای دیتابیس نیز باید توسط کارفرما تعریف شود.

به‌عنوان مثال:

VLAN ID: 300
Name:    DB-NET
Subnet:  10.30.0.0/24

این VLAN صرفاً برای ترافیک مرتبط با دیتابیس استفاده خواهد شد.

در این حالت:

Database VLAN
      │
      ├── PVM Node 1
      ├── PVM Node 2
      ├── PVM Node 3
      │
      └── MongoDB Nodes

استفاده از VLAN اختصاصی باعث می‌شود شبکه دیتابیس علاوه بر Physical Isolation، در سطح منطقی نیز Logical Isolation داشته باشد.

بنابراین دو لایه جداسازی خواهیم داشت:

Physical Isolation
        +
Logical Isolation
        │
        ▼
Database Network

کنترل دسترسی و ACL ↓

ایزوله بودن شبکه به‌تنهایی به معنی امن بودن کامل آن نیست.

روی Switchها و تجهیزات شبکه باید ACL و Security Rule مناسب برای محدود کردن ارتباطات شبکه دیتابیس اعمال شود.

برای مثال، در صورتی که فقط Nodeهای مشخص PVM مجاز به برقراری ارتباط با MongoDB باشند، می‌توان دسترسی را به همین Nodeها محدود کرد:

Allowed:

PVM Node 1 ────────┐
PVM Node 2 ────────┼──────► MongoDB
PVM Node 3 ────────┘


Denied:

Other Network ───────────X──► MongoDB
User Network ────────────X──► MongoDB
Guest Network ───────────X──► MongoDB
Internet ────────────────X──► MongoDB

قوانین ACL باید بر اساس نیاز واقعی سرویس تعریف شوند و دسترسی‌های غیرضروری مسدود شوند.

برای نمونه، در صورتی که MongoDB از پورت استاندارد استفاده کند، تنها Sourceهایی که واقعاً نیاز به ارتباط با MongoDB دارند باید اجازه دسترسی به پورت مربوطه را داشته باشند.

اصل طراحی: دسترسی به شبکه دیتابیس باید بر اساس Least Privilege تعریف شود؛ یعنی هر سیستم فقط به اندازه‌ای که برای عملکرد سرویس نیاز دارد، اجازه ارتباط داشته باشد.

لایه‌های ایزولاسیون شبکه ↓

در این معماری، ایزولاسیون دیتابیس در چند لایه انجام می‌شود:

                    Database Security
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
    Physical Layer    Network Layer    Security Layer
          │                │                │
          ▼                ▼                ▼
   Dedicated NIC     Dedicated VLAN       ACL
          │                │                │
          ▼                ▼                ▼
 Dedicated Switch    DB Subnet         Firewall Rules
          │                │                │
          └────────────────┼────────────────┘
                           ▼
                       MongoDB

در نتیجه، شبکه دیتابیس تنها یک VLAN ساده نخواهد بود؛ بلکه مجموعه‌ای از جداسازی فیزیکی، جداسازی منطقی و کنترل دسترسی شبکه خواهد بود.

---

نتیجه نهایی معماری ↓

در این سناریو، مسیر ارتباطی به‌صورت زیر تعریف می‌شود:

PVM Node
   │
   │ Dedicated Physical NIC
   ▼
Database Switch
   │
   │ Dedicated Database VLAN
   ▼
Database Network
   │
   │ ACL / Security Rules
   ▼
MongoDB

بنابراین الزامات این سناریو از سمت کارفرما عبارت‌اند از:

• اختصاص Physical Port / NIC مستقل برای شبکه دیتابیس به هر Node موردنیاز PVM
• اتصال این پورت‌ها به شبکه یا Switch ایزوله دیتابیس
• اختصاص VLAN اختصاصی دیتابیس
• مشخص کردن Subnet و IP Range مربوط به دیتابیس
• اعمال ACL و Security Rule برای محدود کردن دسترسی‌ها
• مشخص کردن Source و Destinationهای مجاز
• مشخص کردن Port و Protocolهای موردنیاز
• جلوگیری از دسترسی مستقیم شبکه‌های غیرمرتبط به شبکه دیتابیس

نکته: این سناریو بالاترین سطح جداسازی شبکه را در بین روش‌های مورد استفاده در این مستند فراهم می‌کند، زیرا ترافیک دیتابیس هم در سطح Physical و هم در سطح Logical از سایر ترافیک‌های زیرساخت جدا شده است.

معماری دوم در PVM Cluster

PVM Cluster — Isolated Database Network

PVM Node 0110.10.10.11

PVM Node 0210.10.10.12

PVM Node 0310.10.10.13

Core Switch

VLAN 10 · Mgmt

Trunk · 802.1Q

DB Switch

VLAN 20 · Isolated

Mongo 01Primary10.20.20.101

ACL: Only PVM → :27017

TLS Encrypted

No Internet on VLAN 20

PVM Cluster — Logical Isolation via VLAN ↓

در این معماری، برای اتصال Nodeهای مختلف PVM Cluster به MongoDB تنها یک مسیر فیزیکی مشترک در نظر گرفته شده است.

یعنی:

• یک Physical Port / Physical Link برای اتصال PVM Cluster به شبکه

• یک Core Switch مشترک

• یک Database VLAN اختصاصی

• بدون وجود Database Switch اختصاصی

در این معماری، جداسازی شبکه Database در سطح Logical و بر مبنای VLAN انجام می‌شود و برخلاف معماری Physical Isolation، الزاماً به یک مسیر فیزیکی اختصاصی برای Database وابسته نیست.

با این حال، در لایه فیزیکی دو روش برای اتصال Database به شبکه قابل پیاده‌سازی است:

• استفاده از NIC اختصاصی برای MongoDB: یک کارت شبکه مستقل به MongoDB اختصاص داده شده و این Interface مستقیماً برای دسترسی به Database Network استفاده می‌شود.

• استفاده از NIC مشترک: ترافیک MongoDB می‌تواند در کنار ترافیک سایر VMها از همان Physical NIC عبور کند و تفکیک ترافیک در سطح VLAN انجام شود.

بنابراین، Logical Isolation با VLAN می‌تواند هم روی یک NIC اختصاصی و هم روی یک NIC مشترک پیاده‌سازی شود؛ تفاوت اصلی در این است که در حالت NIC اختصاصی، مسیر فیزیکی Database نیز از سایر ترافیک‌ها تفکیک می‌شود، اما در حالت NIC مشترک، جداسازی صرفاً در سطح منطقی و با استفاده از VLAN، Trunk و Policyهای کنترلی شبکه انجام می‌گیرد.

اجزای اصلی معماری ↓

• 1. PVM Nodes

Nodeهای مختلف PVM از همان زیرساخت شبکه موجود برای برقراری ارتباط با MongoDB استفاده می‌کنند.

برای مثال:

PVM Node 01 → 10.10.10.11
PVM Node 02 → 10.10.10.12
PVM Node 03 → 10.10.10.13

این Nodeها برای دسترسی به MongoDB باید اجازه دسترسی به Database VLAN را داشته باشند.

• 2. Physical Port / Physical Link

در این معماری یک مسیر فیزیکی برای انتقال ترافیک وجود دارد و Database Network از یک Physical Port یا Link اختصاصی مستقل برای خودش استفاده نمی‌کند.

در نتیجه، Database Traffic و سایر Trafficها می‌توانند از یک زیرساخت فیزیکی مشترک عبور کنند.

برای مثال:

                    Physical Link
                         │
                         ▼
                 ┌──────────────┐
                 │ Core Switch  │
                 └──────┬───────┘
                        │
             ┌──────────┴──────────┐
             │                     │
          VLAN 10               VLAN 20
          Mgmt                  Database
             │                     │
             ▼                     ▼
        Management              MongoDB

• 3. Core Switch

Core Switch نقطه مرکزی این معماری است.

همان Switch وظیفه انتقال VLANهای مختلف را بر عهده دارد.

برای مثال:

Core Switch
│
├── VLAN 10 → Management Network
│
└── VLAN 20 → Database Network

بنابراین برخلاف معماری قبلی، Database Switch مجزا وجود ندارد.

• 4. Database VLAN

برای MongoDB یک VLAN اختصاصی ایجاد می‌شود.

برای مثال:

VLAN ID    : 20
VLAN Name  : DATABASE-NET
Subnet     : 10.20.20.0/24
MongoDB    : 10.20.20.100
Port       : TCP/27017

VLAN 20 باعث می‌شود Database Traffic از نظر منطقی از VLANهای دیگر جدا شود.

• 5. ACL

دسترسی به MongoDB نباید صرفاً به دلیل قرار داشتن یک Host در شبکه سازمانی آزاد باشد.

باید ACL یا Firewall Policy تعریف شود تا فقط Sourceهای مجاز بتوانند به MongoDB متصل شوند.

برای مثال:

PVM Node 01 ───────┐
PVM Node 02 ───────┼── TCP/27017 ──► MongoDB
PVM Node 03 ───────┘

Other Networks ───────────────X────► MongoDB

در این مثال فقط Nodeهای PVM اجازه دسترسی به Port مربوط به MongoDB را دارند.

• 6. TLS

در کنار Network Segmentation، ارتباط MongoDB باید در صورت نیاز با TLS رمزنگاری شود.

بنابراین:

Database VLAN
     │
     │ TCP/27017
     │
     │ TLS
     ▼
 MongoDB

TLS جایگزین VLAN یا ACL نیست.

VLAN وظیفه Segmentation را بر عهده دارد، ACL وظیفه Access Control را کنترل می‌کند و TLS وظیفه Encryption ترافیک را بر عهده دارد.

ویژگی اصلی این معماری ↓

مهم‌ترین ویژگی این معماری این است که یک Physical Infrastructure مشترک داریم اما روی آن چند Network منطقی ایجاد شده است.

                 ONE PHYSICAL NETWORK
                         │
                         ▼
                   Core Switch
                         │
              ┌──────────┴──────────┐
              │                     │
          VLAN 10                 VLAN 20
          Management              Database
              │                     │
              ▼                     ▼
          Mgmt Traffic          DB Traffic

بنابراین Database از نظر منطقی جدا است، اما از نظر فیزیکی همچنان از همان مسیر و تجهیزات مشترک استفاده می‌کند.

محدودیت‌های این معماری ↓

• 1. عدم وجود Physical Isolation

بزرگ‌ترین محدودیت این معماری این است که Database Network از نظر فیزیکی جدا نیست.

اگر Core Switch یا مسیر فیزیکی مشترک دچار مشکل شود، ممکن است هم Networkهای عمومی و هم Database Network تحت تأثیر قرار بگیرند.

             Core Switch
                  │
          ┌───────┴───────┐
          │               │
       VLAN 10         VLAN 20
       Mgmt               DB
          │               │
          └───────┬───────┘
                  │
             Single Point
              of Failure

• 2. وابستگی بیشتر به Configuration

امنیت این معماری وابستگی زیادی به صحیح بودن Configuration دارد.

اشتباه در مواردی مانند:

VLAN
Trunk
ACL
Routing
Firewall

می‌تواند باعث ایجاد دسترسی ناخواسته یا اختلال در ارتباط MongoDB شود.

• 3. Shared Infrastructure

Database Traffic از همان Infrastructure فیزیکی سایر سرویس‌ها استفاده می‌کند.

بنابراین در شرایطی که ترافیک شبکه بسیار زیاد باشد، Database Traffic نیز می‌تواند تحت تأثیر ظرفیت همان Infrastructure قرار بگیرد.

البته این موضوع به ظرفیت لینک، QoS و طراحی شبکه سازمان بستگی دارد و به معنی وجود مشکل قطعی نیست.

• 4. وابستگی به Core Switch

Core Switch در این معماری اهمیت بسیار بالایی دارد.

اگر این Switch دچار Failure شود و Redundancy مناسبی برای آن وجود نداشته باشد، ممکن است ارتباط چندین PVM Node با MongoDB هم‌زمان قطع شود.

بنابراین در محیط Production باید وضعیت‌هایی مانند:

Core Switch Failure
Uplink Failure
NIC Failure
Link Failure
VLAN Misconfiguration

در طراحی High Availability بررسی شوند.

• 5. ریسک Misconfiguration

در معماری VLAN، اشتباه در Tagging یا Trunk Configuration می‌تواند باعث شود ترافیک Database به مقصد موردنظر نرسد یا در طراحی‌های نادرست، Segmentation مورد انتظار را تضعیف کند.

به همین دلیل VLAN Configuration باید مستند و کنترل‌شده باشد.

مقایسه با معماری Physical + Logical Isolation ↓

در معماری قبلی، Database دارای مسیر فیزیکی و منطقی اختصاصی بود:

PVM
 │
 ▼
Dedicated Physical Port
 │
 ▼
Database Switch
 │
 ▼
Database VLAN
 │
 ▼
MongoDB

اما در این معماری:

PVM
 │
 ▼
Shared Physical Network
 │
 ▼
Core Switch
 │
 ▼
Database VLAN
 │
 ▼
MongoDB

تفاوت اصلی این دو معماری در محل ایجاد Isolation است.

مورد	Physical + Logical Isolation	Logical Isolation via VLAN
Physical Port اختصاصی	دارد	ندارد
Database Switch اختصاصی	دارد	ندارد
Database VLAN	دارد	دارد
Physical Isolation	دارد	ندارد
Logical Isolation	دارد	دارد
زیرساخت فیزیکی مشترک	حداقل	دارد
وابستگی به VLAN/Trunk	دارد	بیشتر
وابستگی به ACL	دارد	دارد
وابستگی به Core Switch	کمتر	بیشتر
هزینه پیاده‌سازی	بیشتر	کمتر
پیچیدگی فیزیکی	بیشتر	کمتر
سطح جداسازی	بالاتر	پایین‌تر
مناسب برای	محیط‌های حساس و High Security	اکثر محیط‌های سازمانی با Segmentation مناسب

تفاوت امنیتی دو معماری ↓

در معماری Physical + Logical Isolation:

Physical Isolation
       +
Logical Isolation
       +
ACL / Firewall
       +
TLS

در معماری VLAN:

Logical Isolation
       +
ACL / Firewall
       +
TLS

بنابراین در معماری VLAN، بخش Physical Isolation حذف شده است.

این موضوع الزاماً به معنی ناامن بودن معماری VLAN نیست؛ بلکه به این معنی است که سطح جداسازی آن به اندازه معماری دارای Physical Isolation نیست و امنیت آن بیشتر به صحیح بودن طراحی و Configuration شبکه وابسته است.

چه زمانی این معماری قابل استفاده است؟ ↓

این معماری زمانی انتخاب مناسبی است که:

• کارفرما امکان اختصاص Database Switch ندارد.

• امکان اختصاص Physical Port مستقل برای Database وجود ندارد.

• سازمان اجازه ایجاد Database VLAN روی شبکه موجود را می‌دهد.

• Core Switch ظرفیت کافی دارد.

• ACL / Firewall Policy مناسب قابل پیاده‌سازی است.

• دسترسی به MongoDB فقط به Sourceهای مشخص محدود می‌شود.

• Redundancy مناسب برای Core Network در محیط Production وجود دارد.

در چنین شرایطی، Logical Isolation via VLAN می‌تواند یک معماری عملی و قابل قبول برای ارتباط PVM Cluster با MongoDB باشد.

جمع‌بندی محدودیت نسبت به معماری قبلی ↓

Physical + Logical Isolation
        │
        ├── Physical Separation
        ├── Logical Separation
        ├── Dedicated DB Path
        └── Higher Isolation
                  ▲
                  │
             Stronger
                  │
                  ▼
Logical Isolation via VLAN
        │
        ├── Logical Separation
        ├── Shared Physical Path
        ├── Shared Core Switch
        └── Higher Dependency on Configuration

پس اگر بخواهیم این دو معماری را از نظر سطح Isolation رتبه‌بندی کنیم:

Physical + Logical Isolation > Logical Isolation via VLAN

اما اگر معیار هزینه، سادگی و استفاده از زیرساخت موجود باشد:

Logical Isolation via VLAN > Physical + Logical Isolation

---

PVM Single Node

در صورتی که PVM به‌صورت Single Node پیاده‌سازی شده باشد، نحوه تأمین شبکه دیتابیس به محل استقرار MongoDB بستگی دارد.

MongoDB خارج از سرور PVM

در صورتی که MongoDB روی سروری خارج از PVM اجرا شود، کارفرما باید Physical Network و VLAN اختصاصی دیتابیس را در اختیار تیم پیاده‌سازی قرار دهد.

در این حالت، ارتباط بین PVM و سرور MongoDB از طریق شبکه فیزیکی و VLAN اختصاصی دیتابیس برقرار خواهد شد.

در صورتی که امکان ارائه Physical Port اختصاصی وجود نداشته باشد، شبکه دیتابیس روی VLAN اختصاصی ارائه‌شده توسط کارفرما پیاده‌سازی می‌شود.

در صورت عدم امکان ارائه VLAN اختصاصی، از VXLAN استفاده خواهد شد.

MongoDB روی Host اصلی PVM

در صورتی که MongoDB به‌صورت Single Node روی Host اصلی PVM مستقر باشد، نیازی به اختصاص Physical Network مجزا برای دیتابیس وجود ندارد.

در این سناریو، ارتباط MongoDB با سایر سرویس‌های موردنیاز از طریق شبکه داخلی مجازی‌سازی برقرار شده و یک Host-Only Network برای ارتباط داخلی در نظر گرفته می‌شود.

در این حالت، ترافیک دیتابیس از شبکه فیزیکی مستقل عبور نمی‌کند و ارتباط در لایه مجازی‌سازی PVM انجام می‌شود.

---

ترتیب تأمین شبکه دیتابیس به شرح زیر است:

1. Physical Port اختصاصی + Database VLAN

در حالت ایده‌آل، کارفرما باید یک Physical Port اختصاصی از سرورهای PVM را به شبکه دیتابیس اختصاص دهد. این پورت باید در VLAN اختصاصی دیتابیس قرار داشته باشد.

در این حالت:

• پورت فیزیکی اختصاص‌یافته برای ترافیک دیتابیس از سایر ترافیک‌های شبکه تفکیک می‌شود.
• VLAN اختصاصی دیتابیس توسط کارفرما ارائه می‌شود.
• ارتباط Nodeهای PVM با MongoDB از طریق این شبکه برقرار می‌شود.
• در این معماری، هم Physical Isolation و هم Logical Isolation برقرار است.

2. Database VLAN روی کارت شبکه موجود

در صورتی که امکان اختصاص یک Physical Port مجزا به شبکه دیتابیس وجود نداشته باشد، کارفرما باید VLAN اختصاصی دیتابیس را روی یکی از کارت‌های شبکه موجود سرورهای PVM ارائه کند.

در این حالت، زیرساخت فیزیکی شبکه می‌تواند با سایر ترافیک‌ها مشترک باشد و جداسازی شبکه دیتابیس در سطح Logical و از طریق VLAN انجام می‌شود.

کارفرما باید مشخص کند که:

• VLAN مربوط به دیتابیس چیست.
• این VLAN روی کدام Physical NIC سرورهای PVM ارائه شده است.
• پورت مربوطه قابلیت عبور ترافیک VLAN موردنظر را دارد.
• در صورت استفاده از Trunk، VLAN دیتابیس روی Trunk مربوطه مجاز باشد.
• مسیر ارتباطی Nodeهای PVM با MongoDB برای VLAN دیتابیس مشخص باشد.

3. VXLAN

در صورتی که کارفرما امکان ارائه Physical Port اختصاصی و همچنین Database VLAN را نداشته باشد، شبکه دیتابیس باید با استفاده از VXLAN پیاده‌سازی شود.

در این معماری، شبکه دیتابیس به‌صورت Overlay روی زیرساخت موجود ایجاد شده و ارتباط Nodeهای PVM با MongoDB از طریق VXLAN برقرار می‌شود.

جزئیات طراحی و پیاده‌سازی VXLAN، شامل Underlay Network، VTEP، VNI، MTU و الزامات Routing و Firewall، در ادامه این مستند ارائه خواهد شد.

نکته: هدف اصلی این طراحی، ایجاد حداکثر سطح ایزولاسیون شبکه برای ترافیک دیتابیس و جلوگیری از اختلاط آن با ترافیک Management و سایر شبکه‌های زیرساخت و برقراری امنیت برای دیتای سازمان است.

سناریوهای استقرار MongoDB و الزامات ارتباطی PVM

این مستند، سناریوهای مختلف استقرار MongoDB در زیرساخت PVM و الزامات شبکه‌ای موردنیاز برای برقراری ارتباط بین PVM و MongoDB را تشریح می‌کند.

ساختار سناریوها بر اساس سه معیار اصلی تعریف شده است:

• محل استقرار MongoDB: داخل یا خارج از PVM
• نوع استقرار PVM: Cluster یا Single Node
• روش تأمین شبکه: NIC اختصاصی، VLAN اختصاصی یا VXLAN

---

ساختار درختی سناریوها

MongoDB
│
├── MongoDB خارج از PVM
│   │
│   ├── PVM Cluster
│   │   │
│   │   ├── NIC اختصاصی + VLAN اختصاصی
│   │   ├── NIC مشترک + VLAN اختصاصی + Trunk
│   │   └── NIC مشترک + VXLAN
│   │
│   └── PVM Single Node
│       │
│       ├── NIC اختصاصی + VLAN اختصاصی
│       ├── NIC مشترک + VLAN اختصاصی + Trunk
│       └── NIC مشترک + VXLAN
│
└── MongoDB داخل PVM
    │
    ├── PVM Cluster
    │   │
    │   ├── NIC اختصاصی + VLAN اختصاصی
    │   ├── NIC مشترک + VLAN اختصاصی + Trunk
    │   └── NIC مشترک + VXLAN
    │
    └── PVM Single Node
        │
        └── Host-Only

---

MongoDB خارج از PVM

در این سناریو، ماشین مجازی یا سرور MongoDB خارج از زیرساخت PVM قرار دارد.

بنابراین، صرف‌نظر از اینکه PVM به‌صورت Cluster یا Single Node پیاده‌سازی شده باشد، وجود یک مسیر شبکه‌ای بین PVM و MongoDB الزامی است.

---

PVM Cluster

در معماری Cluster، چندین Node از PVM در زیرساخت وجود دارد و MongoDB خارج از PVM مستقر شده است.

در این حالت، صرفاً برقراری ارتباط یک Node با MongoDB کافی نیست؛ بلکه تمامی Nodeهایی که سرویس‌های PVM متکی به MongoDB روی آن‌ها اجرا می‌شوند باید امکان دسترسی به MongoDB را داشته باشند.

الزامات عمومی ارتباطی Cluster

برای برقراری صحیح ارتباط در معماری Cluster، موارد زیر باید برقرار باشد:

• تمامی Nodeهای PVM باید به IP مربوط به MongoDB دسترسی داشته باشند.
• مسیر شبکه بین هر Node PVM و MongoDB باید برقرار باشد.
• در صورت وجود چند Node در MongoDB، ارتباط شبکه‌ای موردنیاز بین Nodeهای MongoDB باید برقرار باشد.
• تمامی Nodeهای PVM باید بتوانند به Port سرویس MongoDB متصل شوند.
• در صورت وجود Firewall بین PVM و MongoDB باید Rule های لازم برای ارتباط باید روی Firewall اعمال شوند.
• Routing بین Subnet مربوط به PVM و Subnet مربوط به MongoDB باید برقرار باشد.
• در صورت استفاده از DNS برای اتصال به MongoDB، تمامی Nodeهای PVM باید امکان Resolve کردن نام MongoDB را داشته باشند.
• IP Address مربوط به شبکه MongoDB باید روی Interface صحیح در هر Node PVM قابل دسترسی باشد.
• تنظیمات Network و MTU در تمامی Nodeها باید با معماری انتخاب‌شده سازگار باشد.

---

NIC اختصاصی + VLAN اختصاصی

در این روش، برای ترافیک MongoDB یک NIC فیزیکی اختصاصی روی هر Node موردنیاز PVM در نظر گرفته می‌شود و این NIC به VLAN اختصاصی MongoDB متصل خواهد شد.

در نتیجه، ترافیک MongoDB از ترافیک سایر شبکه‌های PVM جدا می‌شود.

الزامات زیرساختی

• اختصاص حداقل یک NIC فیزیکی مجزا به هر Node PVM که نیازمند ارتباط با MongoDB است.
• اختصاص یک VLAN مشخص و اختصاصی برای شبکه MongoDB.
• اتصال NIC مربوط به MongoDB به شبکه/VLAN اختصاصی دیتابیس.
• اختصاص Subnet و IP Address مشخص برای شبکه MongoDB.
• ایجاد Interface شبکه مربوط به MongoDB روی هر Node PVM.
• اطمینان از Unique بودن IP Addressها.
• برقراری Routing موردنیاز در صورت متفاوت بودن Subnetها.

الزامات ارتباطی Cluster

Database Network Topology

VLAN-DB • L2

L2 Link

NIC Port

DB Tier

VLAN Segment

3 Nodes → Switch (Access) → MongoDB

بنابراین:

PVM Node 1 ──► MongoDB
PVM Node 2 ──► MongoDB
PVM Node 3 ──► MongoDB

باید به‌صورت مستقل قابل برقراری باشد.

در صورتی که MongoDB شامل چند Node باشد:

MongoDB Node 1 ◄──► MongoDB Node 2
       ▲                  ▲
       │
       └──── MongoDB Node 3

ارتباط داخلی موردنیاز MongoDB نیز باید برقرار باشد.

در این سناریو هم میتوان به صورت جدا یک سوئیچ مرتبط به دیتابیس استفاده کرد و هم مستقیم از سوئیچ مرکزی به دیتابیس هدایت شود.

نحوه استقرار

مرحله ۱ — آماده‌سازی سمت سوئیچ فیزیکی:

باید روی سوئیچ فیزیکی، پورت سرورهارا به صورت Access روی VLAN مورد نظر (مثلاً VLAN 200) تنظیم کنیم و کابل شبکه آن را به مثلا NIC سوم سرورهای کلاستر PVM متصل کنیم.

مرحله ۲ — ساخت Bridge/VSwitch اختصاصی در PVM:

روی نود مستر PVM، یک Linux Bridge/OVS جدید (مثلاً MongoDB-Traffic) می‌سازیم و آن را به NIC فیزیکی سوم (eno3) متصل می‌کنیم. این Bridge/VSwitch هیچ IP ندارد روی خود هاست PVM — فقط ماشین‌های مجازی از آن استفاده می‌کنند.

مرحله ۳ — اتصال vNIC ماشین‌های مجازی MongoDB:

هر ماشین مجازی MongoDB یک vNIC روی MongoDB-Traffic دریافت می‌کند. IP آدرس از رنج اختصاصی شبکه دیتابیس (مثلاً 172.16.50.0/24) به این vNIC تخصیص می‌یابد.

مرحله ۴ — پیکربندی MongoDB Bind:

MongoDB را طوری تنظیم می‌کنیم که فقط روی IP مربوط به شبکه دیتابیس Listen کند — نه روی IP شبکه Management.

🔧 از دید فنی: در این سناریو چون پورت سوئیچ Access است، فریم‌های خروجی از سرور بدون تگ VLAN ارسال می‌شوند. سوئیچ خودش تگ VLAN 200 را اضافه می‌کند. بنابراین نیازی به تنظیم VLAN Tagging در PVM نیست. Bridge ساده و Untagged کافی است.

مزایا

• ایزولیشن فیزیکی کامل: ترافیک دیتابیس از کابل و پورت کاملاً مجزا عبور می‌کند
• عدم اشتراک پهنای باند: NIC دیتابیس با هیچ ترافیک دیگری رقابت ندارد
• سادگی پیکربندی: نیاز به VLAN Tagging یا Trunk در PVM نیست
• امنیت بالا: حتی در صورت نفوذ به شبکه Management، دسترسی مستقیم به شبکه دیتابیس وجود ندارد
• عملکرد بهینه: کمترین Latency و بیشترین Throughput برای Replication

الزامات Firewall

Firewall باید حداقل موارد زیر را پوشش دهد:

مبدأ	مقصد	سرویس	وضعیت
تمام PVM Nodeها	MongoDB	MongoDB Port	Allow
MongoDB Nodeها	MongoDB Nodeها	MongoDB Internal Traffic	Allow، در صورت نیاز

---

NIC مشترک + VLAN اختصاصی + Trunk

در این روش، به دلیل نبود NIC فیزیکی آزاد، ترافیک MongoDB از همان NIC موجود سرور PVM عبور می‌کند.

برای جداسازی ترافیک، یک VLAN اختصاصی برای MongoDB ایجاد شده و Port متصل به PVM به‌صورت 802.1Q Trunk پیکربندی می‌شود.

الزامات زیرساختی

• وجود یک NIC مشترک روی هر Node PVM.
• ایجاد VLAN اختصاصی MongoDB.
• پیکربندی Port Switch به‌صورت 802.1Q Trunk.
• عبور VLAN مربوط به MongoDB از Trunk.
• ایجاد VLAN Interface روی هر Node PVM.
• اختصاص IP Address به VLAN Interface.
• اختصاص Subnet مشخص برای شبکه MongoDB.
• اطمینان از عبور VLAN موردنظر در تمام مسیر شبکه.
• برقراری Routing در صورت نیاز.

معماری

Trunk-Based VLAN Segmentation

Trunk Port • 802.1Q

Trunk (Tagged)

Access Link

PVM VLANs

DB VLAN

NIC → Trunk → {VLANs} → MongoDB

الزامات Cluster

در معماری Cluster، VLAN مربوط به MongoDB باید روی تمام Nodeهایی که نیاز به دسترسی به MongoDB دارند قابل دسترسی باشد.

به عبارت دیگر، وجود VLAN روی یک Node کافی نیست.

Node 1 ──┐
Node 2 ──┼── VLAN-DB ── MongoDB
Node 3 ──┘

تمام Nodeها باید:

• VLAN Interface مربوط به MongoDB داشته باشند.
• IP معتبر در Subnet MongoDB داشته باشند.
• MongoDB را Ping/Reach کنند، در صورت مجاز بودن ICMP.
• بتوانند به Port سرویس MongoDB متصل شوند.
• در صورت استفاده از DNS، نام MongoDB را Resolve کنند.

نحوه استقرار

مرحله ۱ — تنظیم Trunk:

ما یک کارت شبکه را برای عبور ترافیک ماشین‌های مجازی روی VLAN 300 در نظر گرفته‌ایم.

برای عبور هم‌زمان ترافیک دیتابیس، پورت سوئیچ متصل به NIC3 سرور را از حالت Access به Trunk تغییر می‌دهیم و VLAN 200 (ترافیک دیتابیس) را به لیست Allowed VLANs اضافه می‌کنیم. VLAN 300 نیز همچنان به‌عنوان VLAN ترافیک عمومی ماشین‌های مجازی باقی خواهد ماند.

در نتیجه، هر دو VLAN 300 و VLAN 200 از طریق یک کارت شبکه و روی یک لینک Trunk عبور داده می‌شوند. به این ترتیب، با استفاده از تفکیک منطقی ترافیک بر بستر VLAN، نبود یک کارت شبکه فیزیکی مستقل برای MongoDB جبران خواهد شد.

مرحله ۲ — ساخت VLAN Interface در PVM:

روی نود PVM، باید Uplink-OVS را روی ترانک قرار دهیم و ویلن های 200 و 300 را allow کنیم. سپس برای هر ویلن یک کانفیگ جدا اضافه میکنیم.

مرحله ۳ — تخصیص پورت خروجی به OVS: باید کانفیک Uplink را که Trunk تنظیم کردیم روی کارت شبکه خروجی مثلا NIC3 تنظیم کنیم.

مرحله ۴ — تخصیص vNIC به ماشین‌های مجازی MongoDB:

ماشین مجازی MongoDB باید vNIC مربوط به کانفیگ OVS ویلن خودش را دریافت کند. ماشین مجازی های دیگر باید vNIC مربوط به ویلن خودشان را دریافت کنند.

نکته حیاتی: چرا از NIC Management ترانک نمی‌کنیم؟

بیایید سناریو را تصور کنیم:

اگر از NIC1 (Management) ترانک کنیم:

• ترافیک مانگو (که می‌تواند صدها مگابیت بر ثانیه باشد) با ترافیک مدیریتی PVM روی یک لینک فیزیکی به اشتراک گذاشته می‌شود
• در ساعات اوج بار دیتابیس، پهنای باند لینک اشباع می‌شود
• دسترسی به Web UI و SSH سرور PVM قطع یا بسیار کند می‌شود
• ارتباط Cluster بین نودهای PVM (Corosync) مختل شده و ممکن است Fencing اتفاق بیفتد
• عملاً کنترل زیرساخت را از دست می‌دهیم

بنابراین قانون طلایی: ترافیک دیتابیس همیشه از NIC مخصوص ترافیک ماشین‌های مجازی (NIC2 یا 3) رد شود — نه از NIC مدیریتی.

مزایا و محدودیت‌ها

مزایا:

• نیاز به پورت فیزیکی اضافه نیست
• ایزولیشن منطقی (Logical) در سطح لایه ۲ توسط VLAN
• سادگی نسبی در پیکربندی

محدودیت‌ها:

• اشتراک پهنای باند فیزیکی NIC2 بین ترافیک عمومی VM و ترافیک دیتابیس
• در صورت اشباع لینک، عملکرد دیتابیس تحت تأثیر قرار می‌گیرد
• وابستگی به پیکربندی Trunk روی سوئیچ فیزیکی

---

NIC مشترک + VXLAN

طبق شرایط زیرساخت شبکه نه VLAN اختصاصی داریم و نه پورت فیزیکی جدا. تنها منابع موجود همان NICهای فعلی سرور با شبکه فعلی هستند. در این حالت باید خودمان شبکه Overlay بسازیم.

💡 به زبان ساده: تصور کنید نه جاده اختصاصی دارید و نه خط ویژه. اما می‌توانید بسته‌های دیتابیسی را داخل بسته‌بندی دیگری قرار دهید (مثل پاکت داخل پاکت) و از همان جاده عمومی بفرستید. دریافت‌کننده بسته بیرونی را باز می‌کند و بسته اصلی دیتابیس را استخراج می‌کند. این دقیقاً کار VXLAN است.

🔧 از دید فنی: VXLAN (Virtual Extensible LAN) یک پروتکل Overlay لایه ۲ روی لایه ۳ است. فریم‌های اترنت شبکه دیتابیس داخل بسته‌های UDP/IP کپسوله شده و از شبکه Underlay (شبکه ترافیک VM) عبور می‌کنند. هر نود PVM یک VTEP (VXLAN Tunnel Endpoint) می‌شود. ترافیک VXLAN از پورت UDP/4789 استفاده می‌کند. از آنجا که VXLAN روی لایه ۳ کار می‌کند، نیازی به VLAN یا تغییر سوئیچ نیست — فقط کافی است نودهای PVM در سطح IP به هم دسترسی داشته باشند.

نکته مهم: تونل VXLAN باید از IP شبکه ترافیک ماشین‌ها ساخته شود — نه از IP شبکه Management. دلیل آن مشابه سناریوی دوم است: ترافیک سنگین دیتابیس نباید از لینک Management عبور کند.VXLAN Overlay Network* روی شبکه موجود ایجاد می‌شود تا یک شبکه منطقی مجزا برای ارتباط MongoDB ایجاد شود.

معماری

VXLAN Overlay Architecture

L2 Over L3 • UDP 4789

Underlay (L3)

VXLAN Overlay (L2 Tunnel)

VTEP Interface

VTEP (PVM) ══ Overlay Tunnel ══ VTEP (MongoDB)

الزامات زیرساختی

• وجود یک IP Underlay Network پایدار بین Endpointهای VXLAN.
• دسترسی IP بین VXLAN Endpointها.
• اختصاص VNI مشخص برای شبکه MongoDB.
• ایجاد VXLAN Interface روی Nodeهای موردنیاز.
• اختصاص IP Address به Overlay Network.
• یکسان بودن تنظیمات VXLAN در Endpointهای مربوطه.
• اطمینان از سازگاری MTU در کل مسیر.
• فراهم بودن امکان عبور ترافیک موردنیاز VXLAN در شبکه Underlay.
• جلوگیری از Fragmentation در مسیر، در صورت امکان.
• برقراری Routing موردنیاز برای شبکه Overlay.

نحوه استقرار VXLAN

مرحله ۱ — اطمینان از ارتباط لایه ۳ بین نودها روی شبکه VM Traffic:

قبل از هر کار، باید مطمئن شویم نودهای PVM از طریق IP شبکه VM Traffic (مثلاً 192.168.10.1 و 192.168.10.2) به هم دسترسی دارند. این IP ممکن است روی vmbr1 یا مستقیماً روی NIC2 یا 3 تنظیم شده باشد.

مرحله ۲ — ساخت VXLAN Interface روی هر نود:

روی هر نود PVM یک VXLAN Interface با VNI مشخص (مثلاً 5000) ایجاد می‌کنیم. این Interface باید از IP شبکه VM Traffic به عنوان Local VTEP استفاده کند و Remote VTEP آن IP نود مقابل (روی شبکه VM Traffic) باشد.

مرحله ۳ — ساخت Bridge/vSwitch اختصاصی دیتابیس:

یک Bridge/vSwitch جدید می‌سازیم و VXLAN Interface را به آن متصل می‌کنیم. این Bridge/vSwitch شبکه Overlay دیتابیس را فراهم می‌کند. در این مرحله بدون OVS فقط با ساخت Bridge کفایت میکند.

مرحله ۴ — اتصال ماشین‌های مجازی MongoDB:

هر VM مربوط به MongoDB یک vNIC دریافت می‌کند و IP روی آن تنظیم می‌کنیم. روی Bridge که ساختیم باید در همان رنج آیپی روی هر نود تنظیم گردد.

مرحله ۵ — تنظیم MTU:

چون VXLAN هدر اضافی (50 بایت) به بسته‌ها اضافه می‌کند، باید MTU شبکه Underlay حداقل 1550 (ترجیحاً 9000 برای Jumbo Frame) تنظیم شود. در غیر این صورت بسته‌های بزرگ قطعه‌قطعه (Fragment) شده و عملکرد افت می‌کند.

چرا VTEP از IP شبکه VM Traffic ساخته می‌شود؟

دقیقاً مشابه منطق سناریوی دوم:

• ترافیک کپسوله‌شده VXLAN شامل داده‌های Replication مانگو است و می‌تواند بسیار سنگین باشد
• اگر VTEP از IP شبکه Management ساخته شود، تمام این ترافیک از NIC1 عبور می‌کند
• اشباع NIC1 یعنی قطع دسترسی به PVM Web UI و مختل شدن Corosync Cluster
• با استفاده از IP شبکه VM Traffic، ترافیک VXLAN از NIC2 عبور می‌کند و NIC1 فقط برای مدیریت آزاد می‌ماند

مزایا و محدودیت‌های سناریوی سوم

مزایا:

• هیچ وابستگی به تغییر شبکه ندارد: نیاز به VLAN یا پورت اضافه نیست
• استقلال کامل تیم دیتابیس: بدون نیاز به هماهنگی با تیم شبکه سازمان
• مقیاس‌پذیری: با اضافه کردن نود جدید، فقط VTEP جدید اضافه می‌شود
• انعطاف‌پذیری: حتی اگر نودها در ساب‌نت‌های مختلف باشند، VXLAN کار می‌کند (فقط Routing لایه ۳ لازم است)

محدودیت‌ها:

• Overhead شبکه: هدر VXLAN حدود 50 بایت به هر بسته اضافه می‌کند
• پیچیدگی عیب‌یابی: مشکلات شبکه در لایه Overlay سخت‌تر ردیابی می‌شوند
• نیاز به تنظیم MTU: بدون Jumbo Frame ممکن است فرگمنتیشن رخ دهد
• مصرف CPU: کپسوله‌سازی و استخراج VXLAN مقداری بار CPU روی هاست ایجاد می‌کند
• اشتراک پهنای باند NIC2: مشابه سناریوی دوم، ترافیک Overlay با ترافیک عمومی VM از یک لینک فیزیکی عبور می‌کند

الزامات Cluster

در Cluster باید VXLAN روی تمام Nodeهایی که نیاز به دسترسی به MongoDB دارند برقرار باشد.

PVM Node 1 ── VXLAN ──┐
PVM Node 2 ── VXLAN ──┼── MongoDB
PVM Node 3 ── VXLAN ──┘

همچنین در صورت وجود چند Node در MongoDB، ارتباط موردنیاز بین Nodeهای MongoDB نیز باید روی شبکه مناسب برقرار باشد.

PVM Single Node

در این معماری تنها یک Node PVM وجود دارد و MongoDB خارج از Host PVM قرار گرفته است.

از آنجا که MongoDB خارج از Host قرار دارد، ارتباط شبکه‌ای همچنان الزامی است.

سه روش زیر قابل استفاده است:

• NIC اختصاصی + VLAN اختصاصی
• NIC مشترک + VLAN اختصاصی + Trunk
• NIC مشترک + VXLAN

نحوه پیاده سازی هر سناریو با حالت کلاستر یکسان هست, اما این شرایط به صورت تک سرور ارائه میشود. به همین دلیل توضیح اضافه برای معماری شبکه داده نمیشود, زیرا با مراحل بالا یکسان هست.

الزامات ارتباطی

در حالت Single Node، تنها همان Node PVM باید به MongoDB دسترسی داشته باشد.

بنابراین برخلاف Cluster، نیازی به ایجاد ارتباط MongoDB برای چندین Node PVM وجود ندارد.

با این حال، موارد زیر باید برقرار باشد:

• مسیر شبکه بین PVM و MongoDB
• IP Address مناسب
• Routing در صورت نیاز
• دسترسی به Port سرویس MongoDB
• Ruleهای Firewall موردنیاز
• DNS Resolution در صورت استفاده از نام دامنه
• در صورت استفاده از Replica Set، ارتباط موردنیاز بین Nodeهای MongoDB

MongoDB داخل PVM

در این سناریو، ماشین مجازی MongoDB روی زیرساخت PVM اجرا می‌شود.

با توجه به نوع استقرار PVM، دو حالت وجود دارد:

• PVM Cluster
• PVM Single Node

PVM Cluster

در این حالت، MongoDB به‌صورت ماشین مجازی روی زیرساخت PVM اجرا شده است و چندین Node PVM در Cluster وجود دارند.

با وجود اینکه MongoDB داخل زیرساخت PVM قرار دارد، در معماری Cluster همچنان باید شبکه موردنیاز برای ارتباط بین Nodeهای PVM و ماشین MongoDB طراحی شود.

سه روش شبکه‌ای قابل استفاده است:

• NIC اختصاصی + VLAN اختصاصی
• NIC مشترک + VLAN اختصاصی + Trunk
• NIC مشترک + VXLAN

الزامات ارتباطی Cluster

Star Topology — VM Hosted on Node

Network VLAN • L2 Access

VLAN Access Link

Physical NIC

Hosted VM

Empty Slot

Switch → 3× NIC → PVM Nodes (MongoDB on Node 1)

توضیحات معماری

طبق معماری نمایش‌داده‌شده، ماشین مجازی MongoDB بر روی Node اول کلاستر PVM مستقر و اجرا شده است.

سایر Nodeهای کلاستر (Node 2 و Node 3) برای دسترسی به سرویس MongoDB، از طریق شبکه کلاستر و سوئیچ فیزیکی به Node اول متصل می‌شوند؛ زیرا ماشین مجازی MongoDB در این Node میزبانی می‌شود.

در این معماری:

• PVM Node 1 به‌عنوان Host میزبان ماشین مجازی MongoDB عمل می‌کند.
• PVM Node 2 و PVM Node 3 از طریق مسیر شبکه به MongoDB VM دسترسی دارند.
• ارتباط بین Nodeهای کلاستر از طریق Physical Switch و شبکه تعریف‌شده (مانند VLAN اختصاصی دیتابیس) برقرار می‌شود.
• دسترسی به MongoDB وابسته به برقراری ارتباط شبکه‌ای بین تمامی Nodeهای کلاستر و Node میزبان MongoDB VM است.

در نتیجه، تمامی Nodeهای کلاستر باید امکان دسترسی شبکه‌ای به PVM Node 1 و سرویس MongoDB اجراشده روی آن را داشته باشند.

در این معماری باید مشخص شود که: تمام Nodeهای موردنیاز PVM باید به MongoDB VM دسترسی داشته باشند.

الزامات اصلی

• دسترسی تمام Nodeهای PVM به MongoDB VM
• اختصاص IP Address مناسب
• برقراری Routing در صورت نیاز
• باز بودن Port سرویس MongoDB
• باز بودن Portهای موردنیاز ارتباط داخلی MongoDB
• پیکربندی صحیح Firewall
• سازگاری MTU در صورت استفاده از Overlay Network
• در صورت استفاده از DNS، امکان Resolve نام‌ها از تمامی Nodeهای موردنیاز

PVM Single Node

در این حالت، هم PVM و هم ماشین مجازی MongoDB روی یک Host فیزیکی قرار دارند.

به دلیل قرارگیری هر دو ماشین روی یک Host، نیازی به ایجاد شبکه فیزیکی مجزا برای ارتباط PVM و MongoDB وجود ندارد.

ارتباط می‌تواند از طریق یک Host-Only Network برقرار شود.

الزامات ارتباطی

• ایجاد یک Host-Only Network بین PVM و MongoDB VM
• اختصاص IP Address به PVM در شبکه Host-Only
• اختصاص IP Address به MongoDB VM در همان شبکه
• قرارگیری دو Interface در یک Subnet
• برقراری ارتباط IP بین PVM و MongoDB VM
• باز بودن Port سرویس MongoDB
• عدم نیاز به NIC فیزیکی اختصاصی
• عدم نیاز به VLAN اختصاصی
• عدم نیاز به Trunk
• عدم نیاز به VXLAN

نکته: در این معماری، Host-Only صرفاً برای ارتباط داخلی بین PVM و MongoDB VM استفاده می‌شود و ارتباط MongoDB با شبکه خارجی، در صورت نیاز، باید به‌صورت مستقل طراحی شود.

---

اولویت پیشنهادی روش‌های شبکه

در صورت وجود امکان انتخاب، روش‌های زیر به‌ترتیب اولویت پیشنهاد می‌شوند:

NIC اختصاصی + VLAN اختصاصی بهترین گزینه از نظر جداسازی ترافیک، سادگی پیاده‌سازی و عیب‌یابی.

NIC مشترک + VLAN اختصاصی + Trunk گزینه مناسب در صورت نبود NIC فیزیکی اختصاصی.

NIC مشترک + VXLAN راهکار مناسب در شرایطی که امکان ارائه NIC یا VLAN اختصاصی وجود ندارد و نیاز به ایجاد شبکه Overlay است.

Host-Only مختص سناریوی MongoDB داخل PVM + Single Node است؛ زیرا PVM و MongoDB روی یک Host قرار دارند.

اصل طلایی: جداسازی ترافیک Management از ترافیک دیتابیس

این بخش مهم‌ترین قانون معماری شبکه در استقرار MongoDB روی PVM است و در هر سه سناریو صدق می‌کند.

اشتباه

NIC1 — Management

PVM Web UI + SSH

Corosync Cluster

• ترافیک MongoDB Replication

اشباع لینک = قطع مدیریت

صحیح

NIC1 — Management

فقط: PVM Web UI + SSH

فقط: Corosync Cluster

NIC2 — VM Traffic

ترافیک ماشین‌ها

• ترافیک MongoDB (VLAN/VXLAN)

مسیر تصمیم‌گیری — کدام سناریو را انتخاب کنیم؟

آیا کارفرما پورت فیزیکی اختصاصی با VLAN می‌دهد؟

بله

سناریوی ۱

پورت فیزیکی + VLAN Access

بهترین عملکرد و امنیت

خیر

آیا VLAN (بدون پورت فیزیکی) می‌دهد؟

بله

سناریوی ۲

Trunk + VLAN Tag

خیر

سناریوی ۳

VXLAN Overlay

---

خلاصه نهایی

استقرار MongoDB روی PVM در محیط سازمانی، بیش از آنکه چالش نرم‌افزاری باشد، چالش معماری شبکه است. انتخاب صحیح بین سه سناریوی پورت فیزیکی، Trunk VLAN و VXLAN Overlay بستگی به سطح همکاری کارفرما و زیرساخت موجود دارد.

در هر سه سناریو، یک اصل تغییرناپذیر وجود دارد:

🔧 ترافیک دیتابیس MongoDB هرگز نباید از شبکه Management سرورهای PVM عبور کند. همیشه از شبکه ترافیک ماشین‌های مجازی (NIC2) استفاده کنید — چه به صورت VLAN، چه Trunk، و چه VXLAN.