خادم SQL الظاهري:ولم لا؟

Question

يحاول قسم تكنولوجيا المعلومات الذي أعمل فيه الانتقال إلى خوادم افتراضية بنسبة 100%، مع تخزين جميع البيانات على شبكة SAN.لم يفعلوا ذلك بعد، لكن الخطة تدعو في النهاية إلى نقل أجهزة SQL Server الفعلية الحالية إلى الخوادم الافتراضية أيضًا.

منذ بضعة أشهر حضرت حدث إطلاق Heroes Happen Here، وفي إحدى جلسات SQL Server ذكر المتحدث بشكل عابر أن هذه ليست فكرة جيدة لأنظمة الإنتاج.

لذلك أنا أبحث عن بعض الأشياء:

1. ما هي الأسباب المحددة التي تجعل هذه الفكرة جيدة أو غير جيدة؟أحتاج إلى مراجع، أو لا تكلف نفسك عناء الرد.يمكنني التوصل إلى استجابة غامضة "مقيدة بالإدخال/الإخراج" بنفسي عبر Google.
2. ربما لن تقنع ذكريات المتحدثين في HHH وحده قسم تكنولوجيا المعلومات لدينا بتغيير رأيه.هل يمكن لأي شخص أن يوجهني مباشرة إلى شيء أكثر موثوقية؟وأعني بكلمة "مباشرة" شيئًا أكثر تحديدًا من مجرد تعليق غامض على موقع Books Online.يرجى تضييق نطاقه قليلا.

Answer 1

أستطيع أن أقول هذا من خلال تجربتي الشخصية لأنني أتعامل مع هذه المشكلة بالذات بينما نتحدث.المكان الذي أعمل فيه حاليًا كمقاول لديه هذا النوع من البيئة لأنظمة تطوير SQL Server الخاصة بهم.أحاول تطوير B.I متواضع إلى حد ما.النظام في هذه البيئة ويكافح حقًا مع مشكلات الأداء.

تكون أخطاء TLB وعمليات الإدخال/الإخراج التي تمت محاكاتها بطيئة جدًا على جهاز ظاهري ساذج.إذا كان نظام التشغيل/النظام الخاص بك يتمتع بدعم شبه افتراضي (والذي لا يزال غير ناضج على نظام التشغيل Windows)، فإنك تستخدم الإدخال/الإخراج شبه الظاهري (في الأساس برنامج تشغيل الجهاز الذي يرتبط بواجهة برمجة التطبيقات في الجهاز الافتراضي).تتمتع الإصدارات الحديثة من Opteron بدعم جداول الصفحات المتداخلة، مما يلغي الحاجة إلى محاكاة MMU في البرنامج (وهو بطيء حقًا).

وبالتالي، فإن التطبيقات التي تعمل على مجموعات كبيرة من البيانات وتقوم بالكثير من عمليات الإدخال/الإخراج مثل (على سبيل المثال) عمليات ETL تتعثر في كعب أخيل للمحاكاة الافتراضية.إذا كان لديك أي شيء مثل نظام مستودع البيانات الذي قد يكون صعبًا على الذاكرة أو إدخال/إخراج القرص، فيجب عليك التفكير في شيء آخر.بالنسبة لتطبيق معاملات بسيط، فمن المحتمل أن يكونوا على ما يرام.

ضع في الاعتبار أن الأنظمة التي أستخدمها تعمل على شفرات (خادم IBM) على شبكة SAN مع وصلات F/C 4x 2 جيجابت.هذه شبكة SAN متوسطة المدى.يحتوي VM على ذاكرة وصول عشوائي (RAM) سعة 4 جيجابايت IIRC والآن وحدتي معالجة مركزية افتراضيتين.في أفضل حالاتها (عندما تكون شبكة SAN هادئة) لا تزال هذه السرعة نصف سرعة شبكة SAN الخاصة بي فقط XW9300, ، الذي يحتوي على 5 أقراص SCSI (النظام، وtempdb، والسجلات، والبيانات، والبيانات) على ناقل U320 واحد وذاكرة وصول عشوائي (RAM) سعة 4 جيجابايت.

قد يختلف عدد الأميال الخاصة بك، لكنني أوصي باستخدام أنظمة محطات العمل مثل تلك التي وصفتها لتطوير أي شيء ثقيل الإدخال/الإخراج بدلاً من الخوادم الافتراضية على شبكة SAN.ما لم تكن متطلبات استخدام الموارد الخاصة بك تتجاوز هذا النوع من الأدوات (وفي هذه الحالة فهي تتجاوز بكثير الخادم الظاهري على أي حال) فهذا حل أفضل بكثير.الأجهزة ليست باهظة الثمن - وبالتأكيد أرخص بكثير من شبكة SAN والهيكل النصلي وترخيص VMWare.يأتي إصدار مطور SQL Server مع V.S.برو وما فوق.

وهذا أيضًا له فائدة تتمثل في أن فريق التطوير الخاص بك مجبر على التعامل مع النشر مباشرةً من البداية - عليك أن تتوصل إلى بنية يسهل نشرها "بنقرة واحدة".هذا ليس صعبا كما يبدو. Redgate SQL قارن برو هو صديقك هنا.يحصل مطوروك أيضًا على معرفة عملية أساسية بإدارة قواعد البيانات.

رحلة سريعة إلى موقع HP حصلت لي على قائمة أسعار تبلغ حوالي 4600 دولار لجهاز XW8600 (طرازهم الحالي المستند إلى xeon) المزود بشريحة xeon رباعية النواة وذاكرة وصول عشوائي (RAM) سعة 4 جيجابايت وأقراص ثابتة SAS سعة 1x146 و4x73 جيجابايت و15 كيلو بايت.من المحتمل أن يكون سعر الشارع أقل إلى حد ما.قارن هذا بسعر ترخيص SAN والهيكل النصلي وVMware وتكلفة النسخ الاحتياطي لهذا الإعداد.بالنسبة للنسخ الاحتياطي، يمكنك توفير مشاركة عبر الشبكة مع النسخ الاحتياطي حيث يمكن للأشخاص إسقاط ملفات النسخ الاحتياطي المضغوطة لقاعدة البيانات عند الضرورة.

يحرر: هذه الوثيقة البيضاء موجودة على موقع الويب الخاص بشركة AMD يناقش بعض المعايير على VM.من خلال المعايير الموجودة في الخلف، فإن عبء العمل الثقيل للإدخال/الإخراج وMMU يعيق أداء الأجهزة الافتراضية.يقترح معيارهم (الذي يجب أن يؤخذ بحذر لأنه إحصائية مقدمة من البائع) عقوبة سرعة 3.5x على معيار OLTP.بينما يتم توفير هذا من قبل البائع، يجب على المرء أن يأخذ في الاعتبار:

• إنه يعيّن المحاكاة الافتراضية الساذجة ويقارنه بمحلول مادي ، وليس أداءً معادنًا.

• سيكون لمعيار OLTP عبء عمل I/O أكثر عشوائيًا ، وسوف يقضي المزيد من الوقت في انتظار البحث عن القرص.سيكون للنمط الأكثر تسلسلًا للوصول إلى القرص (مميزة لاستعلام مستودعات البيانات) عقوبة أعلى ، وستتحمل العملية الثقيلة للذاكرة (SSAs ، على سبيل المثال ، خنزير ذاكرة الكتاب المقدس) الذي يحتوي على عدد كبير من الأخطاء TLB .هذا يعني أن التباطؤ في هذا النوع من المعالجة قد تكون أكثر وضوحًا من عقوبة OLTP المعيارية المذكورة في الورقة البيضاء.

ما رأيناه هنا هو أن TLB يخطئ وأن عمليات الإدخال/الإخراج باهظة الثمن على جهاز افتراضي.إن البنية الجيدة مع برامج التشغيل شبه الافتراضية ودعم الأجهزة في MMU سوف تخفف من بعض أو كل هذا.ومع ذلك، أعتقد أن Windows Server 2003 لا يدعم المحاكاة الافتراضية على الإطلاق، ولست متأكدًا من مستوى الدعم المقدم في خادم Windows 2008.لقد كانت تجربتي بالتأكيد أن الجهاز الافتراضي سوف يبطئ الخادم بشكل جذري عند العمل على عملية ETL وبناء مكعب SSAS مقارنة بالأجهزة المعدنية العارية ذات المواصفات المتواضعة نسبيًا.

Answer 2

SAN - بالطبع، والتجميع، ولكن فيما يتعلق بالمحاكاة الافتراضية - سوف تحصل على نتيجة أداء (قد تكون أو لا تستحق ذلك بالنسبة لك):

http://blogs.technet.com/andrew/archive/2008/05/07/virtualized-sql-server.aspx

http://sswug.org كان لديهم بعض الملاحظات حول هذا الموضوع في رسالتهم الإخبارية اليومية مؤخرًا

Answer 3

أردت أن أضيف هذه السلسلة من المقالات بقلم برنت أوزار:

• لماذا يريد مسؤول النظام الخاص بك جعل خوادمك افتراضية؟
• لماذا تقوم بمحاكاة SQL Server افتراضيًا؟
• أسباب عدم ضرورة تفعيل SQL Server افتراضيًا

ليس بالضبط موثوق بالمعنى الذي كنت أتمناه (أن يأتي من الفريق الذي يبني الخادم، أو من دليل رسمي من نوع ما)، لكن برنت أوزار يحظى باحترام كبير وأعتقد أنه يقوم بعمل رائع في تغطية جميع القضايا هنا.

Answer 4

نحن ندير نظام كشوف المرتبات لأكثر من 900 شخص على برنامج VMWare دون أي مشاكل.لقد كان هذا في الإنتاج لمدة 10 أشهر.إنه حمل متوسط ​​الحجم فيما يتعلق بقاعدة البيانات، وقد قمنا بتخصيص مساحة محرك الأقراص مسبقًا في VM لمنع مشكلات الإدخال/الإخراج.يجب عليك إلغاء تجزئة كل من VM Host وشريحة VM بشكل منتظم من أجل الحفاظ على الأداء المقبول.

Answer 5

إليك بعض اختبارات VMWARE عليه..http://www.vmware.com/files/pdf/SQLServerWorkloads.pdf

من المؤكد أنهم لا يقارنونها بالآلات المادية.ولكن ربما يمكنك إجراء اختبار مماثل باستخدام الأدوات المستخدمة في بيئتك.

نقوم حاليًا بتشغيل SQL Server 2005 في بيئة VMWARE.ولكنها قاعدة بيانات محملة بشكل خفيف للغاية وهي رائعة.يعمل دون أي مشاكل.

كما أشار معظم الناس، سيعتمد ذلك على تحميل قاعدة البيانات لديك.

ربما يمكنك إقناع قسم تكنولوجيا المعلومات بإجراء بعض الاختبارات الجيدة قبل التنفيذ الأعمى.

Answer 6

لا، لا يمكنني الإشارة إلى أي اختبارات محددة أو أي شيء من هذا القبيل، ولكن يمكنني القول من خلال تجربتي أن وضع خادم قاعدة بيانات الإنتاج الخاص بك على جهاز افتراضي يعد فكرة سيئة، خاصة إذا كان به حمل كبير.

إنه جيد للتنمية.ربما حتى الاختبار (على النظرية القائلة بأنه إذا كان يعمل بشكل جيد تحت التحميل على الصندوق الافتراضي، فسوف يعمل بشكل جيد على المنتج) ولكن ليس في الإنتاج.

إنه أمر منطقي حقًا.هل تريد أن يعمل جهازك بنظامي تشغيل وخادم SQL الخاص بك أو نظام تشغيل واحد وخادم SQL؟

يحرر:تجربتي متحيزة ردي.لقد عملت مع قواعد بيانات كبيرة تحت حمل ثابت ثقيل.إذا كانت لديك قاعدة بيانات أصغر تحت التحميل الخفيف، فقد تعمل المحاكاة الافتراضية بشكل جيد بالنسبة لك.

Answer 7

هناك بعض المعلومات حول هذا في كونور كننغهام مقالة مدونة المحاكاة الافتراضية لقواعد البيانات - السر الصغير القذر الذي لا يتحدث عنه أحد....يقتبس:

من المثير للدهشة أن هناك معرفة قليلة داخل الخادم نفسه بالكثير من الأشياء في هذا المجال والتي تعتبر مهمة للأداء.يفترض المحرك الأساسي لـ SQL Server أشياء مثل:

1. جميع وحدات المعالجة المركزية (CPUs) متساوية في القوة
2. تقوم جميع وحدات المعالجة المركزية (CPUs) بمعالجة التعليمات بنفس المعدل تقريبًا.
3. من المحتمل أن يحدث التدفق إلى القرص خلال فترة زمنية محدودة.

ويستمر المنشور في توضيح هذه القضايا بشكل أكبر إلى حد ما أيضًا.أعتقد أنها قراءة جيدة بالنظر إلى ندرة المعلومات المتاحة فيما يتعلق بهذه القضية بشكل عام.

Answer 8

لاحظ أن هناك بعض منتجات المحاكاة الافتراضية المتخصصة التي تم تصميمها لقواعد البيانات التي قد تستحق البحث فيها بدلاً من منتج عام مثل VMWare.

شركتنا (أكثر من 200 خادم SQL) قيد النشر حاليًا اتش بي بوليسيرف على بعض خوادمنا:

يتيح برنامج HP PolyServe لـ Microsoft SQL Server دمج مثيلات Microsoft SQL Server المتعددة في عدد أقل بكثير من الخوادم ووحدة تخزين SAN المركزية.توفر بنية "البيانات المشتركة" الفريدة من HP PolyServe توفرًا على مستوى المؤسسات ومرونة تشبه المحاكاة الافتراضية في النظام الأساسي للأدوات المساعدة.

السبب الرئيسي لنشره هو تسهيل استبدال الأجهزة:أضف المربع الجديد إلى "المصفوفة"، وقم بالتبديل بين مكان وجود كل مثيل SQL (بسلاسة)، ثم قم بإزالة المربع القديم.شفاف لفرق التطبيق، لأن أسماء مثيلات SQL لا تتغير.

Answer 9

سؤال قديم بإجابات قديمة

الإجابات في هذا الموضوع عمرها سنوات.معظم النقاط السلبية في هذا الموضوع بأكمله لا تزال صحيحة من الناحية الفنية ولكنها أقل أهمية بكثير.أصبحت التكلفة العامة للمحاكاة الافتراضية وشبكات SAN عاملاً أقل بكثير الآن مما كانت عليه من قبل.يمكن لمضيف المحاكاة الافتراضية والضيف والشبكة وشبكة SAN التي تم تكوينها بشكل صحيح توفير أداء جيد مع فوائد المحاكاة الافتراضية والمرونة التشغيلية بما في ذلك سيناريوهات الاسترداد الجيدة التي يتم توفيرها فقط من خلال كونها افتراضية.

ومع ذلك، في العالم الحقيقي، لا يتطلب الأمر سوى تفاصيل تكوين بسيطة واحدة لجعل الأمر برمته على ركبتيه.من الناحية العملية، فإن التحدي الأكبر الذي تواجهه مع خوادم SQL الافتراضية هو الإقناع والعمل مع الأشخاص المسؤولين عن المحاكاة الافتراضية لإعدادها بشكل صحيح.

ومن المفارقات، أنه في 100 بالمائة من الحالات التي قمنا فيها بإخراج الإنتاج من المحاكاة الافتراضية وأعدناه مرة أخرى إلى أداء الأجهزة المخصصة، تجاوزنا الحد الأقصى على الأجهزة المخصصة.في كل هذه الحالات، لم يكن الأمر يتعلق بالمحاكاة الافتراضية، بل بالطريقة التي تم بها الإعداد.من خلال العودة إلى الأجهزة المخصصة، أثبتنا بالفعل أن المحاكاة الافتراضية كانت ستؤدي إلى استخدام أفضل بكثير للموارد بمعامل 5 أو أكثر.عادةً ما يتم تصميم البرامج الحديثة للتوسع عبر العقد بحيث تعمل المحاكاة الافتراضية لصالحك على هذه الجبهة أيضًا.

Answer 10

أكبر ما يقلقني عندما يكون ترخيص برامج المحاكاة الافتراضية هو عادةً.

إليك مقالة عنه لـ MS SQL.لست متأكدًا من موقفك لذا لا يمكنك اختيار أي نقاط بارزة.

http://www.microsoft.com/sql/howtobuy/virtualization.mspx

Answer 11

يتم دعم SQL Server في بيئة افتراضية.في الواقع، أوصي برؤية أن أحد خيارات الترخيص يكون لكل مأخذ توصيل.هذا يعني أنه يمكنك وضع أكبر عدد ممكن من مثيلات SQL Server في بيئة افتراضية (على سبيل المثال.Windows 2008 Server Datacenter) حسب رغبتك وادفع فقط لكل مقبس معالج موجود في الجهاز.

إنه أفضل من ذلك لأن DataCenter مرخص لكل مقبس مع تراخيص غير محدودة للأجهزة الافتراضية أيضًا.

أوصي بتجميع جهاز Hyper-V الخاص بك على جهازين، ومع ذلك، إذا فشل أحدهما، يمكن للآخر أن يعوض الركود.

Answer 12

أعتقد أن احتمال حدوث شيء سيئ للبيانات سيكون كبيرًا جدًا.

كمثال بسيط للغاية، لنفترض أنك قمت بتشغيل مربع SQL Server في Virtual Server 2005 R2 وتم تشغيل أقراص التراجع (وبالتالي، يظل ملف "القرص" الرئيسي كما هو ويتم إجراء جميع التغييرات على ملف منفصل يمكن إزالته أو دمجها لاحقا).ثم يحدث شيء ما (عادةً، تصل إلى الحد الأقصى البالغ 128 جيجابايت أو أيًا كان الحجم) ويتعين على بعض المشرفين الجاهلين في منتصف الليل إعادة التشغيل ويكتشف أنه لا يمكنه القيام بذلك حتى يزيل أقراص التراجع.لقد أخطأت - حتى لو احتفظ بملفات قرص التراجع لتحليلها لاحقًا، فإن احتمالات دمج البيانات معًا ضئيلة جدًا.

لذا، فإن تكرار المشاركات الأخرى في هذا الموضوع - يعد أمرًا رائعًا للتطوير ولكنه ليس فكرة جيدة بالنسبة للإنتاج.يمكن إعادة بناء التعليمات البرمجية الخاصة بك وإعادة نشرها (وهذا شيء آخر، فالأجهزة الافتراضية للتحكم في المصدر ليست فكرة جيدة أيضًا) ولكن بيانات الإنتاج المباشر الخاصة بك أكثر أهمية بكثير.

Answer 13

يجب أيضًا مراعاة المشكلات الأمنية التي يمكن تقديمها عند التعامل مع التنشيط. أمن المحاكاة الافتراضية هي مقالة جيدة كتبها PandaLabs والتي تغطي بعض المخاوف.

Answer 14

أنت تنظر إلى هذا من الزاوية الخاطئة.أولاً، لن تجد مستندات تقنية من البائعين لماذا يجب عليك "عدم" المحاكاة الافتراضية أو لماذا يجب عليك المحاكاة الافتراضية.

تختلف كل بيئة عن الأخرى وتحتاج إلى القيام بما ينجح في بيئتك.ومع ذلك، هناك بعض الخوادم المثالية للمحاكاة الافتراضية، وهناك بعض الخوادم التي لا ينبغي أن تكون افتراضية.على سبيل المثال، إذا كان خادم/خوادم SQL الخاصة بك تقوم بملايين وملايين المعاملات في الثانية، كما لو كان خادمك موجودًا في بورصة نيويورك أو ناسداك وتعتمد عليه ملايين وملايين الدولارات، فمن المحتمل ألا تجعله افتراضيًا.تأكد من أنك تفهم تداعيات المحاكاة الافتراضية لخادم SQL.

لقد رأيت أين يقوم الأشخاص بمحاكاة SQL مرارًا وتكرارًا لمجرد أن المحاكاة الافتراضية رائعة.ثم قم بالشكوى لاحقًا عندما لا يعمل خادم VM كما هو متوقع.

ما عليك القيام به هو وضع معيار واختبار الحل الذي تريد نشره بشكل كامل وإظهار ما يمكنه فعله وما لا يمكنه فعله حتى لا تواجه أي مفاجآت.تعد المحاكاة الافتراضية رائعة، وهي مفيدة للبيئة وتوفر من خلال الدمج، ولكن عليك أن توضح لماذا لمشرفيك لماذا لا ينبغي عليك إجراء محاكاة افتراضية لخوادم SQL الخاصة بك وأنت وحدك من يمكنه القيام بذلك.