مجازی سازی در FC SAN
در ابتدا با دو مفهوم NPIV و NPV در مجازی سازی شبکه FC بیشتر آشنا می شویم.
N_Port ID Virtualization (NPIV)
با استفاده از این قابلیت می توانیم برای مثال یک پورت کارت HBA را به چند پورت مجازی تبدیل کنیم و آنها را به ماشین های مجازی اختصاص دهیم. هر پورت مجازی دارای یک آدرس منحصر به فرد WWPN است و در نتیجه هر پورت یک FC address نیز دریافت می کند. در نتیجه در سمت سوئیچ خواهیم دید که یک پورت فیزیکال دارای چند FC address است.
با استفاده از این قابلیت مدیران شبکه می توانند دسترسی به یک Lun را با استفاده از تکنیک هایی مانند Lun masking و Zoning ، محدود به یک ماشین مجازی خاص کنند، در صورتی که اگر از این روش استفاده نکنیم تنها می توانیم دسترسی را در سطح یک سرور تعیین کنیم و نه در سطح ماشین های داخل آن. برای اینکه بتوانیم از این روش استفاده کنیم، هم کارت HBA و هم سوئیچ می بایست از NPIV پشتیبانی نمایند.
البته در این روش کارت HBA با آدرس WWN مخصوص به خود باید بتواند به تمامی Lun هایی که ماشین های مجازیش باید دسترسی داشته باشند، دسترسی داشته باشد.
N_Port Virtualization (NPV)
سوئیچ هایی که از این قابلیت پشتیبانی می کنند، قادرند که در حالت pass-through کار کنند. به عبارت بهتر فقط ترافیک را می گیرند و سپس رد می کنند. اما چه زمانی نیاز به استفاده از این قابلیت داریم؟
در زمانی که از توپولوژی Edge-Core استفاده می نماییم و شبکه دائما در حال رشد است، با اضافه کردن هر سوئیچ edge تعداد Domain ID ها بیشتر می شود و در بلندمدت این مساله ممکن است باعث نگرانی بشود زیرا تعداد این دومین آی دی ها دارای محدودیت است. NPV روشی است که این مشکل را حل کرده و تعداد این دومین آی دی ها را کاهش می دهد.
سوئیچ هایی که از NPV پشتیبانی می کنند دیگر به دومین آی دی نیازی ندارند، آنها فقط ترافیک را بین سرورها و سوئیچ های ردیف Core عبور می دهند. تمامی سرویس های Fabric که قبلا توضیح داده شد، دیگر در این سوئیچ ها غیرفعال هستند و نیازی به وجود آنها نیست زیرا تمامی فعالیت ها را به سمت سوئیچ ردیف Core ارسال می کنند.
در این روش تمامی پورت هایی که به Core Switch متصل هستند، در حالت NP Port قرار می گیرند (و نه E_Port). همچنین Core Switch نیز می بایست از NPIV پشتیبانی نماید در غیر اینصورت عمل نمی کند و سوئیچ های edge از این مد خارج و تنظیمات آنها پاک شده و سپس reboot می شوند، در نتیجه مدیران شبکه در رابطه با استفاده از این مد بسیار باید احتیاط کنند.
Block Level Storage Virtualization
مجازی سازی استوریج های Block level از مباحث جدیدی است که امروزه بسیار مورد استفاده قرار می گیرد. در این روش با استفاده از یک نرم افزار مجازی سازی، تمامی Lun های ساخته شده در استوریج ها را در یک pool جمع کرده و از داخل آن pool اقدام به ساخت Virtual volume می کنیم و سپس آنها را به سرورها اختصاص می دهیم. در واقع سرورها هیچگونه آگاهی از نحوه این mapping که در لایه virtualization انجام می گیرد، ندارند. معمولا این نوع از مجازی سازی توسط یک appliance انجام می گیرد به مانند محصول شرکت emc که با نام VPLEX عرضه شده است. در شکل زیر می توانید به وضوح نحوه اجرای این نوع از مجازی سازی را مشاهده نمایید.
اما یک مزیت کلیدی که این روش مجازی سازی نسبت به روش های سنتی دارد در رابطه با migration است، یعنی زمانی که بخواهیم یک استوریج را با استوریج دیگر جا به جا نماییم.
در روش سنتی این عملیات بصورت آفلاین انجام می گردد ولی در روش مجازی سازی شده با توجه به اینکه سرورها با virtual volume ها در ارتباط هستند و نه بصورت مستقیم با Lun، وقتی یک استوریج اقدام به عملیات migration می کند، لایه مجازی سازی این را تشخیص داده و مسیر را به سمت استوریج mirror تغییر می دهد و در نتیجه هیچ قطعی احساس نمی شود. همچنین به مانند روش سنتی با عوض کردن استوریج دیگر نیازی به تغییر تنظیمات سرور برای اشاره به استوریج جدید نداریم، تنها می بایست در لایه مجازی سازی، mapping مربوطه را تغییر دهیم.
استفاده از این راهکار بخصوص برای دیتاسنترها توانسته است بسیار در مسیر توسعه به آنها کمک کند و راه حل مناسبی برای Big data باشد. می خواهیم راه کار مجازی سازی را که در بالا توضیح دادیم، بیشتر توسعه دهیم. مطابق شکل زیر فرض کنید یک دیتاسنتر در دو محل جغرافیایی مختلف، که هر کدام دارای یک appliance برای ایجاد لایه مجازی سازی مربوط به خود است، ایجاد شده است.
این appliance ها قابلیت این را دارند که به یکدیگر متصل شده و بصورت مرکزی مدیریت شوند، بدین صورت ما یک لایه مجازی سازی داریم که در بین دو مرکز داده در دو ناحیه جغرافیایی مختلف گسترش داده شده است. بدین ترتیب تمامی Lun ها در هر دو مرکز داده در یک Pool قرار گرفته و سپس Virtual Volume ها ساخته می شوند. این volume ها از هر دو مرکز داده قابل دسترسی هستند و سرورها قادرند بصورت همزمان به هر دو دسترسی داشته باشند.
VSAN (Virtual SAN)
در این تکنیک که با نام virtual fabric نیز شناخته می شود، یک سوئیچ FC را به ۲ یا چند واحد انتزاعی تقسیم می کنیم و هر کدام از پورت های سوئیچ را نیز عضو یکی از این واحدها می کنیم. هر کدام از VSAN ها به عنوان یک واحد مستقل و مجزا به حساب می آیند و تمامی سرویس های fabric که در درس قبل شرح داده شدند، بصورت مجزا در هر کدام از این واحدها اجرا می شوند و بطور کلی پیکربندی آنها نیز از هم جدا می باشد.
ترافیک VSAN ها کاملا از هم جدا هستند و به یکدیگر نیز دسترسی ندارند، به همین دلیل باعث بالاتر رفتن امنیت می گردد. این تکنیک به خصوص برای سرویس دهندگان Cloud که multi-tenant می باشند، بسیار کارایی دارد زیرا این امکان را برای آنها فراهم می کند که شبکه tenant های مختلف را از هم جدا کنند تا امنیت آنها حفظ گردد.
نحوه پیکربندی آن بدین ترتیب است که ابتدا VSANها را می سازیم که هر کدام از آنها یک مشخصه با نام VSAN ID دارند و سپس آنها را به F_Port ها اختصاص می دهیم. در واقع هر N_Port که به یک F_Port متصل باشد، عضوی از آن VSAN می گردد و می تواند با سایر پورت هایی که در آن VSAN هستند، ارتباط برقرار کند.
باید در نظر داشت که میان VSAN و Zoning تفاوت وجود دارد. یک مدیر شبکه ابتدا VSAN های خود را ساخته و سپس درون هر VSAN می تواند Zoning بین پورت ها را انجام دهد. به عبارت دیگر از طریق zoning ارتباطات داخل یک VSAN را نیز باز محدود می کنیم.
تکنیک VSAN در سوئیچ های FC به مانند مفهوم VLAN در شبکه های اترنت می باشد. همانطور که در شکل زیر مشاهده می کنید یک لینک ISL که بتواند ترافیک VSANها را بین سوئیچ ها عبور دهد، Trunk link نامیده می شود. زمانی که یک پکت به سوئیچ می رسد و قرار است توسط لینک ترانک به سمت یک سوئیچ دیگر ارسال شود، ابتدا سوئیچ تگ مربوط به VSAN ID را به آن پکت زده و سپس آنرا بر روی لینک ترانک ارسال می کند. سوئیچ مقصد نیز بعد از دریافت پکت، آن تگ را پاک کرده و به سمت N_Port مربوطه ارسال می کند. به این عملیات در اصطلاح VLAN Tagging می گویند.
