پیوندها در آزمایشگاههای مجازی «وبلاگ ippace.net

سه روش اصلی برای اتصال دستگاه های شبکه در دنیای فیزیکی وجود دارد:

• پیوندها از نقطه ای به نقطه بین دستگاه ها (معمولاً با استفاده از برخی از انواع اترنت)
• شبکه هایی با دسترسی زیاد به Layer-1 ، کار با برخی از محاصره IEEE 802.x در بالا (GPON ، WiFi ، Hubs اترنت)
• دسترسی زیادی به دسترسی به Layer-2 (سوئیچ های گنگ ، امیدواریم که نوع STP را شروع کنید)

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

تصویر بزرگ

هر راه حل مجازی سازی من تاکنون دیده ام (VMware ESX ، Hyper-V ، KVM ، ظروف Docker) ماشین های مجازی یا ظروف را به مجازی وصل کنید پل سوئیچ:

او NIC مجازی در نمودار بالا لزوماً رابط نیست. نرم افزار مجازی سازی وادار کردن NIC یا سخت افزار مجازی I/O ^{برای ایجاد دستگاه مجازی ، این تصور را که رابط اترنت وجود دارد ، ایجاد می کند:}

شبکه های KVM/libvirt از پل های لینوکس استفاده می کنند

اگرچه درک آنچه در پشت صحنه در VMware ESXI اتفاق می افتد دشوار است ، اما کشف شبکه مجازی لینوکس بسیار مهم است. بیایید یک توپولوژی NetLab بسیار ساده با دو میزبان متصل به یک بخش مشترک ایجاد کنیم:

توپولوژی NetLab برای ایجاد یک بخش libvirt استفاده می شود

nodes:
  h1:
    device: linux
  h2:
    device: linux

links: [ h1-h2 ]

باکله به Vagrant می گوید که باید H1 و H2 را با a متصل کند لیبرو شبکه های خصوصی و برادر -در تماس های LAW لیبرو برای ایجاد شبکه (X_1):

شبکه های مجازی پس از راه اندازی آزمایشگاه libvirt

$ virsh net-list
 Name              State    Autostart   Persistent
----------------------------------------------------
 default           active   yes         yes
 vagrant-libvirt   active   no          yes
 X_1               active   yes         yes

شبکه X_1 از آن استفاده می کند virbr1 پل لینوکس:

پل لینوکس را که توسط یک شبکه مجازی Libvirt استفاده می شود پیدا کنید

$ virsh net-info X_1
Name:           X_1
UUID:           2994e8b1-b69b-4eaf-8801-d5fe1302ff65
Active:         yes
Persistent:     yes
Autostart:      yes
Bridge:         virbr1

دو رابط (یکی در هر VM) وجود دارد virbr1 پل 🙂

رابط های متصل به پل لینوکس را پیدا کنید

$ brctl show virbr1
bridge name	bridge id		STP enabled	interfaces
virbr1		8000.525400f97191	no		vgif_h1_1
							vgif_h2_1

دو رابط هستند روی رابط ها ضربه بزنید – رابط های ویژه ای که به نرم افزار مجازی سازی اجازه می دهد بسته های ارسال شده برای آنها را ضبط کرده و آنها را در دستگاه مجازی وارد کنید. با این حال ، هیچ رابط لینوکس برای پیاده سازی رابط ماشین مجازی وجود ندارد (یک پین را در این فکر قرار دهید ؛ در پست وبلاگ بعدی به آن احتیاج خواهید داشت).

لمس کردن جزئیات رابط در خدمت یک ماشین مجازی

$ ip -d link show vgif_h1_1
33867: vgif_h1_1:  mtu 1500 qdisc noqueue master virbr1 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether fe:54:00:f5:27:fa brd ff:ff:ff:ff:ff:ff promiscuity 1 minmtu 68 maxmtu 65521
    tun type tap pi off vnet_hdr on persist off
    bridge_slave state forwarding priority 32 cost 100 hairpin off guard off root_block off fastleave off learning on flood on port_id 0x8002 port_no 0x2 designated_port 32770 designated_cost 0 designated_bridge 8000.52:54:0:f9:71:91 designated_root 8000.52:54:0:f9:71:91 hold_timer    0.00 message_age_timer    0.00 forward_delay_timer    0.00 topology_change_ack 0 config_pending 0 proxy_arp off proxy_arp_wifi off mcast_router 1 mcast_fast_leave off mcast_flood on mcast_to_unicast off neigh_suppress off group_fwd_mask 0 group_fwd_mask_str 0x0 vlan_tunnel off isolated off addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

اتصال ظروف به پل های لینوکس

راه حل های ارکستراسیون کانتینر از یک رویکرد کمی متفاوت استفاده می کند. رابط های کانتینر رابط های لینوکس هستند در یک فضای شبکه متفاوت از اسامیحرف این امر اتصال آنها به پل لینوکس را غیرممکن می کند. برای وصل کردن یک ظرف به پل لینوکس ، باید:

• ایجاد جفت رابط های اترنت مجازی مرتبط با کابل مجازی (جفت VETH)
• یکی از رابط های VETH را به پل لینوکس وصل کنید (استاد لینوکس رابط VETH را بسازید)
• رابط دیگر VETH را به نام کانتینر مهاجرت کنید و آن را تغییر نام دهید اسیحرف

بیایید کمی بزرگتر شروع کنیم ^{توپولوژی NetLab برای کشف آنچه در پشت صحنه اتفاق می افتد:}

توپولوژی NetLab برای ایجاد ظروف مرتبط با پل لینوکس استفاده می شود

provider: clab

nodes:
  h1:
    device: linux
  h2:
    device: linux
  h3:
    device: linux

links: [ h1-h2-h3 ]

پس از راه اندازی آزمایشگاه ، میزبان لینوکس ما دارای دو پل اضافی است-مدیریت آزمایشگاه و یک پلی از هواپیمای داده که سه ظرف را برای لینوکس وصل می کند:

پل های لینوکس پس از راه اندازی آزمایشگاه کانتینر

$ brctl show
bridge name	bridge id		STP enabled	interfaces
X_1		8000.363f459a1c59	no		h1_eth1
							h2_eth1
							h3_eth1
br-c16a1e42cdb8		8000.02424d2659f3	no		veth3a66ccf
							veth56c6b05
							vethfa4725c
docker0		8000.02429c2dee48	no
virbr0		8000.525400d00378	yes

هر رابط میزبان طرف “عمومی” زوج Veth است:

جزئیات رابط مرتبط با پل آزمایشگاهی برای داده های داده

$ ip -d link show h1_eth1
33876: h1_eth1@if33877:  mtu 9500 qdisc noqueue master X_1 state UP mode DEFAULT group default
    link/ether aa:c1:ab:f9:63:f8 brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 1 minmtu 68 maxmtu 65535
    veth
    bridge_slave state forwarding priority 32 cost 2 hairpin off guard off root_block off fastleave off learning on flood on port_id 0x8001 port_no 0x1 designated_port 32769 designated_cost 0 designated_bridge 8000.36:3f:45:9a:1c:59 designated_root 8000.36:3f:45:9a:1c:59 hold_timer    0.00 message_age_timer    0.00 forward_delay_timer    0.00 topology_change_ack 0 config_pending 0 proxy_arp off proxy_arp_wifi off mcast_router 1 mcast_fast_leave off mcast_flood on mcast_to_unicast off neigh_suppress off group_fwd_mask 0 group_fwd_mask_str 0x0 vlan_tunnel off isolated off addrgenmode eui64 numtxqueues 16 numrxqueues 16 gso_max_size 65536 gso_max_segs 65535

طرف دیگر جفت VETH در نام های کانتینر قابل مشاهده است:

طرف ظرف جفت

$ netlab connect h1
Connecting to container clab-X-h1, starting bash

h1:/# ip link
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
33872: eth0@if33873:  mtu 1500 qdisc noqueue state UP
    link/ether 02:42:c0:a8:79:65 brd ff:ff:ff:ff:ff:ff
33877: eth1@if33876:  mtu 1500 qdisc noqueue state UP
    link/ether aa:c1:ab:ac:d2:b5 brd ff:ff:ff:ff:ff:ff

به نام های رابط عجیب در اتصال IP چاپ:

• میزبان h1_eth1 با همراه است if33877
• کانتینر eth1 با همراه است if33876

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

آیا ما خوبیم که برویم؟

TL & DR: شماره

پل های لینوکس یک مشکل کوچک دارند: توسعه دهندگان لینوکس بیش از حد درباره پروتکل های شبکه می دانند^{حرف پل های لینوکس با اکراه برخی از پروتکل های مدیریتی Layer-2 را منتقل می کنند ، قاب های LACP را منتقل نمی کنند (شما نمی توانید بین دو دستگاه شبکه تاخیر ایجاد کنید) و STP را شروع کنید مگر اینکه در غیر این صورت پیکربندی شود.}

شما می توانید پل های لینوکس را با Vswitches باز جایگزین کنید (مجاز به ارسال چیزی به دنیای نرم افزار جدید جسورانه هستید) یا هک پیدا کنید که منجر به نقطه ای شود تا نقطه ای بین دو دستگاه مجازی یا ظرف پست وبلاگ بعدی باشد.

انتظار بعدی را داشته باشید: پیوندها از نقطه به نقطه در آزمایشگاههای مجازی