داستان یک سوئیچ

در تجمیع شبکه محلی ما شش جفت سوئیچ Arista DCS-7050CX3-32S و یک جفت سوئیچ Brocade VDX 6940-36Q داشتیم. اینطور نیست که سوئیچ های Brocade در این شبکه بیش از حد تحت فشار قرار گرفته باشیم، آنها کار می کنند و وظایف خود را انجام می دهند، اما ما در حال آماده سازی اتوماسیون کامل برخی از اقدامات بودیم و این قابلیت ها را روی این سوئیچ ها نداشتیم. من همچنین می‌خواستم از رابط‌های 40GE به امکان استفاده از 100GE سوئیچ کنم تا برای 2-3 سال آینده ذخیره کنم. بنابراین تصمیم گرفتیم Brocade را به Arista تغییر دهیم.

این سوئیچ ها سوئیچ های تجمیع LAN برای هر مرکز داده هستند. سوئیچ های توزیع (سطح دوم تجمیع) مستقیماً به آنها متصل می شوند که از قبل سوئیچ های شبکه محلی Top-of-Rack را در رک ها با سرورها مونتاژ می کنند.

هر سرور به یک یا دو سوئیچ دسترسی متصل است. سوئیچ های دسترسی به یک جفت سوئیچ توزیع متصل می شوند (دو سوئیچ توزیع و دو لینک فیزیکی از سوئیچ دسترسی به سوئیچ های توزیع مختلف برای افزونگی استفاده می شود).

هر سرور می تواند توسط کلاینت خود استفاده شود، بنابراین یک VLAN جداگانه به مشتری اختصاص داده می شود. سپس همان VLAN در سرور دیگری از این کلاینت در هر رک ثبت می شود. مرکز داده از چندین ردیف (POD) تشکیل شده است که هر ردیف از رک ها سوئیچ های توزیع مخصوص به خود را دارند. سپس این سوئیچ های توزیع به سوئیچ های تجمع متصل می شوند.

کلاینت ها می توانند سرور را در هر ردیفی سفارش دهند؛ نمی توان از قبل پیش بینی کرد که سرور در یک ردیف خاص در یک رک خاص تخصیص یا نصب شود، به همین دلیل است که در هر مرکز داده حدود 2500 VLAN روی سوئیچ های تجمیع وجود دارد.

تجهیزات DCI (ارتباط مرکز داده) به سوئیچ های تجمیع متصل است. این می تواند برای اتصال L2 (یک جفت سوئیچ که یک تونل VXLAN را به مرکز داده دیگر تشکیل می دهد) یا برای اتصال L3 (دو روتر MPLS) در نظر گرفته شود.

همانطور که قبلاً نوشتم ، برای یکسان سازی فرآیندهای خودکارسازی پیکربندی خدمات روی تجهیزات در یک مرکز داده ، لازم بود سوئیچ های تجمع مرکزی جایگزین شوند. سوئیچ های جدیدی را در کنار سوئیچ های موجود نصب کردیم، آنها را در یک جفت MLAG ترکیب کردیم و شروع به آماده شدن برای کار کردیم. آنها بلافاصله به سوئیچ های تجمع موجود متصل شدند، به طوری که یک دامنه L2 مشترک در تمام VLAN های مشتری داشتند.

جزئیات مدار

برای جزئیات، اجازه دهید سوئیچ های تجمع قدیمی را نام ببریم A1 и A2، جدید - N1 и N2. بیایید تصور کنیم که در POD 1 и POD 4 سرورهای یک مشتری میزبانی می شوند С1، مشتری VLAN با رنگ آبی نشان داده شده است. این سرویس گیرنده از سرویس اتصال L2 با مرکز داده دیگری استفاده می کند، بنابراین VLAN آن به یک جفت سوئیچ VXLAN تغذیه می شود.

مشتری С2 میزبان سرورها در POD 2 и POD 3، مشتری VLAN با سبز تیره نشان داده شده است. این سرویس گیرنده همچنین از یک سرویس اتصال با مرکز داده دیگری استفاده می کند، اما L3، بنابراین VLAN آن به یک جفت روتر L3VPN تغذیه می شود.

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

همه دستگاه‌هایی که با پیوندهای دوگانه متصل می‌شوند، یک پشته، جفت MLAG یا پارچه اترنت VCS را تشکیل می‌دهند. برای یک جفت روتر L3VPN، از چنین فناوری هایی استفاده نمی شود، زیرا نیازی به افزونگی L2 نیست، کافی است آنها از طریق سوئیچ های تجمع به یکدیگر اتصال L2 داشته باشند.

گزینه های پیاده سازی

هنگام تجزیه و تحلیل گزینه ها برای رویدادهای بعدی، متوجه شدیم که راه های مختلفی برای انجام این کار وجود دارد. از یک شکست سراسری در کل شبکه محلی، تا شکست های کوچک به معنای واقعی کلمه 1-2 ثانیه در بخش هایی از شبکه.

شبکه، بس کن! سوئیچ ها، آنها را تعویض کنید!

البته ساده ترین راه این است که یک قطع ارتباط جهانی در همه POD ها و همه سرویس های DCI اعلام کنید و همه لینک ها را از سوییچ ها تغییر دهید. А به سوئیچ ها N.

جدا از وقفه، زمان آن را نمی‌توانیم به طور قابل اعتماد پیش‌بینی کنیم (بله، تعداد لینک‌ها را می‌دانیم، اما نمی‌دانیم چند بار مشکلی پیش می‌آید - از یک وصله سیم شکسته یا کانکتور آسیب‌دیده گرفته تا پورت یا فرستنده و گیرنده معیوب هنوز نمی‌توانیم از قبل پیش‌بینی کنیم که آیا طول پچ‌کوردها، DACها، AOCهای متصل به سوئیچ‌های قدیمی A برای رسیدن به سوئیچ‌های جدید N کافی است، اگرچه در نزدیکی ایستاده است، اما هنوز کمی در کناره است و آیا همان فرستنده‌های گیرنده /DAC/AOC از سوئیچ‌های Brocade تا سوئیچ‌های Arista کار می‌کنند.

و همه اینها در شرایط فشار شدید مشتریان و پشتیبانی فنی ("ناتاشا، بلند شو! ناتاشا، همه چیز آنجا کار نمی کند! ناتاشا، ما قبلاً به پشتیبانی فنی نامه داده ایم، صادقانه! ناتاشا، آنها قبلا همه چیز را رها کرده اند. ناتاشا، چند نفر دیگر داریم که کار نمی کند؟ ناتاشا، کی کار می کند؟!"). حتی با وجود توقف از قبل اعلام شده و اطلاع رسانی به مشتریان، هجوم درخواست ها در چنین زمانی تضمین می شود.

توقف، 1-2-3-4!

اگر یک قطع جهانی را اعلام نکنیم، بلکه یک سری وقفه‌های کوچک ارتباطی برای سرویس‌های POD و DCI را اعلام نکنیم. در اولین استراحت، به سوئیچ ها بروید N تنها POD 1، در دوم - در چند روز - POD 2، سپس چند روز دیگر POD 3بیشتر POD 4…[N]، سپس سوئیچ های VXLAN و سپس روترهای L3VPN.

با این سازماندهی کار سوئیچینگ، پیچیدگی کار یکباره را کاهش می دهیم و اگر ناگهان مشکلی پیش بیاید، زمان خود را برای حل مشکلات افزایش می دهیم. POD 1 پس از تعویض به سایر POD ها و DCI ها متصل می ماند. اما خود کار مدت زیادی طول می کشد؛ در طول این کار در مرکز داده، یک مهندس موظف است سوئیچینگ را به صورت فیزیکی انجام دهد و در حین کار (و چنین کاری معمولاً در شب از ساعت 2 انجام می شود. تا ساعت 5 صبح)، حضور یک مهندس شبکه آنلاین با مدارک تحصیلی نسبتاً بالا الزامی است. اما پس از آن ما با وقفه های کوتاه ارتباط مواجه می شویم؛ به عنوان یک قاعده، کار را می توان در فاصله زمانی نیم ساعت با وقفه تا 2 دقیقه (در عمل، اغلب 20-30 ثانیه با رفتار مورد انتظار تجهیزات) انجام داد.

در مشتری مثال С1 یا مشتری С2 شما باید حداقل سه بار در مورد کار با قطع ارتباط هشدار دهید - اولین بار برای انجام کار روی یک POD که یکی از سرورهای آن در آن قرار دارد، بار دوم - در بار دوم و بار سوم - زمانی که تجهیزات سوئیچینگ برای خدمات DCI.

تغییر کانال های ارتباطی انبوه

چرا ما در مورد رفتار مورد انتظار تجهیزات صحبت می کنیم و چگونه می توان کانال های انبوه را تغییر داد و در عین حال قطع ارتباط را به حداقل رساند؟ بیایید تصویر زیر را تصور کنیم:

در یک طرف پیوند سوئیچ های توزیع POD وجود دارد - D1 и D2، آنها یک جفت MLAG را با یکدیگر تشکیل می دهند (پشته، کارخانه VCS، جفت vPC)، از طرف دیگر دو پیوند وجود دارد - پیوند 1 и پیوند 2 - در جفت سوئیچ های تجمع قدیمی MLAG گنجانده شده است А. در سمت سوئیچ D یک رابط انبوه با نام بندر-کانال A، در کنار سوئیچ های تجمع А - رابط جمع آوری شده با نام بندر-کانال D.

اینترفیس‌های انبوه در عملکرد خود از LACP استفاده می‌کنند، یعنی سوئیچ‌ها در هر دو طرف به طور منظم بسته‌های LACPDU را در هر دو پیوند مبادله می‌کنند تا مطمئن شوند که پیوندها:

• کارگران؛
• موجود در یک جفت دستگاه در سمت راه دور.

هنگام مبادله بسته ها، بسته دارای ارزش است شناسه سیستم، نشان دهنده دستگاهی است که این پیوندها در آن گنجانده شده است. برای یک جفت MLAG (پشته، کارخانه و غیره)، مقدار شناسه سیستم برای دستگاه‌هایی که رابط انبوه را تشکیل می‌دهند یکسان است. تعویض D1 می فرستد به پیوند 1 ارزش شناسه سیستم Dو سوئیچ کنید D2 می فرستد به پیوند 2 ارزش شناسه سیستم D.

سوئیچ ها A1 и A2 بسته های LACPDU دریافت شده را در یک رابط Po D تجزیه و تحلیل کنید و بررسی کنید که آیا شناسه سیستم در آنها مطابقت دارد یا خیر. اگر شناسه سیستم دریافت شده از طریق برخی پیوندها ناگهان متفاوت شود از ارزش عملیاتی فعلی، سپس این پیوند از رابط جمع آوری شده حذف می شود تا وضعیت اصلاح شود. حالا در سمت سوئیچ ما D مقدار شناسه سیستم فعلی از شریک LACP - A، و در سمت سوئیچ А - مقدار شناسه سیستم فعلی از شریک LACP - D.

اگر نیاز به تغییر رابط انبوه داشته باشیم، می توانیم این کار را به دو روش مختلف انجام دهیم:

روش 1 - ساده
هر دو لینک را از سوییچ A غیرفعال کنید. در این حالت کانال تجمیع شده کار نمی کند.

هر دو لینک را یکی یکی به سوئیچ ها وصل کنید N، سپس پارامترهای عملیاتی LACP دوباره مورد مذاکره قرار می گیرد و رابط تشکیل می شود پو دی روی سوئیچ ها N و انتقال مقادیر روی لینک ها system-id N.

روش 2 - وقفه را به حداقل برسانید
لینک 2 را از سوئیچ A2 جدا کنید. در همان زمان، ترافیک بین А и D به سادگی از طریق یکی از پیوندها منتقل می شود، که بخشی از رابط انباشته باقی می ماند.

لینک 2 را به سوئیچ N2 وصل کنید. روی سوئیچ N رابط جمع آوری شده قبلاً پیکربندی شده است Po DNو سوئیچ کنید N2 شروع به ارسال به LACPDU می کند system-id N. در این مرحله می‌توانیم سوئیچ را بررسی کنیم N2 با فرستنده و گیرنده مورد استفاده به درستی کار می کند پیوند 2، که پورت اتصال وارد حالت شده است Up، و اینکه هنگام ارسال LACPDU هیچ خطایی در درگاه اتصال رخ نمی دهد.

اما این واقعیت است که سوئیچ D2 برای رابط انبوه پو آ از طرف پیوند 2 یک مقدار system-id N متفاوت از مقدار سیستم عامل فعلی-id A دریافت می کند، اجازه سوئیچ را نمی دهد D معرفی کنید پیوند 2 بخشی از رابط جمع آوری شده پو آ. تعویض N نمی تواند وارد شود پیوند 2 از آنجایی که تاییدیه عملکرد را از شریک LACP سوییچ دریافت نمی کند D2. ترافیک حاصله است پیوند 2 عبور نکردن

و اکنون لینک 1 را از سوییچ A1 خاموش می کنیم، در نتیجه سوئیچ ها را محروم می کند А и D رابط جمع کاری بنابراین در سمت سوئیچ D مقدار فعلی سیستم شناسه کار برای رابط ناپدید می شود پو آ.

این اجازه می دهد تا سوئیچ ها D и N موافقت با تبادل system-id AN روی رابط ها پو آ и Po DN، به طوری که ترافیک در طول پیوند شروع به انتقال می کند پیوند 2. استراحت در این مورد در عمل تا 2 ثانیه است.

و اکنون به راحتی می توانیم لینک 1 را به سوییچ N1 تغییر دهیمبازیابی ظرفیت و سطح افزونگی رابط پو آ и Po DN. از آنجایی که وقتی این پیوند وصل می شود، مقدار شناسه سیستم فعلی در هر دو طرف تغییر نمی کند، هیچ وقفه ای ایجاد نمی شود.

لینک های اضافی

اما سوئیچ را می توان بدون حضور مهندس در زمان سوئیچ انجام داد. برای انجام این کار، ما باید از قبل پیوندهای اضافی بین سوئیچ های توزیع قرار دهیم D و سوئیچ های تجمع جدید N.

ما در حال ایجاد پیوندهای جدید بین سوئیچ های تجمع هستیم N و سوئیچ های توزیع برای همه POD ها. این امر مستلزم سفارش و نصب پچ‌کوردهای اضافی و نصب فرستنده‌های گیرنده اضافی است N، و در D. ما می توانیم این کار را انجام دهیم زیرا در سوئیچ های ما D هر POD دارای پورت های رایگان است (یا ما آنها را از قبل آزاد می کنیم). در نتیجه، هر POD به طور فیزیکی توسط دو لینک به سوییچ های قدیمی A و سوئیچ های جدید N متصل می شود.

روی سوئیچ D دو رابط انبوه تشکیل شده است - پو آ با لینک ها پیوند 1 и پیوند 2و پو ن - با لینک لینک N1 и لینک N2. در این مرحله اتصال صحیح رابط‌ها و لینک‌ها، سطوح سیگنال‌های نوری در دو انتهای لینک‌ها (از طریق اطلاعات DDM از سوییچ‌ها) را بررسی می‌کنیم، حتی می‌توانیم عملکرد لینک تحت بار را بررسی کنیم یا وضعیت‌های سیگنال های نوری و دمای فرستنده گیرنده برای چند روز.

ترافیک همچنان از طریق رابط ارسال می شود پو آو رابط کاربری پو ن بدون ترافیک تنظیمات روی اینترفیس ها چیزی شبیه به این است:

Interface Port-channel A
Switchport mode trunk
Switchport allowed vlan C1, C2

Interface Port-channel N
Switchport mode trunk
Switchport allowed vlan none

سوئیچ های D، به عنوان یک قاعده، از پیکربندی مجدد جلسه پشتیبانی می کنند؛ مدل های سوئیچ که این قابلیت را دارند استفاده می شود. بنابراین می توانیم تنظیمات رابط های Po A و Po N را در یک مرحله تغییر دهیم:

Configure session
Interface Port-channel A
Switchport allowed vlan none
Interface Port-channel N
Switchport allowed vlan C1, C2
Commit

سپس تغییر پیکربندی به اندازه کافی سریع اتفاق می افتد و استراحت در عمل بیش از 5 ثانیه نخواهد بود.

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

آنچه در این روش سوئیچینگ نیز مهم است این است که همه پیوندهای جدید از قبل نظارت می شوند. خطاها، گنجاندن پیوندها در واحد، بارگیری پیوندها - تمام اطلاعات لازم در حال حاضر در سیستم نظارت وجود دارد و این قبلاً روی نقشه ها ترسیم شده است.

روز شروع بکاری

POD

ما کم دردسرترین مسیر تعویض را برای مشتریان و کمترین احتمال را برای سناریوهای "مشکلی پیش آمده" با پیوندهای اضافی انتخاب کردیم. بنابراین ما همه POD ها را در چند شب به سوئیچ های تجمع جدید تغییر دادیم.

اما تنها چیزی که باقی می ماند تعویض تجهیزاتی است که خدمات DCI را ارائه می دهد.

L2

در مورد تجهیزاتی که اتصال L2 را فراهم می کند، ما قادر به انجام کارهای مشابه با پیوندهای اضافی نبودیم. حداقل دو دلیل برای این وجود دارد:

• عدم وجود پورت های آزاد با سرعت مورد نیاز در سوئیچ های VXLAN.
• عدم وجود عملکرد تغییر پیکربندی جلسه در سوئیچ های VXLAN.

ما پیوندها را "یکی در یک زمان" با وقفه تغییر ندادیم فقط در حین توافق بر روی یک جفت شناسه سیستم جدید، زیرا ما 100٪ اطمینان نداشتیم که این روش به درستی پیش می رود، و یک آزمایش در آزمایشگاه نشان داد که در اگر «مشکلی پیش بیاید»، باز هم با قطعی اتصال مواجه می‌شویم، و بدترین چیز نه تنها برای کلاینت‌هایی است که اتصال L2 با مراکز داده دیگر دارند، بلکه به طور کلی برای همه مشتریان این مرکز داده است.

ما کارهای تبلیغاتی را پیش از موعد برای انتقال از کانال های L2 انجام دادیم، بنابراین تعداد مشتریانی که تحت تأثیر کار روی سوئیچ های VXLAN قرار گرفتند چندین برابر کمتر از یک سال پیش بود. در نتیجه تصمیم گرفتیم ارتباط از طریق سرویس اتصال L2 را قطع کنیم، مشروط بر اینکه عملکرد عادی خدمات شبکه محلی را در یک مرکز داده حفظ کنیم. علاوه بر این، SLA برای این سرویس امکان انجام کارهای برنامه ریزی شده با وقفه را فراهم می کند.

L3

چرا توصیه می کنیم هنگام سازماندهی خدمات DCI، همه به L3VPN روی بیاورند؟ یکی از دلایل آن امکان انجام کار بر روی یکی از روترهایی است که این سرویس را ارائه می دهد، به سادگی کاهش سطح افزونگی به N+0، بدون قطع ارتباط.

بیایید نگاهی دقیق تر به طرح ارائه خدمات بیندازیم. در این سرویس، بخش L2 از سرورهای مشتری فقط به روترهای L3VPN Selectel می رود. شبکه مشتری در روترها خاتمه می یابد.

هر سرور مشتری، به عنوان مثال. S2 и S3 در نمودار بالا، آدرس IP خصوصی خود را دارند - 10.0.0.2/24 در سرور S2 и 10.0.0.3/24 در سرور S3. آدرس ها 10.0.0.252/24 и 10.0.0.253/24 توسط Selectel به روترها اختصاص داده شده است L3VPN-1 и L3VPN-2، به ترتیب. آدرس آی پی 10.0.0.254/24 یک آدرس VIP VRRP است در روترهای Selectel

می توانید درباره سرویس L3VPN اطلاعات بیشتری کسب کنید خواندن در وبلاگ ما

قبل از سوئیچ، همه چیز تقریباً مانند نمودار به نظر می رسید:

دو روتر L3VPN-1 и L3VPN-2 به سوئیچ تجمع قدیمی متصل شدند А. اصلی برای آدرس VIP VRRP 10.0.0.254 روتر است L3VPN-1. برای این آدرس اولویت بیشتری نسبت به روتر دارد L3VPN-2.

unit 1006 {
    description C2;
    vlan-id 1006;
    family inet {       
        address 10.0.0.252/24 {
            vrrp-group 1 {
                priority 200;
                virtual-address 10.100.0.254;
                preempt {
                    hold-time 120;
                }
                accept-data;
            }
        }
    }
}

سرور S2 از gateway 10.0.0.254 برای برقراری ارتباط با سرورها در مکان های دیگر استفاده می کند. بنابراین، قطع ارتباط روتر L3VPN-2 از شبکه (البته اگر ابتدا از دامنه MPLS قطع شود) بر اتصال سرورهای مشتری تأثیری ندارد. در این مرحله، سطح افزونگی مدار به سادگی کاهش می یابد.

پس از این می توانیم با خیال راحت روتر را دوباره وصل کنیم L3VPN-2 به یک جفت سوئیچ N. پیوندها را بگذارید، فرستنده گیرنده را تغییر دهید. رابط های منطقی روتر، که عملکرد خدمات مشتری به آنها بستگی دارد، غیرفعال می شوند تا زمانی که تأیید شود که همه چیز همانطور که باید کار می کند.

پس از بررسی پیوندها، فرستنده‌ها، سطوح سیگنال و سطوح خطا در رابط‌ها، روتر به کار گرفته می‌شود، اما قبلاً به یک جفت سوئیچ جدید متصل شده است.

در مرحله بعد، اولویت VRRP روتر L3VPN-1 را کاهش می دهیم و آدرس VIP 10.0.0.254 به روتر L3VPN-2 منتقل می شود. این کارها نیز بدون وقفه در ارتباط انجام می شود.

انتقال آدرس VIP 10.0.0.254 به روتر L3VPN-2 به شما امکان می دهد روتر را غیرفعال کنید L3VPN-1 بدون وقفه در ارتباط برای مشتری و اتصال آن به یک جفت سوئیچ تجمع جدید N.

اینکه آیا VRRP VIP به روتر L3VPN-1 برگردانده شود یا نه، سوال دیگری است و حتی اگر برگردانده شود، بدون قطع اتصال انجام می شود.

در کل

پس از تمام این مراحل، ما در واقع سوئیچ های تجمیع را در یکی از مراکز داده خود جایگزین کردیم، در حالی که اختلال را برای مشتریان خود به حداقل رساندیم.

تنها چیزی که باقی می ماند، برچیدن است. برچیدن سوئیچ های قدیمی، برچیدن لینک های قدیمی بین سوئیچ های A و D، جداسازی فرستنده گیرنده ها از این لینک ها، تصحیح مانیتورینگ، تصحیح نمودارهای شبکه در مستندسازی و مانیتورینگ.

ما می‌توانیم از سوئیچ‌ها، فرستنده‌ها، پچ‌کوردها، AOC، DAC باقی مانده پس از سوئیچ در پروژه‌های دیگر یا سایر سوئیچینگ‌های مشابه استفاده کنیم.

"ناتاشا، ما همه چیز را تغییر دادیم!"

منبع: www.habr.com