اوپن شفٹ ورچوئلائزیشن: کنٹینرز، کے وی ایم اور ورچوئل مشینیں۔

اوپن شفٹ ورچوئلائزیشن (اپ اسٹریم پروجیکٹ - کبرنیٹس: کوبی ورٹ، دیکھیں۔ یہاں и یہاں)، nee کنٹینر-آبائی ورچوئلائزیشن، کو اوپن شفٹ پلیٹ فارم کی فعالیت کے طور پر متعارف کرایا گیا تھا، جو کہ ورچوئل مشینوں (VMs) کو بنیادی Kubernetes اداروں کے طور پر تعینات کرنے اور ان کا انتظام کرنے کے لیے ڈیزائن کیا گیا ہے۔ ٹیکنالوجی میں بنیادی فرق کی وجہ سے اس قسم کا کام تکنیکی طور پر مشکل ہے۔ اس مقصد کو حاصل کرنے کے لیے، ہم نے Red Hat Enterprise Linux اور KVM پر مبنی جانی پہچانی ٹیکنالوجیز کا استعمال کیا، جو کئی سالوں سے ہمارے ساتھ ہیں اور اپنی تاثیر کو ثابت کر چکی ہیں۔

اس مضمون میں، ہم OpenShift ورچوئلائزیشن کے تکنیکی پہلوؤں پر غور کریں گے جو VMs اور کنٹینرز کے لیے ایک پلیٹ فارم کے اندر ایک ساتھ رہنا ممکن بناتے ہیں جو انہیں ایک واحد وجود کے طور پر منظم کرتا ہے۔

کمپیوٹیشنل کام

کنٹینرز عمل کو الگ تھلگ کرنے اور وسائل کو منظم کرنے کے لیے لینکس کرنل میکانزم جیسے نام کی جگہ اور cgroups کا استعمال کرتے ہیں۔ عام طور پر پروسیسز کو ازگر، جاوا ایپلی کیشنز یا ایگزیکیوٹیبل فائلز کے طور پر سمجھا جاتا ہے، لیکن درحقیقت وہ کوئی بھی پروسیس ہو سکتے ہیں، جیسے bash، Emacs یا vim۔

ورچوئل مشین کیا ہے؟ ہائپرائزر کے نقطہ نظر سے، یہ بھی ایک عمل ہے. لیکن درخواست کا عمل نہیں، بلکہ KVM عمل ایک مخصوص VM کو انجام دینے کے لیے ذمہ دار ہے۔

کنٹینر کی تصویر میں KVM ورچوئل مشین کے لیے درکار تمام ٹولز، لائبریریز اور فائلیں شامل ہیں۔ اگر ہم چلتے ہوئے VM کے پوڈ کا معائنہ کرتے ہیں، تو ہم وہاں مددگار اور qemu-kvm عمل دیکھیں گے۔ مزید برآں، ہمارے پاس ورچوئل مشینوں جیسے qemu-img، qemu-nbd اور virsh کے انتظام کے لیے KVM ٹولز تک رسائی ہے۔

چونکہ ایک ورچوئل مشین ایک پوڈ ہے، اس لیے یہ خود بخود Kubernetes میں پوڈ کی تمام فعالیت کو وراثت میں لے لیتی ہے۔ وی ایم پوڈز، ریگولر پوڈز کی طرح، شیڈیولر اسکیموں اور معیارات جیسے کہ داغدار، رواداری، وابستگی اور اینٹی وابستگی کے تابع ہیں۔ آپ کو زیادہ دستیابی وغیرہ کے فوائد بھی ملتے ہیں۔ تاہم، ایک اہم فرق ہے: عام پوڈز عام معنوں میں میزبان سے میزبان کی طرف منتقل نہیں ہوتے ہیں۔ اگر کوئی نوڈ آف لائن ہو جاتا ہے، تو اس پر موجود پوڈ کو ختم کر دیا جاتا ہے اور کلسٹر کے کسی دوسرے نوڈ کو دوبارہ تفویض کر دیا جاتا ہے۔ اور ورچوئل مشین کے معاملے میں، ہم لائیو ہجرت دیکھنے کی توقع رکھتے ہیں۔

اس خلا کو دور کرنے کے لیے، لائیو مائیگریشن میکانزم کو بیان کرنے کے لیے ایک کسٹم ریسورس ڈیفینیشن (سی ڈی آر) بنائی گئی تھی جو ورکر نوڈس کے درمیان VMs کی لائیو ہجرت کو شروع کرنے، نگرانی کرنے اور ان کے انتظام کے لیے ذمہ دار ہے۔

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
  name: migration-job
spec:
  vmiName: fedora

جب کوئی نوڈ غیر فعال ہو جاتا ہے، تو ان ورچوئل مشینوں کے لیے ہجرت کے کام خود بخود تخلیق ہو جاتے ہیں جن کی بے دخلی کی حکمت عملی کے طور پر لائیو مائیگریشن سیٹ ہوتی ہے۔ اس طرح آپ کلسٹر نوڈس کے درمیان حرکت کرتے وقت ورچوئل مشینوں کے رویے کو کنٹرول کر سکتے ہیں۔ آپ لائیو مائیگریشن کو کنفیگر کر سکتے ہیں اور VM کا نظم کر سکتے ہیں، دوسرے تمام پوڈز کی طرح۔

Сеть

کوئی بھی Kubernetes سسٹم سافٹ ویئر SDN نیٹ ورکس کا استعمال کرتے ہوئے نوڈس اور پوڈز کے درمیان مواصلت فراہم کرتا ہے۔ OpenShift کوئی مستثنیٰ نہیں ہے اور ورژن 3 سے شروع ہو کر اس کے لیے OpenShiftSDN بطور ڈیفالٹ استعمال کرتا ہے۔ اس کے علاوہ، OpenShift 4 میں Multus نامی ایک اور نئی خصوصیت ہے، جو آپ کو ایک سے زیادہ نیٹ ورکس کو دستیاب کرنے اور ان سے پوڈز کو بیک وقت منسلک کرنے کی اجازت دیتی ہے۔

ملٹس کا استعمال کرتے ہوئے، ایڈمنسٹریٹر اضافی CNI نیٹ ورکس کی وضاحت کر سکتا ہے، جو اس کے بعد ایک خصوصی کلسٹر نیٹ ورک آپریٹر کے ذریعے کلسٹر پر تعینات اور ترتیب دیا جائے گا۔ پوڈز پھر ان نیٹ ورکس میں سے ایک یا زیادہ سے جڑے ہوتے ہیں، عام طور پر معیاری OpenShiftSDN اور ایک اضافی انٹرفیس۔ SR-IOV آلات، معیاری لینکس برج، MACVLAN اور IPVLAN آلات سبھی استعمال کیے جا سکتے ہیں اگر آپ کے VM کو ضرورت ہو۔ نیچے دی گئی تصویر سے پتہ چلتا ہے کہ eth1 انٹرفیس پر برج نیٹ ورک کے لیے Multus CNI کیسے سیٹ کیا جائے:

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: multus1
rawCNIConfig: '{ "cniVersion": "0.3.1", "type": "bridge", "master": "eth1", "ipam":
   { "type": "static", "addresses": [ { "address": "191.168.1.1/24" } ] } }'
   type: Raw

OpenShift ورچوئلائزیشن کے سلسلے میں، اس کا مطلب ہے کہ SDN کو نظرانداز کرتے ہوئے، VM کو براہ راست بیرونی نیٹ ورک سے منسلک کیا جا سکتا ہے۔ یہ Red Hat Virtualization یا VMware vSphere سے OpenShift میں منتقل ہونے والی ورچوئل مشینوں کے لیے اہم ہے، کیونکہ اگر آپ کو دوسری OSI پرت تک رسائی حاصل ہے، تو نیٹ ورک کی ترتیبات میں کوئی تبدیلی نہیں ہوگی۔ اس کا مطلب یہ بھی ہے کہ VM میں ایک نیٹ ورک ایڈریس ہو سکتا ہے جو SDN کو نظرانداز کرتا ہے۔ اس طرح، ہم مؤثر طریقے سے خصوصی نیٹ ورک اڈاپٹر استعمال کر سکتے ہیں، یا نیٹ ورک پر سٹوریج سسٹم سے براہ راست جڑ سکتے ہیں...

آپ OpenShift ورچوئلائزیشن ورچوئل مشینوں کو نیٹ ورک سے بنانے اور جوڑنے کے طریقے کے بارے میں مزید جان سکتے ہیں۔ یہاں... اس کے علاوہ ، nmstate آپریٹرOpenShift ورچوئلائزیشن کے حصے کے طور پر تعینات کیا گیا، فزیکل نوڈس پر نیٹ ورک کنفیگریشن بنانے اور ان کا نظم کرنے کا ایک اور مانوس طریقہ پیش کرتا ہے جو ہائپر وائزرز کے تحت استعمال ہوتے ہیں۔

safekeeping کے

OpenShift ورچوئلائزیشن کے اندر ورچوئل مشین ڈسکوں کو جوڑنا اور ان کا نظم کرنا Kubernetes کے تصورات جیسے StorageClasses، PersistentVolumeClaims (PVC) اور PersistentVolume (PV) کے ساتھ ساتھ Kubernetes ماحول کے لیے اسٹوریج پروٹوکول کے معیار کا استعمال کرتے ہوئے انجام دیا جاتا ہے۔ یہ Kubernetes کے منتظمین اور ایپلیکیشن ٹیموں کو کنٹینرز اور ورچوئل مشینوں دونوں کو منظم کرنے کا ایک عام، مانوس طریقہ فراہم کرتا ہے۔ اور ورچوئلائزیشن ماحول کے بہت سے منتظمین کے لیے، یہ تصور مانوس لگ سکتا ہے کیونکہ یہ VM کنفیگریشن فائلوں اور ڈسکوں کو الگ کرنے کے وہی اصول استعمال کرتا ہے جو OpenStack اور بہت سے دوسرے کلاؤڈ پلیٹ فارمز میں استعمال ہوتا ہے۔

تاہم، ہم ہر بار VM کے لیے ایک نئی ڈسک نہیں بنا سکتے، کیونکہ جب ہائپر وائزر سے OpenShift میں منتقل ہوتے ہیں، تو ہمیں ڈیٹا کو محفوظ کرنے کی ضرورت ہوتی ہے۔ ہاں، یہاں تک کہ جب ہم ایک نیا VM لگاتے ہیں، اسے شروع سے تخلیق کرنے کے بجائے ٹیمپلیٹ سے کرنا ہمیشہ تیز ہوتا ہے۔ اس طرح، ہمیں موجودہ ڈسکوں کو درآمد کرنے کے لیے فعالیت کی ضرورت ہے۔

اس کام کو آسان بنانے کے لیے، OpenShift ورچوئلائزیشن کنٹینرائزڈ ڈیٹا امپورٹر (CDI) پروجیکٹ کو متعین کرتی ہے، جو PVC اندراج بنانے کے لیے متعدد ذرائع سے ڈسکوں کی ڈسک امیجز کی درآمد کو کم کرتی ہے۔

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: "fedora-disk0"
  labels:
    app: containerized-data-importer
  annotations:
    cdi.kubevirt.io/storage.import.endpoint: "http://10.0.0.1/images/Fedora-Cloud-Base-31-1.9.x86_64.qcow2"
spec:
  storageClassName: ocs-gold
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

یہ وہ اندراج ہے جو سی ڈی آئی کو متحرک کرتا ہے، ذیل کے اعداد و شمار میں دکھائے گئے اعمال کی ترتیب کو متحرک کرتا ہے۔

CDI مکمل ہونے کے بعد، PVC میں ورچوئل مشین ڈسک ہوگی جو استعمال کے لیے تیار ہے اور اسے معیاری OpenShift فارمیٹ میں تبدیل کر دیا جائے گا...
OpenShift ورچوئلائزیشن کے ساتھ کام کرتے وقت، OpenShift Container Storage (OCS)، Ceph فائل سسٹم پر مبنی ایک Red Hat حل جو کنٹینرز کے لیے مستقل اسٹوریج کی فعالیت کو نافذ کرتا ہے، بھی مفید ہے۔ معیاری PVC رسائی کے طریقوں کے علاوہ - RWO (بلاک) اور RWX (فائل) - OCS خام بلاک آلات کے لیے RWX فراہم کرتا ہے، جو اعلی کارکردگی کی ضروریات کے ساتھ ایپلی کیشنز کے لیے بلاک رسائی کا اشتراک کرنے کے لیے بہت مفید ہے۔ اس کے علاوہ، OCS نئے آبجیکٹ بکٹ کلیم کے معیار کی حمایت کرتا ہے، جو ایپلیکیشنز کو آبجیکٹ ڈیٹا اسٹوریج کو براہ راست استعمال کرنے کی اجازت دیتا ہے۔

کنٹینرز میں ورچوئل مشینیں۔

اگر آپ یہ جانچنے میں دلچسپی رکھتے ہیں کہ یہ کیسے کام کرتا ہے، تو جان لیں کہ OpenShift ورچوئلائزیشن پہلے سے ہی ٹیک پری ویو ورژن میں OpenShift 3.11 اور اس سے زیادہ کے حصے کے طور پر دستیاب ہے۔ موجودہ OpenShift سبسکرپشن کے مالکان OpenShift ورچوئلائزیشن کو بالکل مفت اور بغیر کسی اضافی اقدامات کے استعمال کر سکتے ہیں۔ اس پوسٹ کے وقت، OpenShift 4.4 اور OpenShift ورچوئلائزیشن 2.3 موجودہ ہیں؛ اگر آپ پچھلے ورژن استعمال کر رہے ہیں، تو آپ کو تازہ ترین خصوصیات حاصل کرنے کے لیے اپ گریڈ کرنا چاہیے۔ OpenShift ورچوئلائزیشن کا مکمل تعاون یافتہ ورژن 2020 کے دوسرے نصف میں جاری کیا جانا چاہیے۔

مزید معلومات کے لیے، براہ کرم ملاحظہ کریں۔ اوپن شفٹ دستاویزات تنصیب کی ہدایات کے لیے، بشمول ملٹس سیٹ اپ سیکشن، جو بیرونی نیٹ ورکس کو ترتیب دینے کے بارے میں معلومات فراہم کرتا ہے۔

ماخذ: www.habr.com