অন্যান্য ভিএম এর বেসিমেজ হিসাবে ব্যবহার করার জন্য কাঁচা বা কিউকিউ 2, এর চেয়ে ভাল ইমেজ ফর্ম্যাটটি কোনটি?


25

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

সম্পাদনা 1:

আমি কিছু পরীক্ষা নিরীক্ষা করেছি এবং পেয়েছি এখানে চিত্র বর্ণনা লিখুনএখানে চিত্র বর্ণনা লিখুনএখানে চিত্র বর্ণনা লিখুন

প্রথমটি হ'ল বেসিমেজ এবং ওভারলে উভয়ই QCO2 হয়। দ্বিতীয় যখন বেসিমেজ কাঁচা হয় তবে ওভারলেটি QCO2 হয় এবং তৃতীয় ক্ষেত্রে আমি প্রতিটি ভিএমকে পৃথক কাঁচা ডিস্ক চিত্র দিচ্ছি। আশ্চর্যজনকভাবে, শেষের ক্ষেত্রে অন্যান্য দুটি তুলনায় অনেক বেশি দক্ষ।

পরীক্ষামূলক সেটআপ: 
বেসমেজেজে ওএস: উবুন্টু সার্ভার 14.04 64 বিট।
হোস্ট ওএস: উবুন্টু 12.04 64 বিট
র‌্যাম: 8 জিবি
প্রসেসর: ইন্টেল কোর ™ i5-4440 সিপিইউ @ 3.10GHz × 4 
ডিস্ক: 500 জিবি 

এক্স-অক্ষে: একসাথে বুট করা ভিএম সংখ্যা। 1 থেকে শুরু এবং 15 পর্যন্ত বর্ধিত।

Y- অক্ষগুলিতে: "x" মেশিনের সংখ্যা বুট করার মোট সময়।

গ্রাফগুলি থেকে মনে হচ্ছে ভিএমকে ফুল ডিস্ক চিত্র দেওয়া আরও 2 টি পদ্ধতিতে আরও দক্ষ।

সম্পাদনা 2: এখানে চিত্র বর্ণনা লিখুন

এটি তখনকার ক্ষেত্রে যখন আমরা প্রতিটি ভিএমকে পৃথক কাঁচা চিত্র দিচ্ছি। ক্যাশে ফ্লাশিং করার পরে, এটি গ্রাফ। এটি কাঁচা বেসমেজ + কিউকিও ওভারলেয়ের সাথে প্রায় সমান।

ধন্যবাদ।


1
আমি একটি কাঁচা বেস-চিত্র ব্যবহার করব এবং কিউকিও 2 এর পরিবর্তে ওভারলে কিউইডি করব। কিউইডি কিউকো 2 এর চেয়ে দ্রুত এবং ডিজাইন দ্বারা দূষিত হওয়ার সম্ভাবনা কম।
ম্যাট

@ ম্যাট দয়া করে সম্পাদিত প্রশ্নে মন্তব্য করুন।
এবি

পারফরম্যান্স পার্থক্য আকর্ষণীয়। আপনি কিএইডি দিয়ে চেষ্টা করতে পারেন? কিউকিও 2 বাস্তবায়নে কোনও বিতর্ক / লক করার সমস্যা হতে পারে। আমি বিশ্বাস করি এটির কিছু সমস্যা রয়েছে যার কারণে তারা Qed আবিষ্কার করেছিল।
ম্যাট

1
@ ম্যাট আমি কাঁচা বেসিমেজ-কিড ওভারলে এবং কাঁচা বেসিমেজ-কিউকো 2 ওভারলে পরীক্ষা করেছি। তবে এই সেটিংয়ে কিউডো 2 এর তুলনায় কিয়েড অনেক ধীর।
এবি

উত্তর:


18

আপনার নির্দিষ্ট ব্যবহারের ক্ষেত্রে (বেস চিত্র + qCO2 ওভারলে), কা ফর্ম্যাটটি পছন্দ করা উচিত:

  1. এটি দ্রুত: এটির সাথে কোনও মেটাডেটা যুক্ত নেই, এটি যত দ্রুত সম্ভব। অন্যদিকে, কিউকো 2-তে দুটি ইন্ডিয়ারেশন রয়েছে যা আসল ডেটা মারার আগে অবশ্যই অতিক্রম করতে হবে
  2. ওভারলে স্তরটি অবশ্যই কিউকিও 2 ফাইল হওয়া উচিত, আপনি চিরকালীন-স্নাপশট ক্ষমতাটি হারাবেন না (RAW চিত্রগুলি নিজেরাই স্ন্যাপশটগুলিকে সমর্থন করে না)

বেস ইমেজ + কিউকো 2 ওভারলে বনাম একাধিক সম্পূর্ণ কপির মধ্যে পছন্দটি আপনার অগ্রাধিকারের উপর নির্ভর করে:

  1. নিরঙ্কুশ পারফরম্যান্সের জন্য, ফ্যালোকেটেড RAW চিত্র ব্যবহার করুন। এটিতে স্ন্যাপশটকে সমর্থন না করার খারাপ দিক রয়েছে, বেশিরভাগ পরিবেশে অর্থ প্রদানের জন্য খুব বেশি দাম
  2. নমনীয়তা এবং স্থান-দক্ষতার জন্য RAW বেস চিত্রগুলি + কিউকিও 2 ওভারলেগুলি ব্যবহার করুন।

যাইহোক, আমি কিউকো 2 ফাইলগুলি কিছুটা ভঙ্গুর পেয়েছি।

আমার উত্পাদনের জন্য কেভিএম হাইপারভাইজারগুলি আমি মূলত দুটি ভিন্ন সেটআপ ব্যবহার করি:

  1. কর্মক্ষমতা # 1 যেখানে আমি সরাসরি ভার্চুয়াল মেশিনের সাথে যুক্ত এলভিএম ভলিউম ব্যবহার করি এবং ধারাবাহিক ব্যাকআপ নিতে আমি LVM স্ন্যাপশট ক্ষমতাটি ব্যবহার করি
  2. বর্ধিত নমনীয়তার জন্য যেখানে আমি কিছু কর্মক্ষমতা ত্যাগ করতে পারি, সেখানে আমি একক, বড় এলভিএম পাতলা প্রভিশিত ভলিউম + এক্সএফএস + কা চিত্র ব্যবহার করি

আর একটি সম্ভাবনা হ'ল একটি সাধারণ এলভিএম ভলিউম + এক্সএফএস + কা চিত্র ব্যবহার করা। একমাত্র ক্ষতিটি হ'ল স্বাভাবিক (নন-পাতলা) LVM স্ন্যাপশটগুলি খুব ধীর এবং একটি ব্যস্ত সাধারণ LVM ভলিউমের স্ন্যাপশট করা পারফরম্যান্সকে মেরে ফেলবে (স্ন্যাপশটের আজীবন)। যাইহোক, আপনি যদি স্ন্যাপশটগুলির কেবল বিক্ষিপ্তভাবে ব্যবহার করার পরিকল্পনা করেন তবে এটি সহজ এবং নিরাপদ বাজি হতে পারে।

কিছু উল্লেখ: আরএইচইএল
6
কেভিএম স্টোরেজ কর্মক্ষমতা সম্পর্কে কেভিএম আই / হে ownিলেটি এবং আরএইচইএল 6.1 এবং ফেডোরা 16 কেভিএম
স্টোরেজ কর্মক্ষমতা এবং রেড হ্যাট এন্টারপ্রাইজ লিনাক্স 6.2 এলভিএম পাতলা ভলিউমে ক্যাশে সেটিংস
ব্যাখ্যা করেছে


উপরে উল্লিখিত হিসাবে: পৃথক RAW চিত্রগুলি ইন্ডিয়ারেশন স্তরগুলির কারণে দ্রুত হতে চলেছে। মনে রাখবেন আপনি তবে স্ন্যাপশট (চিত্রের স্তরে) এবং স্থান দক্ষতা ছেড়ে দিচ্ছেন। তদুপরি, আমি এই ছাপে আছি যে আপনার তৃতীয় ফলাফলটি হোস্ট ক্যাশে দ্বারা স্কুড হয়েছে। নিশ্চিত হওয়ার জন্য, প্রতিটি রানের মধ্যে "সিঙ্ক; ইকো 3> / proc / sys / vm / ড্রপ_ক্যাচস" জারি করে আপনার সমস্ত পরীক্ষা আবার করুন।
shodanshok

আসলে আমিও তাই ভাবছিলাম। তবে আমি ভেবেছিলাম যে, প্রকৃত ব্যবহারের ক্ষেত্রেও এটি একই প্রবাহ অনুসরণ করবে।
এবি

সত্যই নয়: এই পরীক্ষার পরিবেশে, আপনি কেবল আপনার ভার্চুয়াল মেশিনগুলি ব্যবহার না করেই বুট করছেন। বাস্তব ক্ষেত্রে, ভার্চুয়াল মেশিনগুলি বুট করার পরে ক্যাশে দূষিত করা হবে। সাধারণভাবে, যুক্তিসঙ্গত ব্যবহারের ক্ষেত্রে বেঞ্চমার্ক করা ভাল।
shodanshok

ক্যাচিং কেন গ্রাফ 1 এবং গ্রাফ 2 যেমন কিউকো 2 বেস-ইমেজ + কিউকো 2 ওভারলে এবং কাঁচা বেস-চিত্র + কিউকো 2 ওভারলেতে এতটা ভূমিকা রাখছে না আপনার কোনও ধারণা আছে?
এবি

6

দয়া করে পরামর্শ দিন .... আপনি যদি লিনাক্স ব্যবহার করে থাকেন তবে আপনি যতটা আকার যায় rawতার একই বেনিফিটগুলি ব্যবহার করতে পারেন qcow2

... যদি আপনার ফাইল সিস্টেমটি গর্তগুলি সমর্থন করে (উদাহরণস্বরূপ লিনাক্সের এক্সট 2 বা এক্সট 3 বা উইন্ডোজে এনটিএফএসে), তবে কেবলমাত্র লিখিত খাতগুলি স্থান সংরক্ষণ করবে।

https://docs.fedoraproject.org/en-US/Fedora/18/html/Virtualization_Administration_Guide/sect-Virtualization-Tips_and_tricks-Using_qemu_img.html

কাঁচা কাঁচা ডিস্ক চিত্র ফর্ম্যাট (ডিফল্ট)। এটি দ্রুততম ফাইল-ভিত্তিক ফর্ম্যাট হতে পারে। যদি আপনার ফাইল সিস্টেমটি গর্তগুলিকে সমর্থন করে (উদাহরণস্বরূপ লিনাক্সের এক্সট 2 বা এক্সট 3 বা উইন্ডোজে এনটিএফএস), তবে কেবলমাত্র লিখিত খাতগুলি স্থান সংরক্ষণ করবে। ইউনিক্স / লিনাক্সের চিত্র বা ls -ls দ্বারা ব্যবহৃত প্রকৃত আকার পেতে qemu-img তথ্য ব্যবহার করুন।


ভাল যুক্তি! তবে ব্যাকআপ / অনুলিপি / সংক্ষেপণে কাঁচা চিত্র-ফাইলের পুরো আকার ব্যবহার করা হয় বলে মনে হয়। ডিস্কে কেবল 4 এমবি বরাদ্দকৃত একটি 20 জিবি কাঁচা ফাইল
20 এমবিতে

এটা আমার জন্য সম্পূর্ণ নতুন ছিল। আমার প্রক্সমক্স ভিইতে 30 জিবি ভার্চুয়াল ডিস্ক সহ একটি ভিএম রয়েছে ... এবং আমি দেখতে পাচ্ছি যে হোস্ট ফাইল সিস্টেমে ডিস্কটির আকার রয়েছে। তবে হোস্ট ফাইল সিস্টেমে << 10 গিগাবাইটের সমস্ত ব্যবহার রয়েছে। এখন সেই কারণেই আমি যা খুঁজছিলাম।
cljk
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.