M365Con 2027 – مؤتمر مجاني عبر الإنترنت · 11–22 Jan 2027 · 120 sessions→ m365con.net

المدونة · Mirko Peters

Azure Elastic SAN مقابل Managed Disks مقابل Blob Storage: اختيار الأداة المناسبة

By ·

أهلاً بعودتكم إلى المدونة، حيث نتوسع في الحوارات التي نجريها على الهواء. قد يبدو التنقل في منظومة التخزين القوية في Azure أمراً محيراً عند تحديد المكان الذي تستضيف فيه بياناتك. سواء كنتم تصممون بنية سحابية جديدة أو توسعون بيئة مؤسسية قائمة، فإن فهم تفاصيل عروض التخزين في Microsoft Azure أمر بالغ الأهمية للأداء وكفاءة التكلفة معاً. اليوم نقارن Azure Elastic SAN مع Managed Disks وAzure Files وBlob S

Automatically translated with AI from the original post. Read the English original

Cover: Azure Elastic SAN — Simply Explained

أهلاً بعودتكم إلى المدونة، حيث نتوسع في الحوارات التي نجريها على الهواء. قد يبدو التنقل في منظومة التخزين القوية في Azure أمراً محيراً عند تحديد المكان الذي تستضيف فيه بياناتك. سواء كنتم تصممون بنية سحابية جديدة أو توسعون بيئة مؤسسية قائمة، فإن فهم تفاصيل عروض التخزين في Microsoft Azure أمر بالغ الأهمية للأداء وكفاءة التكلفة معاً. اليوم نقارن Azure Elastic SAN مع Managed Disks وAzure Files وBlob Storage لمساعدتكم على تحديد أفضل بنية لمتطلبات تطبيقكم المحددة.

إذا كنتم ترغبون في تعمق أكبر في هذه المفاهيم أثناء التنقل، فلا تفوتوا الحلقة البودكاست ذات الصلة، Azure Elastic SAN — Simply Explained، حيث نفصّل مبادئ بنية التخزين هذه بالتفصيل.

التنقل في منظومة التخزين في Azure

تقدم Azure مجموعة مثيرة للإعجاب من خدمات التخزين المصممة لأنواع البيانات وأنماط الوصول ومتطلبات الأداء المختلفة. ومع ذلك، ومع توسع بيئات السحابة، يصبح اختيار الأداة المناسبة أقل ارتباطاً باختيار الخيار الافتراضي وأكثر ارتباطاً بمطابقة خصائص أعباء العمل مع قدرات التخزين الأساسية. وعند النظر إلى Azure Managed Disks وBlob Storage وAzure Files وElastic SAN الأحدث، نجد أن كل خدمة مصممة لمعالجة تحديات تشغيلية وأدائية محددة.

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

لماذا تصبح الأقراص المنفصلة عنق زجاجة

تعمل Azure Managed Disks بشكل جيد جداً مع كثير من الأجهزة الافتراضية الفردية. بالنسبة إلى قاعدة بيانات واحدة أو خادم ويب مستقل، يكون توفير قرص مخصص أمراً مباشراً وموثوقاً. يظهر التحدي عندما تحتوي البيئات على عشرات أو مئات أعباء العمل، ولكل منها أنماط أداء مختلفة تماماً.

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

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

فهم IOPS والإنتاجية وحدود الأجهزة الافتراضية

لتصميم بنية تخزين مثالية، يجب أن ننظر بعناية إلى كيفية قياس الأداء. هناك مفهومان أساسيان يحكمان أداء تخزين السحابة: IOPS والإنتاجية.

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

أما الإنتاجية (Throughput) فتصف حجم البيانات التي يمكن نقلها خلال فترة زمنية محددة، وعادةً ما تُقاس بالميغابايت أو الجيجابايت في الثانية. تعتمد النسخ الاحتياطية الكبيرة لقواعد البيانات، ونقل الملفات بكميات كبيرة، ومعالجة الفيديو، وأحمال العمل التحليلية الثقيلة بدرجة كبيرة على الإنتاجية المستدامة أكثر من اعتمادها على IOPS وحدها. تتطلب أحمال العمل المختلفة مزيجًا مختلفًا تمامًا من هذين المقياسين، وإحداث التوازن بينهما ضمن حدود الأجهزة الافتراضية مسؤولية أساسية لأي مهندس سحابي.

ما هو Azure Elastic SAN؟

واجهت مراكز البيانات التقليدية في الموقع تحديات الأداء والتوسع المشابهة لعقود باستخدام شبكات التخزين المعروفة بـ SAN (Storage Area Networks). وبدلًا من منح كل خادم بنية تخزين مستقلة تمامًا، تُنشئ مراكز البيانات المؤسسية أنظمة تخزين مركزية يمكن للخوادم المتعددة الوصول إليها بأمان وكفاءة.

يجلب Azure Elastic SAN نموذج التخزين المشترك المألوف هذا مباشرةً إلى السحابة دون أن تضطر المؤسسات إلى شراء وحدات تحكم تخزين فعلية، أو تثبيت مصفوفات أجهزة، أو توصيل أرفف الخوادم، أو صيانة أجهزة SAN القديمة بنفسها. فـ Azure Elastic SAN هو خدمة تخزين كتل مُدارة في Azure مصممة بالكامل حول تجمع تخزين مشترك.

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

مقارنة بين Elastic SAN والأقراص المُدارة (Managed Disks) والتخزين Blob

لاختيار الأداة المناسبة لبيئتك، من المفيد فهم موقع Azure Elastic SAN بين خدمات التخزين البارزة الأخرى في محفظة Azure.

  • Azure Blob Storage: مصمم أساسًا لتخزين الكائنات غير المهيكلة. وهو الخيار الأمثل للصور ومقاطع الفيديو والمستندات غير المهيكلة وبحيرات البيانات والنسخ الاحتياطية الأرشيفية طويلة الأمد. يتوسع بشكل هائل ويقدم تكلفة منخفضة للغاية لكل جيجابايت، لكنه لا يوفر وصولًا منخفض زمن الاستجابة إلى تخزين الكتل المناسب لقواعد البيانات عالية الأداء.
  • Azure Files: يوفر مشاركات ملفات مُدارة بالكامل في السحابة، يمكن الوصول إليها عبر بروتوكولي Server Message Block (SMB) وNetwork File System (NFS) المعتمدين في الصناعة. وهو مثالي لعمليات ترحيل التطبيقات بالنقل المباشر (lift-and-shift) التي تتطلب وصولًا مشتركًا للملفات عبر أجهزة افتراضية متعددة.
  • Azure Managed Disks: توفر تخزين كتل موثوقًا وعالي الأداء مصممًا خصيصًا للأجهزة الافتراضية الفردية في Azure. وتظل الخيار الأبسط والأكثر فعالية عندما يحتاج جهاز افتراضي واحد إلى قرص تمهيد أو قرص بيانات مخصص به.
  • Azure Elastic SAN: يحتل موقعًا فريدًا كتخزين كتل مركزي عالي الأداء مصمم لأحمال العمل التي تستفيد من مشاركة تجمع تخزين أكبر. يوفر أداءً على مستوى الكتل مع مرونة تجميع الموارد مركزيًا، ليسد الفجوة بين حدود الأقراص لجهاز افتراضي واحد وإدارة التخزين على مستوى المؤسسة.

بنية Azure Elastic SAN

يساعد فهم طريقة تنظيم Azure Elastic SAN على توضيح كيفية إدارة المسؤولين للسعة والأداء على نطاق واسع. تقوم الخدمة على ثلاث طبقات تنظيمية أساسية: الـ SAN نفسه، ومجموعات الأحجام، والأحجام الفردية.

الـ SAN

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

مجموعات الأحجام

تُشكّل مجموعات وحدات التخزين حدًّا مهمًا للإدارة والأمان بين وحدات التخزين المرتبطة ببعضها. فعلى سبيل المثال، قد تُنشئ مؤسسة كبيرة مجموعةً لقواعد بيانات SQL Server الخاصة بالإنتاج، ومجموعةً أخرى لبيئات التطوير والاختبار، وثالثةً لأحمال العمل الدائمة في Azure Kubernetes Service (AKS).

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

وحدات التخزين

وحدات التخزين هي وحدات التخزين الفعلية التي تستهلكها الخوادم والتطبيقات. فقد تستخدم مثيلةُ SQL Server وحدةً لملفات قاعدة البيانات الأساسية، ووحدةً منفصلة تمامًا لسجلات المعاملات. وقد يستخدم تطبيقُ AKS وحدةً لتخزين بيانات التطبيق الدائمة. تظل كل وحدة مستقلة تمامًا ومعزولة منطقيًا، حتى وإن كانت عدة وحدات تشترك في البنية التحتية نفسها لشبكة SAN.

كيف يعمل نموذج الأداء المشترك

من أهم جوانب Azure Elastic SAN طريقةُ تعامله مع تخصيص الأداء. ففي إعدادات الأقراص المُدارة التقليدية يرتبط الأداء ارتباطًا وثيقًا بحجم القرص، إذ يُضطر المسؤول غالبًا إلى توفير قرص أكبر بكثير مما يحتاجه فعليًا إذا أراد مزيدًا من IOPS.

تُقدّم Azure Elastic SAN نموذج أداء مشتركًا. ووفقًا لمواصفات المنصة، تُسهم كل 1 TiB من السعة الأساسية بقدر محدد من الأداء، مثل 5,000 IOPS و200 ميغابايت في الثانية من الإنتاجية، في مجمع SAN. والأهم من ذلك أن هذا الأداء يتبع مجمع SAN نفسه، ولا يُحجز ولا يُخصَّص حصريًا لحمل عمل واحد.

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

تخيّل أنك تدير أربع قواعد بيانات SQL مختلفة في بيئتك. قاعدة بيانات المبيعات هي الأكثر نشاطًا خلال ساعات العمل العادية. وتُنتج المالية تقارير ثقيلة في نهاية الشهر. ويُنفّذ نظام المستودعات معالجة مكثفة خلال الليل. وتشهد قاعدة بيانات أخرى استيرادًا أسبوعيًا كبيرًا للبيانات. ومع الأقراص المُخصَّصة بشكل فردي، يجب تحجيم كل حمل عمل وفق أقصى طلب نظري يمكن أن يصل إليه. أما Elastic SAN فتسمح لتلك الوحدات بالسحب من مجمع أداء مشترك. فعندما تحتاج المالية إلى مزيد من IOPS بينما يكون نظام المستودعات هادئًا، يمكنها الاستفادة من هذه المساحة المتاحة. ومع مرور الوقت، ينتقل الأداء بشكل طبيعي نحو حمل العمل الأكثر طلبًا له.

بالطبع، الأداء المشترك ليس أداءً غير محدود. فإذا أصبحت عدة أحمال عمل نشطة للغاية في وقت واحد، وتجاوز طلبها المجمّع ما يمكن لشبكة SAN توفيره، فقد يتم تقييد الطلبات، ما يؤدي إلى زيادة زمن الاستجابة وانخفاض استجابة التطبيقات. لذلك يجب على المسؤولين أن يراقبوا الذروات المجمّعة للطلب باستمرار، للتأكد من أن مجمع SAN الأساسي مُهيّأ بالشكل الصحيح.

اختيار الأداة المناسبة لمتطلبات تطبيقك

يعتمد اختيار بنية التخزين المناسبة في Azure على تحليل بنية بيانات التطبيق، وبروتوكولات الوصول، وملف الأداء. فإذا كنت تُخزّن أصولًا وسائطية غير مهيكلة أو تبني بحيرة بيانات، فإن Azure Blob Storage خيار لا مثيل له. وإذا كنت تنقل تطبيقات قديمة تعتمد على مجلدات الشبكة المشتركة، فإن Azure Files هو الخيار الأفضل. أما لتطبيقات الجهاز الافتراضي الواحد البسيطة، فإن Azure Managed Disks تُبقي الأمور بسيطة وفعّالة.

غير أنه عندما تدير عناقيد كثيفة من قواعد البيانات، أو تطبيقات معبّأة في حاويات، أو بيئات متعددة الطبقات معقدة تعاني من حدود تخزين معزولة وميزانيات مُخصَّصة بالزيادة، فإن Azure Elastic SAN يُقدّم بديلًا معماريًا قويًا. فمن خلال تجميع السعة والأداء في نسيج تخزين كتلي مركزي، تستطيع المؤسسات تحقيق قدر أكبر من الكفاءة والمرونة والتحكم.

لاستكشاف هذا الموضوع بشكل أعمق والاستماع إلى نقاش موجّه حول كيفية تناسب هذه التقنيات مع بنى المؤسسات الحديثة، تأكّد من الاستماع إلى حلقة البودكاست المصاحبة لنا، Azure Elastic SAN — Simply Explained. إنّ تقييم استراتيجية التخزين لديك في ضوء هذه المبادئ سيضمن أن تظلّ بيئة Azure الخاصة بك سريعة وقابلة للتوسع وفعّالة من حيث التكلفة مع استمرار نمو مؤسستك.

Entities in this article

Azure Elastic SAN IOPS Azure Files Azure Disk Storage Microsoft Azure Virtual machine Azure Blob Storage

Related articles

RSS