এলভিএম ভলিউম গ্রুপ কেভিএম / লিব্বার্ট হোস্ট এবং অতিথিদের মধ্যে ভাগ করেছে: এটি কী খারাপ ধারণা?


12

আমি সবেমাত্র একটি চকচকে নতুন কেভিএম / লিব্বার্ট-ভিত্তিক ভার্চুয়াল মেশিন হোস্ট তৈরি করেছি, এতে 4 টি SATA II হার্ড ড্রাইভ রয়েছে এবং সেন্টোস 5.5 x86_64 চলছে।

ডিস্কগুলি কিউকিও ইমেজ হিসাবে তৈরি করার স্বাভাবিক অনুশীলনের পরিবর্তে, একটি এলভিএম ভলিউম গ্রুপে লিবলিক ভলিউম হিসাবে ভার্চুয়াল মেশিন ডিস্ক তৈরি করার সিদ্ধান্ত নিয়েছি ।

আমি যা সিদ্ধান্ত নিতে পারছি না তা হ'ল আমার ভিএম হোস্টের ভলিউম গ্রুপে বা একটি ডেডিকেটেড ভলিউম গ্রুপে ভার্চুয়াল মেশিন লজিক্যাল ভলিউম তৈরি করা উচিত।

আমার কোন পদ্ধতিটি বেছে নেওয়া উচিত এবং কেন?


পদ্ধতি 1: ভিএম হোস্টের ভলিউম গ্রুপটি ব্যবহার করুন

বাস্তবায়ন:

  • ফাইল md0- /bootসিস্টেম সমন্বিত ছোট RAID1
  • বড় RAID10 md1অবশিষ্ট স্থান দখল করে, এতে একটি LVM ভলিউম গ্রুপ রয়েছে vghostvghostভিএম হোস্টের মূল ফাইল সিস্টেম এবং অদলবদল বিভক্ত রয়েছে
  • vghostপ্রয়োজনীয় হিসাবে লজিক্যাল ভলিউম হিসাবে ভার্চুয়াল মেশিন ডিস্ক তৈরি করুন

পেশাদাররা:

  • যদি ভিএম হোস্টের রুট ফাইল সিস্টেমটি জায়গার বাইরে চলে যায় তবে vghostআপেক্ষিক স্বাচ্ছন্দ্য থেকে আমি আরও জায়গা বরাদ্দ করতে পারি
  • সিস্টেমটি ইতিমধ্যে চালু এবং চলছে (তবে এটি শুরু করা কোনও বড় বিষয় নয়)

কনস:

এই পদ্ধতিটি কাজ করছে বলে মনে করেন, আমি এই অনুভূতিটি কাঁপতে পারি না যে এটি কোনওভাবেই খারাপ ধারণা। আমি সেটা অনুভব করি:

  • এটি একরকম একটি সুরক্ষা ঝুঁকি হতে পারে
  • ভবিষ্যতের কোনও পর্যায়ে আমি সেটআপটির সাথে কিছুটা সীমাবদ্ধতা পেতে পারি এবং আশা করি যে আমি একটি উত্সর্গীকৃত গোষ্ঠীটি ব্যবহার করেছি
  • সিস্টেমটি (CentOS, libvirt, ইত্যাদি) সত্যিই এটির মতো ব্যবহারের জন্য নকশাকৃত নাও হতে পারে এবং তাই এক পর্যায়ে আমি ভিএম হোস্টের ফাইলগুলি এবং / অথবা ফাইল-সিস্টেমকে দুর্নীতিগ্রস্থ / হারাতে পারি might

পদ্ধতি 2: একটি উত্সর্গীকৃত ভলিউম গ্রুপ ব্যবহার করুন

বাস্তবায়ন:

  • একই md0এবং md1পদ্ধতি 1 এর মতো, md1ভিএম হোস্টের জন্য যথেষ্ট পরিমাণে যথেষ্ট পরিমাণে তৈরি করা (উদাহরণস্বরূপ 5 থেকে 10 গিগাবাইট)
  • md2অবশিষ্ট স্থান দখল করা বড় RAID10 । md2একটি এলভিএম ভলিউম গ্রুপ রয়েছে vgvms, যার লজিকাল ভলিউমগুলি ভার্চুয়াল মেশিনগুলির দ্বারা একচেটিয়াভাবে ব্যবহার করা উচিত

পেশাদাররা:

  • আমি vgvmsহোস্ট ওএস ভঙ্গ করার ভয় ছাড়াই টিঙ্কার করতে পারি
  • এটি আরও মার্জিত এবং নিরাপদ সমাধান বলে মনে হচ্ছে

কনস:

  • যদি ভিএম হোস্টের ফাইল সিস্টেমটি স্থানের বাইরে চলে যায় তবে আমাকে এর ফাইল সিস্টেমের কিছু অংশ (যেমন। / usr বা / var) এর দিকে সরিয়ে ফেলতে হবে vgvms, যা খুব সুন্দর বলে মনে হচ্ছে না।
  • আমাকে হোস্ট ওএস পুনরায় ইনস্টল করতে হবে (যা আগে বলেছিল যে আমি আসলেই কিছু মনে করি না)

আপডেট # 1:

পদ্ধতি 2 তে আমি ভিএম হোস্ট ডিস্কের জায়গাটি সরিয়ে নিয়ে যাওয়ার জন্য কেন উদ্বিগ্ন হওয়ার একটি কারণ হ'ল আমি জানি না যে ভিএম হোস্ট ভার্চুয়াল মেশিনে সমস্ত পরিষেবাদি চালানোর পক্ষে যথেষ্ট শক্তিশালী কিনা। আমাকে ভার্চুয়াল মেশিন থেকে হোস্ট ওএসে কিছু / সমস্ত পরিষেবা স্থানান্তর করতে হতে পারে।

ভিএম হোস্ট হার্ডওয়্যার স্পেসিফিকেশন:

  • ফেনোম II 955 এক্স 4 ব্ল্যাক সংস্করণ প্রসেসর (3.2GHz, 4-কোর সিপিইউ)
  • 2x4GB কিংস্টন PC3-10600 ডিডিআর 3 র‌্যাম
  • গিগাবাইট GA-880GM-USB3 মাদারবোর্ড
  • 4x ডাব্লুডি ক্যাভিয়ার আরই 3০০ জিবি সটা II এইচডিডি (7200 আরপিএম)
  • আনটেক বিপি 500 ইউ বাসিক 500W এটিএক্স বিদ্যুৎ সরবরাহ
  • কুলারমাস্টার সিএম 690 মামলা

আপডেট # 2:

আমি মনে করি যে কারণটি 1 ম পদ্ধতিতে হোস্ট ভিজি-কে একটি লিবারভিট স্টোরেজ পুল হিসাবে ব্যবহার করার জন্য নকশাকৃত নাও হতে পারে তার কারণ হ'ল গুণ-পরিচালকের মধ্যে আমি লক্ষ্য করেছি:

  • যোগ করার পরে, এটি অভিযোগ করেছে যে এটি ভিজিটিকে সক্রিয় করতে পারে না (সম্ভবত, হোস্ট ওএস ইতিমধ্যে এটি সক্রিয় করেছে)
  • সরানোর পরে, এটি এটি করতে অস্বীকার করেছিল কারণ এটি ভিজিকে নিষ্ক্রিয় করতে পারেনি (স্পষ্টতই, কারণ হোস্ট ওএস এখনও রুটটি ব্যবহার করে এবং এলভিগুলি অদলবদল করে)

আমি একটি প্রশ্ন করেছি (# 272324) যেখানে আপনার সমাধান # 1 খুব ভাল উত্তর হতে পারে! এবং ঠিক এটিই আমি একই ধরণের সেটআপে গিয়েছিলাম - এবং আমি এটির সাথে অনেকটাই খুশি। আমার অবশ্য সমস্যা আছে যেখানে অতিথির মধ্যে ডিস্কআইও হোস্টের একই এলভি "লুপ-মাউন্টিং" এর চেয়ে ধীরে ধীরে হয়।
স্টলভিক

উত্তর:


3

ভাল চিন্তা-ভাবনা প্রশ্ন!

আমি পদ্ধতি 2 নিয়ে যাব, তবে এটি ব্যক্তিগত পছন্দ বেশি। আমার কাছে, পদ্ধতি 2 কনস খুব বেশি সমস্যা নয়। হোস্ট ওএস এর 5-10 জিবি পার্টিশনটি বাড়িয়ে দেখছি না, যদি না আপনি এটিতে অতিরিক্ত জিনিস ইনস্টল করা শুরু করেন, যা আপনার সত্যিকারের উচিত নয়। সরলতা এবং সুরক্ষার স্বার্থে, হোস্ট ওএস সত্যই একটি নিরপেক্ষ ন্যূনতম ইনস্টল হওয়া উচিত, প্রশাসনের জন্য প্রয়োজনীয় ন্যূনতম সর্বনিম্ন ব্যতীত অন্য কোনও কিছুই চালানো উচিত নয় (যেমন, এসএসডিডি)।

পদ্ধতি 1 কনস আসলেই কোনও সমস্যা নয়, আইএমও। আমি মনে করি না যে কোনও অতিরিক্ত সুরক্ষা ঝুঁকি থাকবে, যেহেতু কোনও মূলযুক্ত ভিএম যদি কোনওভাবে তার পার্টিশনটি ভেঙে ফেলতে এবং অন্য পার্টিশনগুলিকে সংক্রামিত / ক্ষতিগ্রস্থ করতে সক্ষম হয়, তবে পৃথক ভিজিতে হোস্ট ওএস থাকা কোনও পার্থক্য করতে পারে না। অন্য দুটি কনস সরাসরি অভিজ্ঞতা থেকে আমি কথা বলতে পারি না, তবে আমি আমার অন্ত্রে বলেছি যে সেন্টোস, এলভিএম, এবং লিবারভিটগুলি নমনীয় এবং তাদের সম্পর্কে চিন্তা না করার জন্য যথেষ্ট শক্তিশালী।

সম্পাদনা - আপডেটের জন্য প্রতিক্রিয়া 1

আজকাল, ভার্চুয়ালাইজেশনের পারফরম্যান্স হিট খুব কম, বিশেষত এর সমর্থনে নির্মিত প্রসেসর ব্যবহার করে, তাই কোনও অতিথির ভিএম থেকে হোস্ট ওএসে কোনও পরিষেবা স্থানান্তর করা কখনই উপযুক্ত হবে বলে আমি মনে করি না। আপনি পারে "খালি ধাতু" চলমান দ্বারা 10% গতি বুস্ট পাবেন, কিন্তু আপনি একটি ছোট, আঁট, নিরাপদ হোস্ট অপারেটিং সিস্টেম থাকার সুবিধাগুলো হারাবে, এবং সম্ভাব্য পুরো সার্ভারের স্থায়িত্ব প্রভাবিত। আইএমও।

এর আলোকে, আমি এখনও 2 পদ্ধতিটির পক্ষে চাই।

আপডেট 2 এর প্রতিক্রিয়া

দেখে মনে হচ্ছে যে বিশেষ উপায়ে libvirt স্টোরেজটি ধরিয়ে দেওয়া হয়েছে তা পদ্ধতি 2 এর পক্ষে আরও একটি পয়েন্ট My আমার সুপারিশটি হ'ল: পদ্ধতি 2 দিয়ে যান।


ধন্যবাদ। আমি আমার প্রশ্নের 2 টি আপডেট সংযোজন করেছি, যা আপনাকে ব্যাখ্যা করেছে যে আমি যে কনস কনসটিকে আমি সম্বোধন করেছি তার কয়েকটি কেন তালিকাভুক্ত করেছে তা আরও ব্যাখ্যা করে। আপডেটগুলি কি আদৌ আপনার মতামত পরিবর্তন করে?
Mosno

@ মোসনো: আপনার আপডেটের জবাবে আমার উত্তর আপডেট করেছে।
স্টিভেন সোমবার

আপনার উত্তরের জন্য সবাইকে ধন্যবাদ, সবাই আমার পক্ষে সহায়ক হয়েছে এবং কার উত্তর গ্রহণ করতে হবে তা বেছে নেওয়া কঠিন ছিল। আমি স্টিভেনকে বেছে নিচ্ছি কারণ আমার মনে হয়েছে যে জিজ্ঞাসা করা প্রশ্নটি সমাধানের জন্য এটি সর্বোত্তম প্রচেষ্টা করে। রেকর্ডটির জন্য, যদিও আমি সম্মত করি পদ্ধতি 2 সম্ভবত আরও ভাল, আমি পদ্ধতি 1 এর সাথে থাকতে বেছে নিয়েছিলাম কারণ এটি কাজ করে এবং সময়সীমাবদ্ধতার কারণে।
Mosno

1
এছাড়াও, আমি আপাতত পদ্ধতি 1 এর সাথে রয়েছি কারণ আমার ধারণা এই পদ্ধতির সীমাবদ্ধতাগুলি অন্বেষণ করা শিক্ষামূলক হবে be উদাহরণস্বরূপ, আমি শিখেছি যে কোনও অতিথি ওএসে আপনি যদি সরাসরি ডিভাইসে একটি এলভিএম পিজি তৈরি করেন (উদাহরণস্বরূপ ডিভাইস / ডিভ / ভিডিএ পরিবর্তে পার্টিশন / দেব / ভিডিএ 1), তবে হোস্ট ওএসের পিভিস্কান অতিথির পিভি তালিকাভুক্ত করে (যেমন। / dev / vda1 ব্যবহার করুন, / dev / vda নয়)।
Mosno

1

যতক্ষণ না কেবল একটি সিস্টেম যেকোন সময় পঠন / লেখার মোডে প্রদত্ত এলভি ব্যবহার করার চেষ্টা করে, হোস্ট এবং অতিথিদের জন্য একই ভিজি ব্যবহার করা সম্ভব ible যদি একাধিক সিস্টেম একই এলভিতে লেখার চেষ্টা করে তবে ফাইল সিস্টেমের দুর্নীতির ফলস্বরূপ।


এটি পরিচালনা করার জন্য অবশ্যই জটিলতার একটি বর্ধিত স্তর রয়েছে। এটা চতুর..মাব খুব চালাক।
ইউনিক্স জ্যানিটার

@ ব্যবহারকারী37899: এটি এলভিএম হ্যান্ডেল করার সাধারণ উপায়
জাভিয়ের

ধন্যবাদ, তবে আমি তা বুঝতে পারি; আমি এটা করার পরিকল্পনা করছিলাম না।
Mosno

আমি যখন হোস্ট ওএসে "lvscan" করি তখন এটি অতিথির LV কে "ACTIVE" হিসাবে রিপোর্ট করে। হোস্টের কাছে এলভি লাগানো নেই। LV কেবল "ACTIVE" অবস্থায় থাকায় কি "পড়ুন / লেখার মোড" গঠিত হয়, বা আপনি হোস্টের ফাইল সিস্টেমে একটি স্পষ্ট মাউন্ট বলতে চান?
মোসনো

আমার অর্থ একটি স্পষ্ট r / w মাউন্ট mean
Ignacio Vazquez-Abram

1

আপনি এটি একবার দেখে নিতে পারেন, সম্ভবত টিঙ্কার এবং দেখুন যে প্রকল্পটি আপনি কী বলছেন তা কী করে।

প্রক্সমক্সভিএইয়ার একটি বেয়ার-মেটাল কেভিএম হোস্ট যা আরএইচইএল এর ভারী পাল্টা অংশের পরিবর্তে লিভারভিটের একটি পার্ল বাস্তবায়ন ব্যবহার করে। এটি উভয় দৃশ্যের প্রয়োগ করে।

ভার্চুয়াল ডিস্কগুলি .raw এবং স্পর্স, .ক্কোয়ের মতো তবে দ্রুত faster

কিউকো ও ভিএমডিকি ডিস্ক চিত্রের ফর্ম্যাটগুলিও সমর্থিত তবে আমি মনে করি এতে জড়িত এলভিএম সীমাবদ্ধতা থাকতে পারে। আমি সেগুলি ব্যবহার করি না তাই এ বিষয়ে আমি বেশি কিছু বলতে পারি না।

এলভিএম স্টোরেজটি নোডের ভিএমগুলির মধ্যে ভাগ করা হয় এবং এটি ডিআরবিডি ডিভাইস হতে পারে।

ওএস-এর ভিজি স্পেস ভাগ করার ক্ষেত্রে ব্যাকআপের সময় স্ন্যাপশটের আকারের সাথে সম্পর্কিত কেবলমাত্র সীমাবদ্ধতা। এখানে এই মানটি একটি কনফিগার ফাইলে পরিবর্তিত হতে পারে এবং আমি কখনও কখনও ফোরামে দেখতে পাই যেখানে লোকেরা এটি পরিবর্তন করতে হয়েছিল তবে ডিফল্টরা আমাকে বেশ কয়েক বছর ধরে ভালভাবে পরিবেশন করেছে - এমনকি বিশাল ভার্চুয়াল ডিস্ক সহ।

পিভিই এর এলভিএম স্টোরেজ বিশদ:

http://pve.proxmox.com/wiki/Storage_Model#LVM_Groups_with_Network_Backing

ভিজিগুলি এভাবেই রাখা হয়:

মেটাডেটা টাইপ lvm2 ব্যবহার করে ভলিউম গ্রুপ "LDatastore1" পাওয়া গেছে

মেটাডেটা টাইপ lvm2 ব্যবহার করে ভলিউম গ্রুপ "LDatastore0" পাওয়া গেছে

মেটাডেটা টাইপ lvm2 ব্যবহার করে ভলিউম গ্রুপ "pve" পাওয়া গেছে

এগুলি আমার এলভিগুলি:

ACTIVE '/ dev / LDatastore1 / vm-9098-Disc-1' [৪.০০ গিগাবাইট] উত্তরাধিকারী

ACTIVE '/ dev / LDatastore1 / vm-7060-Disc-1' [২.০০ গিগাবাইট] উত্তরাধিকার সূত্রে প্রাপ্ত

ACTIVE '/ dev / LDatastore1 / vm-5555-Disc-1' [8.00 গিগাবাইট] উত্তরাধিকারী

ACTIVE '/ dev / LDatastore0 / vm-4017-Disc-1' [8.00 গিগাবাইট] উত্তরাধিকারী

ACTIVE '/ dev / LDatastore0 / vm-4017-Disc-2' [512.00 গিগাবাইট] উত্তরাধিকারী

ACTIVE '/ dev / LDatastore0 / vm-7057-Disc-1' [32.00 গিগাবাইট] উত্তরাধিকারী

ACTIVE '/ dev / LDatastore0 / vm-7055-Disc-1' [32.00 গিগাবাইট] উত্তরাধিকারী

ACTIVE '/ dev / LDatastore0 / vm-6030-Disc-1' [80.01 গিগাবাইট] উত্তরাধিকারী

ক্রিয়াকলাপ '/ dev / pve / swap' [৩.62২ গিগাবাইট] উত্তরাধিকার সূত্রে প্রাপ্ত

ক্রিয়াকলাপ '/ dev / pve / root' [7.25 গিগাবাইট] উত্তরাধিকার সূত্রে প্রাপ্ত

ক্রিয়াকলাপ '/ dev / pve / ডেটা' [14.80 গিগাবাইট] উত্তরাধিকার সূত্রে প্রাপ্ত

এটি 72 7200 আরপিএম সীগেট ব্যারাকুডা এসটিএ ড্রাইভের তৈরি RAID10 এ এলভিএম:

সিপিইউ বগমীপস: 53199.93

রিগেক্স / সেকেন্ড: 824835

এইচডি সাইজ: 19.69 গিগাবাইট (/ দেব / ম্যাপার / এলডিটাস্টোর0-টেস্টলভি)

বুফারড রিডস: 315.17 এমবি / সেকেন্ড

গড় অনুসন্ধান সময়: 7.18 এমএস

এফএসওয়াইএনসিএস / সেকেন্ড: 2439.31

এবং এটি সিঙ্গেল ইন্টেল এক্স 25-ই সটা এসএসডি-তে এলভিএম, উল্লিখিত / দেব / পাভ / ডেটা যেখানে ভিএম থাকে সেখানে একই ভিজি:

সিপিইউ বগমীপস: 53203.97

রিগেক্স / সেকেন্ড: 825323

এইচডি আকার: 7.14 গিগাবাইট (/ দেব / ম্যাপার / pve- মূল)

বুফার্ড রিডস: 198.52 এমবি / সেকেন্ড

গড় অনুসন্ধান সময়: 0.26 এমএস

এফএসওয়াইএনসিএস / সেকেন্ড: 1867.56

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.