এসকিউএল সার্ভার সহ একাধিক পিভিএসসিএসআই


12

এসকিউএল সার্ভার ভার্চুয়ালাইজেশন সম্পর্কিত, লগ ডিভাইসগুলি থেকে পৃথক প্যারাভিচুয়াল এসসিএসআই (পিভিএসসিএসআই) অ্যাডাপ্টারগুলিতে পৃথক করার ক্ষেত্রে যদি ইতিবাচক কর্মক্ষমতা প্রভাব থাকে তবে তথ্য সন্ধানের চেষ্টা করা হচ্ছে

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

যেমনটি জানা যায় যে লগ ডিস্কগুলি সাধারণত ক্রমানুসারে লেখা হয়, যখন ডেটা ডিস্কগুলি তাদের আর / ডাব্লুতে আরও র্যান্ডম প্যাটার্ন অনুসরণ করে এবং পৃথক ডিস্কে এই দুটি ভিন্ন ধরণের ফাইল রাখার কার্যকারিতা সুবিধা রয়েছে।

তবে নিয়ন্ত্রণকারীদের কী হবে? পৃথক পিভিএসসিএসআই নিয়ন্ত্রকগুলিতে এই বিভিন্ন ধরণগুলি রাখার কি কোনও সুবিধা রয়েছে?

এই সম্পর্কে কারও অন্তর্দৃষ্টি আছে?

আগাম ধন্যবাদ

উত্তর:


15

আমি দুটি অংশে উত্তর দেব: প্রথম "কেন ক্রমবর্ধমান এবং র্যান্ডম পৃথকীকরণ সম্পর্কে প্রচলিত উত্তর প্রায়শই প্রয়োগ হয় না।"

তারপরে আমি উইন্ডোজ ফিজিক্যালডিস্কে ফাইলগুলি পৃথক করার এবং অতিরিক্ত ভিএইচবিএ যুক্ত করার এবং তাদের মধ্যে ফিজিক্যাল ডিস্ক বিতরণের সম্ভাব্য সুবিধাগুলি নিয়ে আলোচনা করব।

উইন্ডোজ ফিজিক্যালডিস্ক স্তরে এলোমেলো এবং অনুক্রমিক ডিস্ক আইও পৃথক করে উপকারের প্রত্যাশা সাধারণত ডেটা স্টোরেজের জন্য এইচডিডি ডিভাইসগুলি ধরে নেয়। এটি সাধারণত ধরে নেয় যে পৃথক উইন্ডোজ ফিজিডিডিস্কের অর্থ পৃথক এইচডিডি ডিভাইস। ধারণাটি হ'ল এইচডিডিগুলির কয়েকটি সেট মূলত সিক্যুয়াল ডিস্ক আইও পরিচালনা করছে এবং এতে খুব সীমাবদ্ধ ডিস্কের হেড মুভমেন্ট রয়েছে (যেমন এইচডিডিগুলি একক ব্যস্ত txlog * হোস্ট করছে) যখন এইচডিডিগুলির একটি পৃথক সেট এলোমেলো ডিস্ক আইও পরিচালনা করছে।

এই অনুমানগুলি আজ খুব কমই ধরা পড়ে - বিশেষত একটি ভিএম-তে। প্রথমত, যদি ভিএমএস উইন্ডোজ ফিজিক্যালডিস্কগুলি আরডিএম না হয়, তবে একাধিক একক ডেটাস্টোর হতে পারে - অথবা একাধিক ডাটাস্টোর একক ইএসসি হোস্ট LUN এ থাকতে পারে। তাই অতিথির মধ্যে যা আলাদা করা হয় তা ESXi হোস্ট স্তরে কম্যান্ড করা যায়।

তবে আসুন আমরা বলে নিই যে আরডিএম ব্যবহার করা হয়, বা প্রতিটি অতিথি ফিজিক্যালডিস্ক তার নিজস্ব ডেটাস্টোরে, তার নিজস্ব এসএসসি লুনে থাকে। তারপরেও, অতিথির মধ্যে এলোমেলো io থেকে পৃথক ক্রমবিন্যাস প্রায়শই অ্যারেতে উপস্থিত হয়, কারণ ESXi হোস্টকে উপস্থাপন করা LUN গুলি ডিস্ক ডিভাইসের একই একক পুল হতে পারে। প্রায় প্রতিটি স্টোরেজ অ্যারে এখন এটি করে - একচেটিয়াভাবে বা পরিচালনা সহজতর করার জন্য এবং অ্যারে দক্ষতা / সংস্থান ব্যবহার বাড়ানোর বিকল্প হিসাবে as

অবশেষে, আজ এত স্টোরেজ হয় সমস্ত ফ্ল্যাশ বা হাইব্রিড ফ্ল্যাশ + এইচডিডি। মাথা ঘামানোর বিষয়ে কোনও মাথাচাড়া দেওয়া না থাকলে, ফ্ল্যাশ এলোমেলোভাবে ক্রমিকের বিভাজন সম্পর্কে চিন্তা করে না ... এমনকি আইও বোনা সম্পর্কেও চিন্তা করে না।

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

* আমি উদ্দেশ্যমূলকভাবে এই এইচডিডি উদাহরণটিতে একটি একক লেনদেনের লগ উল্লেখ করেছি। যখন বিভিন্ন পৃথক অনুক্রমিক ডিস্ক আইও স্ট্রিমগুলি (যেমন 8 ব্যস্ত লেনদেন লগগুলি) একই এইচডিডি তে সঞ্চালিত হয় - যদি না কোনওভাবে প্রায় সমস্ত ক্রিয়াকলাপ সান ক্যাশে না থাকে - ক্রমবর্ধমান আইও ট্র্যাকগুলির মধ্যে ধ্রুবক মাথা চলাচল IO বুননের দিকে পরিচালিত করে। এটি একটি নির্দিষ্ট ধরণের ডিস্ক হেড থ্র্যাশিং যা ডিস্কের ল্যাটেন্সি যা "এলোমেলো থেকে খারাপ" বাড়ে। RAID5 এবং RAID10 এ ঘটে, যদিও RAID10 উল্লেখযোগ্য অবক্ষয়ের আগে RAID5 এর চেয়ে সামান্য কিছুটা ভিন্নতা সহ্য করতে পারে।


এখন - র্যান্ডম থেকে ক্রমকে আলাদা করা কীভাবে কার্যকর হতে পারে সে সম্পর্কে দীর্ঘকালীন আলাপচারিতায় - কীভাবে ফিজিক্যালডিস্কে ফাইল ছড়িয়ে দেওয়া এখনও সহায়তা করতে পারে? কীভাবে ভিএইচবিএ-র মধ্যে শারীরিক সংক্রমণ ছড়িয়ে দেওয়া সহায়তা করতে পারে?

এগুলি সবই ডিস্ক আইও সারিতে রয়েছে।

যে কোনও উইন্ডোজ ফিজিক্যালডিস্ক বা লজিক্যালডিস্কের পারফরম্যান দ্বারা "কারেন্ট ডিস্ক ক্যু" হিসাবে রিপোর্ট করা হয়েছে এমন সময়ে একবারে 255 টি পর্যন্ত বকেয়া ডিস্ক আইও থাকতে পারে। ফিজিক্যালডিস্ক সারিতে অসামান্য ডিস্ক আইও থেকে স্টোরপোর্ট 254 অবধি মিনিড্রাইভারে যেতে পারে। তবে মিনিড্রাইভারের একটি পরিষেবা সারি (পরবর্তী নিম্ন স্তরে নিচে নেমে আসা) এবং একটি ওয়েট সারি উভয়ই থাকতে পারে। এবং স্টোরপোর্টকে 254 থেকে যে সংখ্যাটি পাস হয় তা কম করতে বলা যেতে পারে।

একটি ভিএমওয়্যার উইন্ডোজ গেস্টে, পিভিএসসিসি ড্রাইভারের একটি ডিফল্ট "ডিভাইস" ক্যু গভীরতা 64৪, যেখানে ডিভাইসটি একটি ফিজিক্যাল ডিস্ক k সুতরাং যদিও পারফমন একক ফিজিক্যালডিস্কের জন্য "বর্তমান ডিস্কের সারি দৈর্ঘ্য" তে 255 ডিস্ক আইও প্রদর্শন করতে পারে তবে তাদের মধ্যে কেবলমাত্র 64 টি একযোগে পরবর্তী স্তরে পাস হবে (যদি না ডিফল্ট পরিবর্তন না হয়)।

কতটি ডিস্ক আইও একটির বকেয়া হতে পারেব্যস্ত লেনদেনে লগে এক সময়? ঠিক আছে, লেনদেন লগ লেখার আকার 60kb অবধি হতে পারে। উচ্চ স্কেল ইটিএল চলাকালীন, আমি প্রায়শই 60xb তে txlog- এ প্রতিটি লেখা দেখতে পাই। টিএক্সলগ লেখক একবারে এক টেক্সলগের কাছে k০ কেবি বকেয়া লিখে থাকতে পারে writes তাই, যদি আমি ডিফল্ট ভিএমওয়্যার সেটিংস সহ কোনও ব্যস্ত মঞ্চ txlog এবং একই শারীরিক সংক্ষেপে একটি ব্যস্ত DW txlog পেয়েছি? যদি উভয়ই টেক্সলগগুলি 32 টি বকেয়া 60 কেবিতে সর্বাধিক সন্ধান করে, তবে ফিজিক্যালডিস্কটি তার সারি গভীরতার ?৪ এর গভীরতায় রয়েছে Now এখন ... যদি শারীরিক সংক্রমণের জন্য ইটিএল উত্স হিসাবে ফ্ল্যাটফিলগুলিও থাকে? ভাল ... ফ্ল্যাটফিলগুলি পড়ার মধ্যে এবং টিএক্সলগ লিখেছেন, তাদের জন্য অপেক্ষা করার সারিটি ব্যবহার করতে হবে, কারণ একসাথে কেবল মাত্র 64 টি বেরিয়ে যেতে পারে। এর মতো ব্যস্ত txlogs সহ ডাটাবেসের জন্য, শারীরিক সার্ভার বা ভার্চুয়াল যাই হোক না কেন, আমি txlog এর নিজস্ব ফিজিক্যালডিস্কে সুপারিশ করি, ফিজিক্যালডিস্কের সাথে অন্য কিছুই নেই। এটি সেই স্তরে সারি বাঁধা রোধ করে এবং একাধিক ফাইলের ইন্টারলিভিংয়ের বিষয়বস্তু নিয়ে যে কোনও উদ্বেগ দূর করে (যা এই দিনগুলিতে অনেক বেশি, উদ্বেগ কম)।

একসাথে কতগুলি ডিস্ক আইওএস রো-ফাইলে বকেয়া থাকতে পারে (এসকিউএল সার্ভারের দৃষ্টিকোণ থেকে, অগত্যা নিম্ন স্তরে জমা দেওয়া হয় না)? নিজেই এসকিউএল সার্ভারে কোনও সীমা নেই (যেটি আমি খুঁজে পেয়েছি)। কিন্তু ফাইল অভিমানী একটি একক উইন্ডোজ physicaldisk (আমি SQL সার্ভার, অন্য সময় জন্য একটি বিষয় যে জন্য ডোরাকাটা গতিশীল ডিস্ক ব্যবহার করার প্রস্তাব না) চালু থাকে, তখন সেখানে হয় একটা সীমা। এটি আমি আগে উল্লেখ করেছি 255।

এসকিউএল সার্ভার রিডহেড এবং অ্যাসিনক্রোনাস আইও এর যাদুতে আমি সিরিয়াল ড্রাইভে প্রতিটি চলমান 4 সমবর্তী প্রশ্নগুলি 1200 এরও বেশি মোট "বর্তমান ডিস্কের সারি দৈর্ঘ্য" দেখেছি! 255 সীমাবদ্ধতার কারণে, এটি একটি ফিজিকালডিস্কের সমস্ত রোফিল বিষয়বস্তু দিয়েও সম্ভব নয়। এটি 8 টি ফাইল সহ একটি নিজস্ব ফাইলগ্রুপের বিরুদ্ধে ছিল, প্রতিটি নিজস্ব ফিজিক্যালডিস্কে।

সুতরাং রিডহেড রিডগুলি খুব আক্রমণাত্মক হতে পারে এবং আইও সারিতে চাপ দিতে পারে। তারা এতটা আক্রমণাত্মক হতে পারে যে অন্যান্য রোফিল ফাইলটি পড়ে অপেক্ষা করে শেষ করে। যদি লেনদেনের লগগুলি রো-ফাইলের মতো একই শারীরিক সংক্রমণের দিকে থাকে, একইসাথে রিডহেড পড়ার সময় এবং টিএক্সলগ লেখার জন্য অপেক্ষা করা খুব সহজ। এমনকি যদি সেই অপেক্ষাটি "বর্তমান ডিস্কের সারি দৈর্ঘ্য" স্তরে না থাকে তবে এটি ডিভাইস কাতারে অপেক্ষা করতে পারে (পিভিএসসিএসআই সহ ডিফল্টরূপে 64)।

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

Txlogs বিচ্ছিন্ন করার বিষয়ে বিবেচনা করার জন্য আরও একটি এসকিউএল সার্ভার আইও টাইপ রয়েছে: টেমপ্লেড থেকে ক্যোরি স্পিল। যখন কোয়েরি স্পিল হয় তখন প্রতিটি স্পিলিং কাজ করে টেম্পডিবিতে writes একই সাথে সমস্ত স্পিলিং করে প্রচুর সমান্তরাল কর্মী পেয়েছেন? এটি বেশ লেখার বোঝা হতে পারে। একটি ব্যস্ত txlog এবং এটি থেকে দূরে গুরুত্বপূর্ণ রোফফিলগুলি রাখা সত্যিই সহায়ক হতে পারে :-)

এখন, পিভিএসসিসি ড্রাইভারের জন্য ডিফল্ট ডিভাইস সারি গভীরতার পরিবর্তন করা সম্ভব। এটি ডিফল্ট 64৪ এ, এবং এটি সর্বোচ্চ ২৫4 হিসাবে সেট করা যেতে পারে যা সবচেয়ে স্টোরপোর্টটি পাস করবে। তবে এটি পরিবর্তন করতে সাবধান হন। আমি সর্বদা অন্তর্নিহিত ESXi হোস্ট LUN সারির গভীরতার সাথে অতিথি ডিভাইস কাতারের গভীরতা সারিবদ্ধ করার প্রস্তাব দিই। এবং অ্যারে সেরা অনুশীলন প্রতি ESXi হোস্ট LUN কিউ গভীরতা সেট করে। একটি EMC ভিএনএক্স ব্যবহার করছেন? হোস্ট LUN সারির গভীরতা 32 হওয়া উচিত? অতিথি আরডিএম ব্যবহার করেন? গ্রেট। অতিথি পিভিএসসিসি ডিভাইস কিউয়ের গভীরতা 32 তে সেট করুন যাতে এটি ESXi হোস্ট LUN কিউ গভীরতার সাথে একত্রিত হয়। ইএমসি ভিএমএক্স? সাধারণত ESXi হোস্ট স্তরে ,৪, অতিথি। খাঁটি / এক্সট্রেমিও / আইবিএম ফ্ল্যাশসিস্টেম? কখনও কখনও হোস্ট LUN কিউ গভীরতা 256 হিসাবে উচ্চ সেট করা হবে! এগিয়ে যান এবং পিভিএসসিসি ডিভাইস সারি গভীরতা তখন 254 (সর্বোচ্চ সম্ভব) সেট করুন।

নির্দেশাবলীর সাথে একটি লিঙ্ক এখানে। https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145

লিঙ্কটি রিকোয়ারিংপেজ সম্পর্কেও কথা বলেছে - কি কি ?? তারা পিভিএসসিসি অ্যাডাপ্টারের জন্য সারি গভীরতা নির্ধারণ করে। প্রতিটি পৃষ্ঠা অ্যাডাপ্টার সারি গভীরতায় 32 স্লট দেয়। ডিফল্টরূপে, অনুরোধ পৃষ্ঠাগুলি 256 এর অ্যাডাপ্টারের সারি গভীরতার জন্য 8 হয় 10 এটি 1024 অ্যাডাপ্টারের সারি গভীরতার স্লটের জন্য 32 হিসাবে সর্বোচ্চ সেট করা যায়।

আসুন যাক সবকিছু ডিফল্ট হয়। আমি তাদের উপর রোফাইলগুলি সহ 8 টি ফিজিক্যাল ডিস্ক পেয়েছি এবং এসকিউএল সার্ভার সামান্য ব্যস্ত। 8 টি জুড়ে গড়ে 32 টি "বর্তমান ডিস্কের সারি দৈর্ঘ্য" রয়েছে এবং কোনওটিই 64 এর চেয়ে বেশি নয় (সমস্ত কিছু বিভিন্ন ডিভাইস পরিষেবা কাতারে ফিট করে)। দুর্দান্ত - এটি 256 ওআইও দেয়। এটি ডিভাইস পরিষেবা কাতারে ফিট করে, এটি অ্যাডাপ্টার পরিষেবা কাতারে ফিট করে তাই সমস্ত 256 এটি অতিথি থেকে ESX হোস্ট স্তরের কাতারে তৈরি করে।

তবে… যদি জিনিসগুলি কিছুটা ব্যস্ত হয়, তবে কিছু দৈহিক ডিস্কের সারির গড় গড় 128 এর চেয়ে বেশি .৪ টির বেশি outstanding 8 টি ফিজিডিডিস্ক জুড়ে 256 টিরও বেশি ডিভাইসগুলির পরিষেবা সারিতে থাকলে, অ্যাডাপ্টার পরিষেবা সারিতে স্লট না খোলার পূর্ব পর্যন্ত ওভারেজ অপেক্ষার সারিতে থাকবে।

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

একটি পিভিএসসিসি অ্যাডাপ্টারে থাকাকালীন এবং অনুরোধকৃত পৃষ্ঠাগুলি বাড়িয়ে অনুরূপ কিছু অর্জন করা যেতে পারে। 16 এ যাওয়ার ফলে 512 স্লট এবং 32 ফলন হবে 1024 স্লট।

সম্ভব হলে, আমি গভীর (অ্যাডাপ্টারের সারি গভীরতা বৃদ্ধি) প্রস্থে যাওয়ার আগে প্রশস্ত (অ্যাডাপ্টার যুক্ত করা) প্রস্তাব দিই। তবে ... বেশিরভাগ ব্যস্ততম সিস্টেমে, উভয়ই করতে হবে: অতিথির উপর 4 ভিএইচবিএ রাখুন, এবং রিকোয়ারিংপেজগুলি 32 এ বাড়িয়ে দিন।

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

তবে আমি আমার স্বাগত: --) বাড়াতে চাই না

লনি নাইডারস্টাড @ এসকিউএল_হ্যান্ডলি

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