انتقال SQL Server به یک پلت فرم مجازی

/
/
/

در این مقاله قصد داریم به نحوه انتقال SQL Server از یک محیط فیزیکی به یک محیط مجازی بپردازیم.
برای مدیران پایگاه اطلاعاتی، موضوع مجازی سازی یا Virtualization از جمله موضوع مهم محسوب می شود. در ابتدای پیدایش تکنیک مجازی سازی، SQL Server برای مجازی سازی مناسب به نظر نمی رسید. بهرحال، پلت فرم های مجازی تکامل پیدا کرده اند و مجازی سازی SQL Server یک عمل قابل قبول است. مجازی سازی در حال حاضر بخش مهم محیط های سازمانی محسوب می شود.
مجازی سازی همچنین نقش مهمی در یکپارچه سازی بخصوص در سازمان های بزرگ دارد. ماشین های مجازی(VMها) روشی را برای یکپارچه نمودن سرورهای فیزیکی کوچک در سرورهای کمی بزرگتر ارائه می دهند، ضمن اینکه تفکیک حجم های کاری همچنان حفظ می شود. یک روش موفق و آزمایش شده برای مجازی سازی این است که این کار را آرام آرام شروع کنید و پلت فرم مجازی خود را گسترش دهید. در صورتی که این روش با برنامه ریزی صحیح و استانداردها و تکنیک های خوب همراه باشد، می توانید یک انتقال موفق به VMها را تجربه کنید.
انتخاب روش مجازی سازی
مدیران پایگاه اطلاعاتی یا DBAها به روش های مختلف با ماشین های مجازی در محیط های خود کار می کنند. حجم های کاری غیربحرانی، سرورهای فوت پرینت کوچک و حتی حجم های کاری بحرانی تولید در پلت فرم های مجازی اجرا می شوند. برخی تصمیم گیری ها در مورد مجازی سازی به راحتی انجام می گیرند اما برخی دیگر مستلزم تامل و آزمایش دقیق هستند.

حجم های کاری غیر بحرانی
ابتدایی ترین و آسان ترین نوع اجراهای VM ، به حجم های کاری غیر بحرانی مربوط می شود. حجم های کاری غیر بحرانی به شما امکان می دهند تا کار را به آرامی و در مقیاس کم آغاز نمایند.
DBAهایی که مجازی سازی برای آن ها تازگی دارد، اغلب کار را با مجازی سازی SQL Serverهای توسعه ای، آزمایشی و غیر تولید آغاز می کنند. معمولاً برای این نوع محیط ها تحمل کاهش کارایی به دلیل کاهش هزینه های عملیاتی و مدیریت ساده تر قابل قبول است.
مجازی سازی حجم های کاری غیر تولید در مقایسه با حجم کاری مالی مانند گرفتن عکس آنی از محیط ها و تحویل سریع سرورهای جدید مزایایی به همراه دارد.
توانایی گرفتن عکس آنی یا اسنب شات از یک سرور در یک لحظه خاص، امکان آزمایش تغییرات مربوط به پیاده سازی (deployment) یا پیکربندی را فراهم می سازد و به سرعت آن را به موقعیت خوب و شناخته شده باز می گرداند. بازگرداندن محیط های پیچیده به یک موقعیت شناخته شده معمولاً ممکن است ساعت ها و حتی روزها بسته به اندازه محیط طول بکشد. این امر میتواند زمان لازم برای اجراهای چندگانه یک فرآیند آزمایشی را کاهش دهد.
یکی از چالش های کار با سرورهای فیزیکی این است که تحویل سرورها زمان زیادی طول می کشد. با محیط های فیزیکی، معمولاً باید پروژه هایی را طرح ریزی کنید که در ماه های ابتدایی به سرورهای جدید نیاز دارند. یک پلت فرم مجازی می تواند یک VM جدید را ظرف چند دقیقه تحویل نماید. ابزارهای اتومات سازی مانند System Center Orchestrator مایکروسافت کاری می کنند که rollout ماشین های مجازی جدید با SQL Server و نرم افزارهای لازم دیگر به سادگی کلیک کردن یک دکمه باشد.

سرورهای فوت پرینت کوچک
یکی از تصمیم گیری های ساده ای که در روزهای ابتدای مجازی سازی گرفته می شد، انتقال سرورهای تولید با فوت پرینت های بسیار کوچک به VMها بود. اکثر کسب و کارها دارای تعدادی اپلیکیشن داخلی هستند که باید از حجم های کاری دیگر مجزا شوند، چرا که حاوی اطلاعات مهمی مانند اطلاعات مالی و اطلاعات کارمندان می باشند. این اپلیکیشن ها اغلب دارای یک  user base (کاربرانی که از یک سرویس یا محصول استفاده می کنند) بسیار کوچک اما بسیار بحرانی برای دسترسی درساعات کاری بودند. همین طور این اپلیکیشن ها اغلب در سخت افزاری مستقر بودند که بسیار قدرتمندتر از حد نیاز بود. مثال دیگر یک سرور با حجم کاری کوچک، سرور بازیابی از فاجعه(DR) است که تنها برای اهداف DR استفاده می شود و همانند یک سرور failover با دسترسی بالا نیست.
یک راه متداول مجازی¬سازی سرورهای فوت پرینت کوچک، ادغام چندین نمونه SQL Server در سرور بیس¬(server base) مشابه است. این روش مستلزم مدیریت بسیار دقیق می باشد در غیر این صورت منجر به بروز مشکلات اساسی می شود. SQL Server بگونه ای طراحی شده تا خاطرنشان کند که مهمترین اپلیکیشن در سرور است و خود را نگران منبع مورد نیاز اپلیکیشن های دیگر نمی کند.
اگر قصد دارید به سراغ روش multi-instancing بروید، بسیار مهم است که نمونه های SQL Server را تا حد امکان جداسازی کنید. برای یک multi-instancing موفق در SQL Server به این نکته ها توجه کنید:
* هنگامیکه مقدار حافظه آزاد لازم را برای سیستم عامل و فرآیندهای non-buffer-pool محاسبه می کنید، سر بار اضافی SQL Server در حال اجرا را نیز در نظر بگیرید.
*  Max Server Memory را برای نمونه ها محدود کنید تا اطمینان حاصل شود که حافظه کافی برای هر نمونه وجود دارد و حافظه آزاد کافی هم باقی می ماند.
o    اگر در تخصیص حافظه ناموفق بودید، نشانه این است که تنظیم max memory به درستی پیکربندی نشده است.
* از درایوهای اختصاصی جدا برای هر نمونه SQL Server استفاده کنید تا مطمئن شوید که حجم کاری زیاد و ناگهانی IO در یک نمونه مانع عملکرد نمونه های دیگر نمی شود.
•    برای مدیریت CPU هر نمونه از Windows System Resource Manager استفاده کنید.
مجازی سازی هنوز هم مستلزم برنامه ریزی دقیق می باشد، اما ذاتاً تفکیک شده است و چیزهای زیادی وجود دارند که باید موقع اجرا با multi-¬instancing درVM ها درنظر بگیرید. شما چندین سرور را در بخش بزرگی از سخت افزار ادغام می کنید، در حالی که هر نمونه SQL در سیستم عامل مخصوص خودش خواهد بود. به هر VM بلوک حافظه و CPUی مخصوص خودش اختصاص داده شده و هر VM سیستم فایلی خود را در درایوهای سخت مجازی (VHD) دارد.
گرچه VMها دارای مقدار تفکیک شده توکار هستند، اما هنوز هم منابع مشابه ای را در سرور میزبان به اشتراک می گذارند و برای اجرای چندین VM به یک برنامه ریزی دقیق نیاز است تا اطمینان حاصل شود که یک VM نمیتواند سرباری را به سیستم وارد کند و منجر به ایجاد مشکلاتی برای VMهای دیگر در همان سرور میزبان شود.

حجم های کاری تولید
مایکروسافت و VMWare و همچنین فروشندگان مجازی کوچکتر دائما عملکرد پلت فرم مجازی را ارتقا می دهند. ظرف چندسال ذهنیت ما از این موضوع که VMها مناسب حجم های کاری تولید بحرانی نیستند به استفاده از VMها برای سیستم های تولید تراکنشی بسیار بحرانی تغییر یافت. پلت فرم به سرعت تکامل یافت و با رشد تولید در نرخ بالا سازگاری دارد.
همزمان با تکامل پلت فرم مجازی، علم مدیران مجازی ساز نیز در حال افزایش و تکامل بود. در ابتدا اشتباهات زیادی در خصوص پلت فرم های مجازی صورت می گرفت. اما این صنعت از آن اشتباهات درس گرفت و محصولات مجازی سازی و تکنیک های بهتری را برای اطمینان از یک اجرای موفق ارائه داد.
پلت فرم های مجاز می توانند حجم های بزرگی از CPUهای مجازی (vCPU) و حافظه را برای VMها فراهم کنند و همچنین گزینه های جدیدی برای قابلیت دسترسی ارائه دهند که بدون مجازی سازی امکان آن وجود ندارد. Hyper-V و VMWare هر دو تکنولوژی را برای انتقال یک VM زنده از یک سرور میزبان به سرور میزبان دیگر بدون زمان بیکاری ارائه می دهند. این امکان انتقال یک سرور زنده از میان سرور میزبان در Hyper-V مایکروسافت Live Motion و در VMWare، vMotion نام دارد.
با این ویژگی ترازهای بالای دسترسی در سطح VM ارائه می گردد بدون اینکه نیاز به منطق اضافی در SQL server یا تراز اپلیکیشن باشد.
تکنولوژی هایی مانند Windows Failover Clustering به نحوی توسعه یافته تا از مجازی سازی پشتیبانی کند و گزینه های متفاوتی را در جهت یکی کردن کلاسترینگ در طرح شما که قابلیت دسترسی بالای دارد ، ارائه نماید.
کلاسترینگ را میتوان برای میزبان VM یا در سطح VM که کلاسترینگ مهمان نام دارد، به اجرا در آورد. کلاسترینگ مهمان مستلزم آن است که تمام گره¬های(node)  VM در همان میزبان VM وجود داشته باشند. برخلاف کلاسترینگ متداول SQL Server ، کلاسترینگ مهمان SQL Server نقطه خرابی اجرا در یک سرور مجزا را حذف نمی کند و در برابر خرابی یک VM مجزا یا یک نمونه SQL Server از آن پشتیبانی می کند، اما اگر میزبان VM آفلاین شد، کل کلاستر آفلاین می شود. کلاسترینگ مهمان استقبال گسترده ای دریافت نکرده است، چون  پیچیدگی اجرای کلاسترینگ به مراتب بیشتر از مزایایی است که ارائه می دهد.
اگر قصد دارید یک سرور تولید بحرانی را از یک پلت فرم مجازی انتقال دهید، باید آزمایش کنید و مطمئن شوید که آن پلت فرم مناسب حجم کاری شما باشد. مهاجرت به یک VM به راحتی اختصاص دادن همان تعداد vCPU و همان مقدار رم سخت افزار فیزیکی به آن نیست. در اکثر موارد، ماشین مجازی یا همان VM، یک میزبان VM را با دیگر VMها به اشتراک می گذارد و باید بسیار دقت شود که حتما از بهترین تکنیک ها در این زمینه استفاده گردد. بعلاوه هر تغییری در پلت فرم باید قبل از قرار گرفتن در مرحله مصرف به خوبی مورد آزمایش قرار بگیرد و این مسئله در مورد زمانی که اولین بار انتقال به یک VM صورت می گیرد نیز صادق است.
بهترین تکنیک های مربوط به SQL Server در یک پلت فرم مجازی
وقتی نوبت اجرای SQL Server در یک پلت فرم مجازی می رسد، استفاده از بهترین تکنیک های مربوط به مجازی سازی به تنهایی کافی نیست. موارد دیگری وجود دارند که باید در خصوص SQL Server در نظر بگیرید که ممکن است در VMهایی که میزبان اپلیکیشن ها یا حجم کاری دیگری هستند، مورد استفاده قرار نگیرند. مثلا، گاهی اوقات احتصاص منابع بیشتر به VMهایی که از حجم کار گوناگون مثل اپلیکیشن های وب پشتیبانی می کنند خوب به نظر می رسد اما هرگز پیشنهاد نمی کنیم که اختصاص منابع بیشتر به SQL Server VMها صورت بگیرد.
حجم های کاری سبک یا غیربخرانی نیاز به استفاده از بهترین تکنیک ها را ندارد. در کل ما روی بهترین تکنیک ها در حجم های کاری تولید SQL Server تاکید داریم. تکنیک های زیر به داشتن یک پلت فرم مجازی برای نمونه های SQL Server  بحرانی تولید کمک می کنند.
* میزبان را به درستی پیکربندی کنید: مطمئن شوید که میزبان VM بدرستی برای کنترل و مدیریت حجم های کاری بزرگ پیکربندی شده باشد.
* High Performance Power Plan : طرح عملکرد بالا یا High Performance Plan را در میزبان VM و نیز در VM فعال کنید.
* برای صرفه جویی در هزینه برق، VMهایی که قادرند از یک طرح با مصرف برق متعادل تر در یک میزبان متفاوت استفاده کنند را جداسازی نمایید. VM های SQL Server هرگز نباید کاهش قدرت CPU را تجربه کنند.
* آرایه¬های درایو کافی یا LUNها در میزبان: مطمئن شوید که میزبان از آرایه های درایو کافی یا LUN برخوردار است. به این ترتیب سرورهای متفاوت می توانند در صورت نیاز در درایوهای جداگانه مستقر شوند.
* VMهای غیربحرانی یا کم فعالیت می توانند درایوهای میزبان را تا جایی که قابلیت های IO درایو اجازه می دهد به اشتراک بگذارند، اما تاثیرات IO و انتقال فایل ها باید تحت نظارت قرار بگیرد.
* فایل های بحرانی و پرفعالیت SQL Server VM نباید درایوها را در تراز میزبان به اشتراک بگذارند چرا که برای یک سیستم over-load شده بسیار آسان است تا سیستم های دیگر در همان درایو میزبان را تحت کنترل خود بگیرد.
* عدم تخصیص بیش از حد:به VMهای SQL Server بیش از حد منابع اختصاص ندهید.
* اگر به میزبان VM ، مجوز VMهای SQL Server نامحدود را می دهید به خاطر داشته باشید که Unlimited یا نامحدود فقط یک اصطلاح در اعطای گواهینامه است و در قابلیت های اصلی میزبان VM شما کاربرد ندارد.
* نظرات بر میزبان: بر تک تک VMها و همچنین میزبان VM نظارت داشته باشید. اگر مشکل اجرایی از طریق شمارنده های موجود در VM قابل توضیح نیست، نگاهی به شمارنده های موجود در میزبان VM بیاندازید.
* مثلا اگر مصرف پردازنده در میزبان VM بسیار بالاست، حتی یک VM کم مصرف می تواند علائم فشار بر پردازنده را کم کند گرچه شمارنده های محلی پردازنده ممکن است کم باشند.
* جداسازی انواع فایل های SQL Server در میزبان: بهترین تکنیک های SQL Server را با توجه به ذخیره سازی فایل¬های SQL Server VM دنبال کنید.
* فایل¬های VM(VHDs) مربوط به فایل های داده ای دیتابیس و فایل های لوگ باید در فایل های متفاوتی جداسازی شوند این فایل ها یکی پس از دیگری در درایوهای میزبان اختصاصی مختلف تفکیک می گردند.
* فایل¬های tempdb میزبانی کننده VHD باید جداسازی شوند.
* VHDهای مربوط به درایو پشتیبان باید جداسازی شوند.
* VHDهای مربوط به درایو سیستم و درایو نصب SQL (به ترتیب C و D) باید از VHDهای دیگر جدا شوند اما ممکن است با VHDهای دیگر درایو سیستم از VMهای دیگر در تراز میزبان، باهم میزبانی شوند.
* تمام فایل های SQL Server دیگری که شما در سیستم فیزیکی جداسازی می کنید، باید در تراز میزبان VM جداسازی شوند.
* جداسازی انواع فایل های SQL Server در VM: حتی اگر طرح اولیه، میزبانی فایل های VM در یک درایو ترکیبی در میزبان باشد، فایل های SQL Server همچنان باید در VHDهای محتلف جداسازی شوند. در اینصورت فایل ها میتوانند بدون پیکربندی مجدد VM یا SQL Server انتقال داده شوند.
* NIC Teaming : از NIC Teaming توکار ویندوز با قابلیت برگشت پذیری استفاده کنید تا حداکثر عملکرد و اطمینان پذیری از عملکرد شبکه حاصل شود.
o    فشرده سازی جریان TDS یا بسته های شبکه را در جهت کاهش بار شبکه سازی در نظر داشته باشید.
* از رایج ترین سیستم عامل استفاده کنید: ویندوز همچنان به حمایت های خود از پلت فرم های مجازی ادامه می دهد. گرچه عاقلانه است که همیشه از رایج ترین نسخه سیستم عامل استفاده کنید، اما این نکته در مورد پلت فرم های مجازی هم صادق است.
* استفاده از نسخه های قدیمی تر سیستم عامل در حجم های کاری کوچک فوت پرینت و غیربحرانی مشکلی ایجاد نمی کند اما اگر از سیستم عامل قدیمی برای حجم های کاری تولید بحرانی استفاده کنید دچار صدمه و آسیب خواهید شد.
* تخصیص منابع برای حجم های کاری SQL Server :  سرورهای بحرانی باید دارای منابع اختصاصی خودشان باشند. VMها را مجبور نکنید تا بر سر منابع با هم رقابت کنند.
* Memory Ballooning را غیرفعال نمائید : Memory Ballooning سعی می کند تا با فرستادن سیگنال های دروغی در مورد کمبود حافظه به  SQL Server و درخواست از آن برای آزاد  کردن حافظه، حافظه را بازپس بگیرد. در SQL Serverهای تولید بحرانی Ballooning باید غیرفعال باشد.
* Lock Pages in Memory را فعال کنید: کارشناسان مخالف موضوع اعطای مجوزهای Lock Pages in Memory به SQL Server در سرورهای فیزیکی هستند. در مورد سرورهای مجازی، مهم است که SQL Server بتواند صفحات را لاک کند، به این ترتیب می تواند خود را در برابر فشارهای خارجی حفظ کند.
* از مرزهای NUMA عبور نکنید: در معماری NUMA (دسترسی به حافظه غیر یکنواخت) حافظه  برای هر CPU محلی است. در صورتیکه لازم است از مرزهای NUMA برای دسترسی به حافظه مربوط به یک گره متفاوت عبور کنید، دچار افت کوچکی در عملکرد و اجرا می شوید. اگر تعداد vCPUهایی که شما اختصاص می دهید کمتر از تعداد CPUهای هر گره NUMA باشد، این تخصیص باید از یک گره مجزا بیاید. اگر لازم است چندین گره را اختصاص دهید، آن ها را در لایه VM به صورت گره های مجزای NUMA ارائه نمائید همانند آن هایی که در میزبان هستند.
* VHDهای استاتیک با اندازه ثابت: VHDهایی با اندازه ثابت تعیین کنید. برای فایل های SQL Server از دیسک های پویا یا دارای ذخیره کم  استفاده نکنید. SQL Server یک اپلیکیشن با IO دیسک بسیار سنگین است و انتظارهای مکرری را برای IO مطرح می کند، این در حالی است که ذخیره سازی که فضای مقرر شده را در دسترس قرار می دهد میتواند تاثیر بزرگی در عملکرد داشته باشد.
* وقتی شک دارید، آزمایش کنید: در مورد پیکربندی هایی که  از  تنظیم صحیح آنها مطمئن نیستید، قبل از رفتن به مرحله تولید آن ها را آزمایش نمائید.این توصیه بهترین تکنیک برای تمام چیزهای مربوط به SQL Server است.
* بهترین تکنیک های استاندارد SQL Server را دنبال کنید: برای پیکربندی SQL Server بهترین تکنیک های استاندارد را دنبال کنید. اگر VM و میزبان VM به درستی پیکربندی شوند، باید بتوانید SQL Server را به همان روشی که در سرور فیزیکی انجام می دهید، پیکربندی و حفظ نمائید.

نکاتی در مورد  مجوزدهی
مجوزدهی SQL Server یک موضوع پیچیده است. وقتی در مورد مجوزدهی SQL Server شک دارید، پیشنهاد می کنیم با یک حرفه ای در این زمینه تماس بگیرید تا مطمئن شوید که از اکثر استانداردها برخوردار هستید.
به واسطه پیچیدگی مجوزدهی SQL Server، تنها مولفه های کلیدی را عنوان می کنیم که مستقیما مربوط به SQL Server در یک پلت فرم مجازی می شوند.
علاوه بر مجوزدهی به ازای هر هسته در SQL Server که در SQL Server 2012 معرفی شد، مایکروسافت اخیراً تغییراتی را در قوانین مربوط به حقوق Failover در مورد SQL Server اعمال کرده است. طبق این تغییرات که با SQL Server 2014 معرفی شد، دیگر نمی توانید با صدور مجوز به یک سرور فعال، برای یک Failover غیرفعال مجوز رایگان دریافت کنید. حقوق Failover در حال حاضر مستلزم (SA) Software Assurance است که با SQL Server 2012 آغاز شد، حقوق موبیلیتی مستلزم توافقنامه SA است.
مجوزدهی VM و مجوزدهی Server
خارج از سناریوهای خاصی که ممکن است بخواهید از Server و Clients Access License(CALs) استفاده کنید، دو روش اصلی برای مجوزدهی به SQL Server در VM وجود دارد. شما میتوانید در VM های SQL Server نامحدود به تعداد کل هسته ها در میزبان VM مجوز صادر کنید یا میتوانید به VMهای فردی به ازای تعداد هسته هایی که به آن ها ارائه می شوند، مجوز بدهید.
مزایای مجوز دادن به تمام هسته ها در میزبان VM آن است که مدیریت مجوزهای SQL Server بسیار آسان تر می شود. شما میتوانید VMها را از سروری به سرور دیگر منتقل کنید، بسازید و خراب کنید، بدون آنکه نیاز به ردیابی مجوزهای فردی باشد. این شامل حقوق انتقال یک VM از یک سرور به سرور دیگر با استفاده از vMotion یا Live Migration است، بدون خریدن مجوزهای اضافی تا زمانیکه تمام میزبان¬های درگیر به ازای تمام هسته ها مجوز داشته باشند.
مجوزدهی به تمام هسته های میزبان مستلزم مجوز دهی به Enterprise Edition و Software Assurance (SA) است. گرچه حقوق نسخه های پایین تر یا downgrade rights به شما امکان می دهد تا Standard Edition را تحت این مدل اجرا کنید، اما باید برای دادن مجوزهای Enterprise Edition پول بپردازید. پر واضح است که تنها می توانید از این گزینه تحت شرایط زیر استفاده نمایید:
•    باید از نسخه Enterprise Edition ،SQL Server استفاده نمایید .
* میزبان به VM هایی اختصاص می یابد که تنها SQL Server را اجرا می کنند. استفاده از آن در حجم های کاری غیر SQL Server برای مجوزهای هسته ای بسیار پرهزینه خواهد بود.
یکی از مزیت های بزرگ صدور مجوز فردی به هر VM این است که شما می توانید برای هر VM، مجوز Standard Edition یا Enterprise Edition صادر کنید.
ایراد اصلی صدور مجوز فردی به هرVM این است که باید به حداقل ۴ هسته یک سرور مجوز بدهید. اگر نمونه های فوت پرینت یا SQL Server  غیر بحرانی بسیار زیاد و کوچکی دارید که تنها به یک هسته نیاز دارند، باید حداقل مجوزهای چهارهسته ای را برای هر VM خریداری کنید.
هنگام در نظر گرفتن گزینه صدور مجوز به هر VM ، نکات کلیدی زیر را به خاطر بسپارید:
* مجوزهای VM مستقیماً به سرور میزبان VM مرتبط می شوند. اگر یک VM به میزبان دیگری مهاجرت کند، مجوزهای SQL همراه با سرور منتقل نمی شوند و VM باید در سرور جدید مجداً مجوز بگیرد.
* حقوق موبیلیتی با Software Assurance (SA) یا بیمه نرم افزار منتقل می شود. اگر دارای توافقنامه SA هستید، مجوزهای مربوط به VM را می توان با VM انتقال داد.
* VM هایی که با استفاده از مدل per-core بطور مجزا مجوز می گیرند می توانند در همان میزبان VM، با VM های SQL Server ادغام شوند.
* فرا ریسمانی (Hyper threading) در مجوز دهی فردی VM رایگان است.هنگام استفاده از فناوری فراریسمانی شما تنها مجوزهای هسته را به تعداد رشته های اجرایی (thread) خریداری می کنید. شما در قبال مجوزهای اضافی مربوط به رشته های اجرایی اضافی که در نتیجه فراریسمانی دیده می شوند، چیزی نمی پردازید.
واضح است که مدل مجوزدهی پیش فرض برای مجوز دادن به VM ها باید مدل مجوزدهی فردی VM باشد. صدور مجوز به میزبان VM بازای تمام هسته ها، یک روش گرانقیمت در مجوزدهی VM هاست و تنها برای موقعیت هایی مناسب است که شما باید از تمام هسته ها برای اجرای VMهای SQL Server تحت Enterprise Edition استفاده نمایید.

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

—————–

برگردان : مهسا قنبری

نظر بدهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

It is main inner container footer text