Bootcamp مدیریت محصول

منتشر شده توسط castroflavio در تاریخ 12 مه 2019

چه خبر است؟ در سال گذشته در حالی که در اتوماسیون شبکه سازی دیتاسنتر برای پی پال کار کردم ، متوجه شدم که برخی از تیم های توسعه چه زمانی موثر هستند که مدیر محصول خوبی دارند و حس کنجکاوی من را کم می کند. فهمیدم که همیشه وقت خوبی را صرف می کنم که بپرسم چرا کار قبل از انجام آن انجام می شود و این یکی از ویژگی های یک مدیر محصول است.

هفته گذشته ، من در مجمع عمومی به Bootcamp درمورد مدیریت محصول پیوستم. هدف من از پیوستن به این Bootcamp این است که به موضوع بپردازیم و درک کنیم که چگونه مدیریت محصول برای تیم ارزش می آورد. در طول راه ، امیدوارم مهارت هایی کسب کنم که به من کمک کند تا در شغل خود مؤثرتر باشم.

در این مقاله ، قصد دارم توصیف خواندن برای اولین هفته از چکمه را ذکر کنم و خلاصه خواندن را بنویسم:

در اینجا لیست مقالات:

  • PM خوب / بد PM توسط بن هوروویتس و دیوید وایدن (3.5 ستاره)
  • مشکل شما (فقط قسمت 1 و 2) توسط مت لاووی (5 ستاره!)
  • پنج مؤلفه یک فرضیه خوب توسط ترزا تورس (4 ستاره)
  • شغل مدیر محصول توسط جوش المان (3 ستاره)
  • مدیریت محصول در مقابل بازاریابی محصول توسط Marty Cagan (4/5 ستاره)
  • مدیریت محصول در مقابل مدیریت پروژه توسط Marty Cagan (3 ستاره)
  • هنگامی که شما در حال نوآوری هستید ، مقاومت در جستجوی راه حل  های  Review Business Harvard (هنوز نخوانده اید)

PM خوب / PM بد توسط بن هوروویتس و دیوید وایدن – 3.5 ستاره

مقاله خوبی است که به خوبی توضیح می دهد که یک مدیر محصول خوب چه کاری انجام می دهد ، و همچنین درباره آنچه مدیر محصول بد انجام می دهد ، احتیاط می کند. چراغهای برجسته یک PDM خوب:

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

تا زمانی که دید محصول در همه تیمها سازگار نباشد استراحت نمی کند.

مشکل شما (قسمتهای 1 و 2) توسط مت لاووی – 5 ستاره

مقاله ای باورنکردنی که به توضیح این موضوع می پردازد که چرا تعریف یک بیانیه مشکل برای موفقیت یک تلاش مهم است نه پرش به راه حل ها همانطور که معمولاً ما مهندسین انجام می دهیم. من دوست دارم که این یک خواندن سرگرم کننده و در عین حال مختصر و مؤثر در پیشبرد نقطه نظرات خود باشد. نکات برجسته:

با یک عبارت مشکل ، خزش هیچ ویژگی ای وجود ندارد. یک مشکل و یک نتیجه قابل اندازه گیری وجود دارد.
اگر اعتقاد داریم چیزی به آن نتیجه می رسد و می توانیم یک آزمایش را برای اثبات آن ایجاد کنیم ، باید روی آن کار کنیم.

با یک لحظه برای شناسایی مشکل ، اجرای شما به همان اندازه که ممکن است موفقیت آمیز نباشد.

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

پنج مؤلفه یک فرضیه خوب توسط ترزا تورس – 4 ستاره

خواندن جامد که توضیح می دهد که چرا فرد باید فرضیه خوبی را برای اثربخشی کار تعریف کند. من در واقع فرمی را که او در مقاله بعدی از آن انتقاد می کند می پسندم: چگونه می توان طراحی آزمایش خود را بهبود بخشید (و اعتماد به نفس خود را در آزمایشات محصول خود ایجاد کنید) . قالب Lean Startup:

ما اعتقاد داریم که [این قابلیت]
منجر به [این نتیجه]
می شود هنگامی که [این سیگنال های قابل اندازه گیری را می بینیم] اطمینان حاصل کنیم.

من آن را بهتر می خواهم زیرا عملکرد آن محور است. من می توانم ببینم که بسته به مشکل ، الگوی فرضیه وی دقیق تر خواهد بود ، اما Lean Startup لاغر است ، فقط لازم است تا حرکت شما را جلب کند.

شغل مدیر محصول توسط جاش المان – 3 ستاره

خوب بخوانید ، اما صادقانه تأثیر پذیر نیست. این فقط روی دید وی درباره شغل PDM افزود: “به تیم (و شرکت) کمک کنید تا کالای مناسب را برای کاربران خود بفرستند”. که صحیح است من فکر می کنم هنوز هم نیاز به بینش در مورد چگونگی دستیابی به این اطلاعات برای ارتباط با من دارد

مدیریت محصول در مقابل بازاریابی محصول توسط Marty Cagan – 4/5 ستاره

خواندن عالی ، و توصیف آنچه نویسنده فکر می کند باید دو نقش مکمل مورد نیاز برای راه اندازی یک محصول باشد. نویسنده اظهار می دارد که اغلب این دو نقش به یک شخص اختصاص می یابد حتی اگر افراد معمولاً از یک جنبه یا جهت دیگر متمرکز می شوند و اغلب باعث ایجاد شکاف می شوند.

مدیریت محصول در مقابل مدیریت پروژه توسط Marty Cagan (5/10)

خوب خوانده شده اما بی تأثیر است.

این در حال حاضر برای همه افراد وجود دارد ، من هیجان زده ام و سعی خواهم کرد که هفتگی یک پست وبلاگ درباره این تجربه جدید بنویسم.

پیام بگذارید

پس از اعتیاد به اعتیاد به مواد مخدر برای SDN چیست؟

منتشر شده توسط castroflaviojr در تاریخ 1 مه 2019

یک بار دیگر بگویید SDN!

گزیده زیر برای فهم SDN خواندن اجباری است. این مقاله از مقاله “SDN برای شبکه سازی DevOps است” نوشته راب شروود ، نوشته شده در سال 2014. اگر هنوز آن را نخوانده اید ، اکنون این کار را انجام دهید.

اصطلاح SDN برای اولین بار در مقالهای با بررسی MIT Technology Review با مقایسه تغییر شبکه در تغییر فناوری رادیویی با پیشرفت رادیوهای تعریف شده توسط نرم افزار ابداع شده است.

با این حال ، این اصطلاح شاید گمراه کننده باشد زیرا تقریباً تمام دستگاههای شبکه شامل ترکیبی از قطعات سخت افزاری و نرم افزاری هستند. این ابهام توسط شرکتهای مختلفی که سعی در تولید مجدد محصولات تحت چتر “SDN” داشته و به طور مؤثر به باند SDN بپیوندند ، افزایش یافته و تشدید شد. در نتیجه ، بسیاری از شایستگی های فنی SDN در سر و صدا از بین رفته است.

درگیری با معناشناسی آغاز می شود. وقتی محققان به SDN مراجعه می کنند ، منظور آنها هیچ شبکه ای نیست که توسط یک نرم افزار تعریف شود ، خیلی ساده است. این به معنای گروه خاصی از ایده ها در شبکه های رایانه ای است که بیشتر در مورد انتزاع و جدایی بین صفحه کنترل و داده ایجاد می شود . از آن فرض ، این اصطلاح کاملاً در صنعت مورد سوءاستفاده قرار گرفته است. علاوه بر این ، سطوح مختلفی از انتزاع وجود دارد که می توان این جداسازی را بر اساس آن بنا کرد:

به دلیل این جداسازی ، می توانید چرخه های نوآوری را جدا کرده و به عنوان مثال شبکه خود را با نمای جهانی از شبکه بهینه کنید. در حقیقت ، ارزشمندترین هدف SDN جدا کردن چرخه نوآوری است ، به عبارت دیگر ، شما می توانید کنترل شبکه خود را مستقل از فن آوری های اساسی بهبود بخشید. این باعث افزایش چشمگیر سرعت ویژگی ها در صنعت شده است. ما در 10 سال گذشته پیشرفت بیشتری در صنعت نسبت به 30 سال گذشته داشته ایم. یکی از پست های من شواهدی در مورد آن ارائه می دهد.

از این طریق ، OF یا P4 انتزاعی است که مبتنی بر ارسال API است ، در حالی که روش سنتی تر اتوماسیون شبکه ، انتزاعی است که در بالای API های سنتی ساخته شده است. از این طریق ، سطوح مختلف انتزاع می توانند گزاره های ارزش SDN را در سطوح مختلف ارائه دهند. بعضی از بهینه سازی ها بدون SDN خالص اما همه آنها حاصل نمی شود.

من افرادی را دیدم که BGP ، SDN را صدا می کنند: نرم افزاری دارد ، بنابراین تعریف شده نرم افزار است ، درست است؟ چه می شود اگر از یک بازتابنده مسیر استفاده کنم تا خط مشی BGP را از یک نقطه مرکزی مشخص کنم؟ باشه ، الان داریم صحبت می کنیم یک بحث بسیار متفکرانه این است که “شما نیاز به اتوماسیون شبکه / DevOps دارید نه SDN”. در واقع ، برای بسیاری از موارد استفاده ، این کافی است و این موضوع مرا به موضوع بعدی خود می رساند:

DevOps برای شبکه سازی

سلب مسئولیت: بشریت قبل از توافق درمورد SDN و DevOps درمورد معنای زندگی به توافق می رسند. من این مقاله را از مقاله قبلی ذکر خواهم کرد: ” DevOps مدیریت سرورهای سنتی را با بهترین روشهای مهندسی نرم افزار از جمله انتزاع ، اتوماسیون ، متمرکز کردن ، مدیریت انتشار و آزمایش ، تزریق می کند.” من کاملاً مطمئن هستم که اکثر مردم می توانند قبول کنند که این اقدامات / نتایج مطلوب است.

IaC به شما این فرصت را می دهد تا اکثر موارد را ارائه دهید:

  • انتزاع – مفهوم – برداشت
  • اتوماسیون
  • تمرکز
  • مدیریت انتشار
  • آزمایش کردن

این نرم افزار انتزاعی از  API های میراث دارنده هواپیمای کنترل را کنترل می کند که به اندازه کافی مناسب برای بسیاری از افراد است. همچنین ، استخدام یک توسعه دهنده زن و شوهر نسبت به جایگزینی سخت افزار بسیار ساده تر است. تفکیک شبکه  در لایه فلز لخت در حال حاضر موارد زیادی را تحویل داده است. اکنون آیا اتوماسیون شبکه می تواند بهینه سازی جهانی را ارائه دهد؟

قطعاً این بدان معنا نیست که باید ، یا بهترین یا ارزانترین راه است. در مورد این موضوع فکر کنید: تا چه اندازه ارزش تحویل بهینه سازی با استفاده از اتوماسیون را دارد؟ چه انتزاعی انجام این کار را برای شما آسانتر می کند؟ این اکنون به یک مشکل مهندسی تبدیل شده است که در آن ارزیابی می کنیم از چه فناوری برای حل یک مشکل استفاده کنیم.

مهندسی ترافیک

به عنوان مثال ، ستون فقرات TE را بگیرید ، بعضی از سازمان ها با استفاده متوسط ​​از 30٪ پیوندهای کاملاً خوبی دارند. برخی از شرکت ها در اثر جریان فیل صدمه دیده اند ، برخی از آنها نیست. چرا دوباره به TE اهمیت می دهید؟ خوشحالم که پرسیدم ، این پست را بررسی کنید. به شوخی کنار ، یک شرکت با TE اثربخش به طور مداوم تجربه بهتری را با کاهش هزینه های OpEx و CapEx ارائه می دهد ، سرانجام ، این بازده ها توسط بازار جذب می شوند. در واقع ، من استدلال می کنم که ما شروع به مشاهده آن می کنیم. از شما می پرسم ، کدام شرکت ها بیشترین پول را برای گسترش شبکه های خود خرج می کنند؟ بله ، ارائه دهندگان محتوا مانند Google و Facebook.

آیا می توانیم با RSVP-TE بهینه سازی جهانی ارائه دهیم؟ مطمئن. سیستم نرم افزاری که آن بهینه سازی ها را انجام دهد چقدر پیچیده است؟ به من بگو. اندازه متوسط ​​تیم ستون فقرات TE چقدر است؟ من مطمئن هستم که حداقل نیمی از CCIE ، یک تن از فروشندگان و تعداد زیادی از مهندسین پشتیبانی سطح پایین است. بیشتر ISP ها هنوز بهینه سازی جهانی را در زمان واقعی تحویل نداده اند. بسیاری از آنها بهینه سازی های ذکر شده را ذکر نکرده اند.

گوگل برخی داده ها را منتشر کرده است و آنها اطلاع داده اند که تیم های SDN در مقایسه با معماری های شبکه سنتی از 6 برابر سرعت ویژگی پشتیبانی می کنند. با منطق مشکوک می توان القا کرد که تحویل TE با معماری های سنتی 6 برابر گران تر است.

اسپرسو پس از گذشت بیش از یک سال از روند افزایشی افزایشی ، شش برابر سرعت ویژگی ، 75٪ کاهش هزینه ، بسیاری از ویژگی های جدید و رشد ظرفیت نمایی را نسبت به معماری های سنتی پشتیبانی می کند.

برای توسعه یک سیستم TE مبتنی بر OF به چه تعداد مهندس نیاز دارید؟

می توان اینگونه استدلال كرد كه فن آوری اساسی تا زمانی كه راه حل ارائه شود مهم نیست. به اندازه کافی عادلانه در این حالت ، من از شما می خواهم بپرسم که چه معماری گسترده تر خواهد شد ، و بزرگترین مزیت طولانی مدت را برای شما فراهم می کند؟ یکی با یک دسته از hacks قرار گرفته است یا یکی از زمین ساخته شده تا به بالا؟

نتیجه گیری – پس از اعتیاد به مواد مخدره چه چیزی باقی مانده است؟

دلایل اصلی آغاز انقلاب SDN هنوز واقعی است: نیاز به کاهش هزینه های شبکه و چرخه سریع تر نوآوری. خالص SDN تنها راهی برای دستیابی به این موارد نیست ، تفکیک شبکه و اتوماسیون شبکه در گزاره های ارزش ارائه شده است ، اما هنوز فضای زیادی برای بهبود وجود دارد. P4 یک مثال عالی است زیرا هدف آن افزایش سرعت نوآوری در سمت سخت افزاری معادله است.

دیگر جای سوال نیست که آیا با شیوه های جدید در شبکه می توان هزینه ها را کاهش داد؟ عملیات گران قیمت قطعه به صورت قطعه جایگزین می شود ، آن را در مرکز داده شروع می شود ، اکنون ستون فقرات هدف جدید است. علاوه بر این ، من حدس می زنم که به دلیل 5G ، در سال 2019 ، چارچوب نظارتی تغییر زیادی خواهد کرد و به شرکت های نوآورانه اجازه می دهد سهم بازار را به میزان قابل توجهی افزایش دهند. استراتژی های نوآوری مؤثر به بهترین ISP ها اجازه می دهد تا با هزینه ای بسیار کاهش یافته گسترش یابد و بازار دیر یا زود آن را ببیند .

پیام بگذارید

در مورد GitOps شنیدید؟

منتشر شده توسط castroflaviojr در 5 دسامبر 2018

هوي! این فقط یک توصیه خواندن است. اخیراً مقاله ای را که غیرقابل توصیف است ، گرفتار کردم. قطعاً باید خوانده شود.

GitOps: راهی برای بیشتر سرویس های IT

من فقط قصد دارم بهترین گزیده ها را از مقاله بچسبانم:

برای یادآوری ، یک سیستم GitOps مانند این تکامل می یابد:

  1. پایه – پیکربندی در repo به عنوان مکانیسم ذخیره سازی یا پشتیبان گیری.
  2. IaC – روابط عمومی از درون تیم فقط استقرار مبتنی بر CI را تحریک می کند.
  3. GitOps – روابط عمومی خارج از تیم ، روابط عمومی از قبل بررسی شده ، آزمایش پس از ادغام.
  4. خودکار – چک های انسانی را به طور کامل از بین ببرید.

GitOps هزینه ایجاد سیستمهای IT خدمات سلف سرویس را کاهش می دهد و امکان انجام عملیات سلف سرویس را در جایی فراهم می کند که قبلاً آنها را نمی توان توجیه کرد. این امکان را برای استفاده ایمن از سیستم فراهم می کند و به کاربران عادی امکان ایجاد تغییرات بزرگ را می دهد. با افزودن آزمایش های بیشتر ، ایمنی بهبود می یابد. با ردیابی هر تغییر ، ممیزی های امنیتی آسان تر می شوند.

به هر حال ، آن را بخوانید.

پیام بگذارید

اتوماسیون شبکه محور تست

منتشر شده توسط castroflaviojr در تاریخ 25 سپتامبر 2018

مدتی گذشته در آخرین پست ، تجربه خود را در مورد هکاتون NANOG 72 روایت کردم که در آنجا کار خود را روی یک پروژه قناری شروع کردم. من قصد دارم به طور عمیق تر به مفاهیم اساسی برای اتوماسیون شبکه محور تست شیرجه بزنم.

چرا؟

در حال حاضر توجیهاً فشار زیادی برای Infra-as-Code (IAC) در شبکه وجود دارد. IAC به منظور فعال کردن فرایندهای نرم افزاری مدرن در زیرساختها دنبال می شود. اصلی ترین مزایایی که به دنبال آن هستیم چابکی و پیش بینی است. چابکی یعنی چرخه تحویل ویژگی سریعتر. پیش بینی به معنای کاهش خاموشی: با خودکار سازی استقرار می توانیم خطاهای انسانی را در حین نگهداری کاهش دهیم. با این کار ، تیم خود را قادر می سازید تا با بهبود کد ، همکاری مؤثرتری داشته و سود حاصل از بهره وری خود را با هم تركیب كنید ، درنهایت به شما اجازه می دهید كه با یك تیم كوچك ، شبکه عظیمی را اداره كنید.

به عنوان یک یادداشت جانبی ، من معتقدم که این راندمان های توسعه یافته در شرکت های پیمایشی مانند فیس بوک ، گوگل ، مایکروسافت دیر یا زود به بازارها جذب می شوند. تیم های فعلی عملیات شبکه در TELCOs (Verizon ، AT&T ، Comcast، Charter) سفارشات بزرگی بزرگتر از تیم Webscale هستند. بنابراین ، در نهایت من معتقدم که OpEx به آرامی اعمال ناکارآمد را از بازار سوق می دهد.

چطور؟

CI / CD به عنوان یک نرم افزار کاملاً خوب تعریف شده است. سوال اینجاست که چگونه می توانیم آن را در اتوماسیون شبکه اعمال کنیم. موارد زیر نمایش خوبی از روند ارائه شده توسط Juniper است (فکر می کنم):

  1. تغییراتی ایجاد کنید
  2. درخواست را بکشید
  3. بررسی همتا – کد اتوماسیون بررسی می شود
  4. خشک – ضد خش در برابر آزمایشگاه یا محصول
  5. اعلان نتایج – پیکربندی اختلافات ، خطاها؟
  6. تایید
  7. قناری تغییر می کند تا اینکه کل سیستم به روزرسانی شود یا دوباره به عقب برگردد

اکنون ، این یک روند منصفانه است ، قسمت مفقود شده در اینجا اتوماسیون تست است. افزودن این فرایند با اتوماسیون آزمون باعث می شود باکتری ها سریعتر پیدا شود و قطع خاموشی ها انجام شود. آزمایشات شبکه می تواند اساساً در 5 دسته خلاصه شود.

  • پیکربندی چک (قالب)
  • بررسی حالت (ورودی های جدول ARP ، جدول مسیریابی ، همسایگان BGP)
  • سلامت دستیابی L2
  • سلامت اتصال L3
  • بهداشت برنامه

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

  1. وضعیت بهداشتی اولیه را ضبط کنید
  2. تغییراتی را در زیر مجموعه گرهها اعمال کنید
  3. منتظر / جمع آوری داده ها
  4. هشدارها را مشاهده کنید
    • پس از گذشت زمان انتظار قرنطینه ، زیر مجموعه تغییرات افزایشی را انتخاب کرده و به مرحله 2 برگردید.
    • اگر زنگ هشدار غیرقابل قبول است ، چرخش را تغییر دهید

در این روش ، تضمین می کنید که فقط زیرمجموعه شبکه شما تحت تأثیر خطاهای احتمالی قرار دارد.

درنهایت ، داده های سلامتی برنامه باید این امر را هدایت کنند. اما معمولاً ، این داده ها به راحتی قابل استفاده نیستند زیرا سیلوهای تیم ، یا به دست آوردن یک مجموعه کوچک از معیارهای سطح برنامه که به طور قطعی از شبکه می گویند ، مشکل است. بنابراین ، ما دوباره به اتصال L3 برمی گردیم. اکنون ، در مورد اتصال L3 ، اساساً منظورمان تأخیر ، از دست دادن و توان عملیاتی است. تنها راه برای بدست آوردن داده های واقعی با اندازه گیری فعال آن ، ساده ترین ابزار منبع باز در خارج برای انجام این برنامه به صورت Todd است.

چه اشتباهی می تواند انجام شود؟

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

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

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

چگونه می توانم از این سود ببرم؟

Canarying به شما امکان می دهد قبل از به خطر انداختن کل شبکه خود ، یک اشکال را شناسایی کنید. و زمان تشخیص را کاهش می دهد زیرا تأیید اکنون روشی خودکار است. برای مثال بیایید ، شما به عنوان مثال یک تغییر پیکربندی را با یک نقشه مسیر خراب تحت فشار قرار داده اید ، برخی از مسیرها را به سیستم های خود بی اعتبار می کنید. یک سیستم تشخیص خوب به همراه یک نوع استقرار آبی و سبز می تواند خاموشی را ایجاد کند که توسط پیکربندی اشتباه انجام می شود.

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

پیام بگذارید

اتوماسیون شبکه با جواب: ارتقاء قناری / نورد

منتشر شده توسط castroflaviojr در 12 مارس 2018

در این پست ، تجربه خود را در NANOG 72 Hackathon شرح می دهم و پروژه ای را که در آن کار کردم توضیح می دهم. اگر می خواهید کار را ببینید ، اختلافات من را می توان در اینجا یافت.

Hackathon 8 ساعت به طول انجامید و مهندسین در تمام سطوح را درگیر می کرد. این کار با ارائه ابزارهای اتوماسیون شبکه آغاز شد. به دنبال تشکیل تیم: هر کس با ایده ای این فریاد را به گروه داد و پس از آن تیم ها خود ساماندهی شدند. من ایده ای را برای تغییر خودکار شبکه قناری به اشتراک گذاشتم. بگذار توضیح بدهم.

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

نمونه هایی از مواردی که ممکن است وجود داشته باشد عبارتند از: بروزرسانی های سیستم عامل ، به روزرسانی های مهم نرم افزار ، تغییرات پیکربندی و موارد دیگر. قناری نیز مشابه آن است. می گویند شما نیاز دارید که نرم افزار در حال اجرا را روی کلیه سوییچ های خود از quagga به FRR تغییر دهید. عالی نیست اگر بتوانید در حین اطمینان از عملکرد شبکه خود ، آن تغییرات را سریع انجام دهید؟ آره! گزینه دیگری برای اجرای اسکریپت های شما مانند یک وحشی است که بعداً متوجه می شوید که یک تایپی در بررسی کد شما لغزید و تمام ترافیک دیتاسنتر شما را سیاه کرد.

حالا ، دوباره به هکاتون برگردید. من تیم خود را متقاعد کردم که از یک محیط ناشایست + کد قابل قبول o که توسط کومولوس تهیه شده استفاده کند.  استفاده از منابع منبع باز راهی عالی برای توسعه بوت استرپ و رسیدن به یک پایه اولیه بود ، بنابراین ما می توانیم روی راه حل قناری (این ممکن است اشتباه باشد) متمرکز شویم. به نظر می رسد اینترنت اشباع شده است و بیش از یک ساعت زمان نیاز به بارگیری جعبه ها داشت. ظهر ، من فقط محیط زیست را به این نتیجه رسیدم که دریابم که آن صندوق ها دیگر از کگا پشتیبانی نمی کنند. این ما را به حدود ساعت 1 بعد از ظهر رساند و تیم من کمی بی تاب شد. در آن زمان افراد مشغول بحث در مورد گزینه های محوری بودند اما من تصمیم گرفتم کار را خودم تمام کنم. بنابراین من تیم خود را ترک کردم ، یا آنها مرا ترک کردند ، شما انتخاب می کنید.

به هر حال ، من اسکریپت های مربوط را برای اجرای FRR تغییر دادم و در نهایت حدود ساعت 2 بعد از ظهر یک توپولوژی در حال اجرا داشتم. پس از آن ، من شروع به بازی با Ansible کردم و به سرعت ویژگی لازم برای مورد استفاده خود را پیدا کردم. Ansible به شما امکان می دهد تعداد نقاط انتهایی را که با قسمت “سریال” اجرا می شود ، پیکربندی کنید. پس از تنظیم سریال روی 1 ، اسکریپت ها یک بار اجرا می شوند. انجام شده!!! درست؟ نه هنوز.

حالا جالب شد ، و من یک زن و شوهر را جذب کردم تا در مورد چگونگی اجرای این موضوع بحث کنند. و اساساً ، بحث بر سر این بود كه شرط كافی برای تعیین دقیق وضعیت سیستم چیست.

  1. پینگ اگرچه یک پینگ ناموفق به معنای خرابی شبکه است ، اما موفقیت آن به معنای تغییر مشکلی نیست.
  2. جدول مسیر سوئیچ اصلاح شده: این تضمین نمی کند که کل سیستم در وضعیت مثبتی باشد. به عنوان مثال ، همه چیز می تواند از نظر سوئیچ خوب به نظر برسد اما یک مسیر ممکن بود از آن طرف شبکه خارج شود.
  3. جدول جدول مسیریابی جهانی. این که فقط یک شخص درست باشد ، چالش این است که چگونه می توانید آن اطلاعات را بدست آورید.
  4. برخی از افراد این تیم به طور عادی ذکر کردند که دارای سیستم های نظارت هستند که برای تشخیص ناهنجاری ها و اصلاح آنها با اسکریپت ها در حال اجرا هستند. اما شما نمی دانید چه چیزی را نمی دانید. بنابراین من می خواهم علاوه بر آن قناری شریک باشم.

خوب ، بنابراین من به سرعت شماره 2 را انجام دادم و فهمیدم که به اندازه کافی خوب نیست. باید کد نویسی را در آنجا متوقف کردم و یک پاورپوینت درست کردم ، اما تصمیم گرفتم به جای آن هک کردن را ادامه دهم. من قادر به تکمیل شماره 3 نبودم و kinda فقط محتوای این پست را به سخره گرفت. باحال بود. به طور کلی ، این یکشنبه من را به ثمر رساند و من در غیر این صورت کاری نمی کردم.

چند هفته بعد این پروژه را تمام کردم. من یک سرویس وب فلاش نوشتم که تعداد همسایگان BGP شاغل را برمی گرداند ، سپس در Ansible می توانم با آن API تماس بگیرم و وضعیت جهانی را ارزیابی کنم. بیایید برای یک آموزش برویم.

آموزش قناری

برای اجرای این کار شما نیاز به 2.02 آشکار دارید. برای شروع ایجاد زیرساخت ها:

 git clone https://github.com/cumulusnetworks/cldemo-vagrant
 cd cldemo-vagrant
 sudo vagrant up oob-mgmt-server oob-mgmt-switch leaf01
 sudo vagrant up leaf02 leaf03 leaf04 spine01 spine02

این باید یک زیرساخت برگ نخاعی ایجاد کند که هنوز تنظیم نشده است. برای پیکربندی آن ، موارد زیر را انجام دهید:

 sudo vagrant ssh oob-mgmt-server
git clone https://github.com/castroflavio/cldemo-roh-ansible
cd cldemo-roh-ansible
ansible-playbook start.yml

قدم بعدی اجرای نسخه play.yml playbook است:

---
- hosts: spines
  user: cumulus
  become: yes
  become_method: sudo
  roles:
    - ifupdown2
    - frr
    - statecheck
  serial: 1
  max_fail_percentage: 50

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

- uri:
    url: "http://{{ item }}:5000/"
    return_content: yes
  register: webpage
  with_items:    
    - '192.168.0.11'
    - '192.168.0.12'
    - '192.168.0.13'
    - '192.168.0.14'

- debug: var=item.content
  failed_when: item.content|int < 2
  with_items: "{{ webpage.results }}"

به هر برگ (192.168.0.1 *) می رسد و از طریق API REST تعداد همسایگان BGP را بدست می آورد. کد سرویس وب را می توان در اینجا یافت.

با تشکر از شما برای خواندن پست طولانی ، برای به اشتراک گذاشتن هر گونه سوال و افکار دریغ نکنید.

پیام بگذارید

چه اتفاقی در سال 2018 می افتد؟

منتشر شده توسط castroflaviojr در 5 مارس 2018

من به مرور پست های قدیمی وبلاگ می پرداختم و به  این مقاله می  پرداختم که نظرات خود را درباره وضعیت و آینده صنعت شبکه در ژانویه 17 توضیح دادم. در این مقاله ، من می خواهم برای 2018 نیز همین کار را انجام دهم. سال 2017 ، سال های اعتیاد به مواد مخدره بود ، من معتقدم سال 2018 یک سال رقابتی خواهد بود.

برای شروع ، اولین  مشخصات مربوط به 5G است . حراج های طیف اتفاق می افتد . این بدان معناست که بازیکنان جدیدی در حال آمدن هستند و بازارها در حال تکان خوردن خواهند بود ، افرادی که دارای سیستمهای مدیریت بهتر شبکه مانند گوگل هستند ، قطعاً سرمایه گذاری بزرگی را انجام می دهند.

به غیر از تعقیب 5G ، کاهش هزینه ها و افزایش درآمد هنوز هم عامل اصلی نوآوری هستند. هیچ چیز در آنجا تغییر نکرد. در 100 سال آینده تغییر نخواهد کرد. در سال 2017 ، شاهد افزایش تقاضا برای نوآوری های شبکه برای شرکت ها بودیم. این اتفاق به دلیل بلوغ فناوریهای شبیه SDN اتفاق می افتد.

بزرگترین دستاورد سال 2017 ، تفکیک شبکه توسط OCP است. Broadcom همچنان مشخصات فک را  برای چیپست های آینده اعلام می کند . هنوز هم ، رقابت در آن منطقه از نظر ملانوکس ، کاویوم و P4 سالم به نظر می رسد. از طرف سیستم عامل ، Cumulus ، Big Switch ، SnapRoute ، Arista و حتی  OpenSwitch  گزینه های زیادی را ارائه می دهند و هنوز هم به طور پیوسته در حال رشد هستند. علاوه بر این ، AT&T تلاش  خود را برای سیستم عامل منبع باز برای خود انجام می دهد .

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

من فکر می کنم فرصتی برای پشتیبانی تجاری از راه حل های منبع باز وجود دارد. چالش در یافتن مشوق های مناسب نهفته است. کارآفرینان انگیزه کمی برای سرمایه گذاری در یک فناوری خاص مانند OpenStack یا Kubernetes دارند زیرا این یک اثر زودگذر است ، بنابراین انگیزه آنها در ایجاد روابط با مشتری و یادگیری فن آوری در صورت لزوم نهفته است. علاوه بر این ، به نظر می رسد که شرکت ها استخدام نیروی کار متخصص در پروژه های منبع باز مشکل دارند (برخی معتقدند که شرکتها در استخدام به طور کلی وحشتناک هستند) و در پایان با عبور از آن گزینه ها از ابتدا. بازیکنان برنده مانند آمازون ، گوگل و فیس بوک با استخدام نیروی کار ماهر در تیم های چابک ، افزایش میزان یادگیری ، این هزینه و هدیه را از این مزایا غافل نمی کنند.

من ممکن است در اینجا اشتباه کنم ، اما می بینم Juniper در حال انجام یک حرکت قوی به نرم افزار با Contrail است و حتی Junos Space و Cisco هنوز هم Cisco هستند. به عبارت دیگر ، بزرگترین عاملی که موجب تسلط بر بازار می شود ، روابط مشتری است و نه پیروزی در فناوری ، و فناوری همیشه در درازمدت پیروز می شود. در مشخصات شبکه خام ، شک دارم که آنها به BCM برسند. فقط زمان می تواند بگوید.

همه اینها باعث می شود كه من اعتقاد داشته باشم كه سال 2018 تغییرات بزرگی در صنعت آغاز می شود. ما نمی بینیم که این تغییرات تا حداقل سال 2019 نتایج مالی را دگرگون کند ، اما شرط می بندم که ISP های برنده در سال 2020 کسانی باشند که اکنون انتخاب درست فن آوری می کنند. همچنین توجه داشته باشید که سهم بازار در این صنعت در 5 سال گذشته تغییر چندانی نکرده است.

پیام بگذارید

مهندسی ترافیک MPLS – بررسی

مهندسی ترافیک MPLS – بررسی

منتشر شده توسط castroflaviojr در 15 نوامبر 2017

من می خواستم اصول اولیه MPLS و Engineering Traffic (TE) را مرور کنم ، بنابراین به وبلاگ مورد علاقه شبکه خود رفتم و RSVP را جستجو کردم و مقالات زیر را یافتم:
  • طراحی MPLS TE ( قسمت 1 ، قسمت 2 ، قسمت 3 )
  • شیرجه عمیق RSVP ( قسمت 1 ، قسمت 2 )

اگرچه این مقاله باورنکردنی بود و به روشنی فن آوری ها را توضیح می داد ، اما همچنین به وضوح نشان می داد که فناوری های MPLS “میراث” پیچیده هستند. به روز رسانی: من اخیراً در مورد PacketDesign فهمیدم و از مطالبی که در آنجا می گذرد بسیار هیجان زده شدم. کاغذ سفید آنها بر روی MPLS-TE یکی از بهترین قطعاتی است که من در این زمینه دیدم! من از شما می خواهم که آن را بررسی کنید.

این مقاله به 4 بخش تقسیم می شود: اول ، من دلایل ارسال MPLS را ذکر می کنم. دوم ، من به برخی از انگیزه های فن آوری های مهندسی ترافیک می پردازم. سپس ، من به طور خلاصه Segment Routing را توضیح می دهم ، و با یک آموزش در مورد چگونگی دستیابی ONOS با استفاده از یک برنامه SR SDN در بالای OpenFlow نتیجه گیری می کنم.

اصلاً چرا MPLS؟

برای کاهش وضعیت شبکه
امروز جدول مسیریابی کامل اینترنت شامل +600.000 مسیر است. مسیریابی این کار به خودی خود پیچیده است. حال اگر مسیرهای مختلفی را برای کلاسهای مختلف خدمات (CoS) طی کردید ، به راحتی می توانید به مسیرهای 2M برسید. با MPLS ، شما اساساً می توانید چندین پیشوند شبکه را در برچسب ها جمع کنید و حالت را به شدت کاهش دهید. مقالاتی که در ابتدا به آنها اشاره کردم ، به برخی از این شماره ها می پردازد. یک معماری Segment Routing (SR) می تواند این تعداد را حتی به ترتیب تعداد دستگاه های شبکه کاهش دهد. ps: SR را می توان با محصورسازی IPV6 نیز بدست آورد.

چرا مهندسی ترافیک؟

برای صرفه جویی در پول!! $ $ $

دیپتانشو سینگ با شگفتی این موضوع را توضیح می دهد ، بنابراین از شما می خواهم در صورت نیاز به توضیحی دقیق تر مقاله وی را بررسی کنید.

به عنوان مثال ، بگویید که شبکه Comcast در محله شما دارای 1 گیگابیت بر ثانیه VOIP و 4 گیگابیت ثانیه تقاضای ترافیک داده است. این 50 درصد پیش بینی شده است ، بنابراین پیوندهای 10G آن در حال حاضر کفایت می کنند. حال فرض کنید که ترافیک آن در سال آینده 20٪ افزایش یابد ، با حفظ این استراتژی نیاز به ارتقاء فوری زیرساخت ها است.

یک استراتژی Diffserv می تواند نرخ تخصیص منابع را تغییر دهد: در عوض می توان نرخ پیش بینی 2 برابر برای VOIP و پیش بینی 1.2 برابر داده ها را اختصاص داد. نتیجه حاصل از پهنای باند در کل 2.4 + 6 گیگابیت بر ثانیه (1G * 120٪ * 2 ، داده های صوتی به علاوه 20٪ افزایش بار بیش از حد 2 برابر نرخ پیش بینی) سال آینده ، شما 2.8 8 7.2 Gbps از داده ها ، که هنوز کوچکتر از 10G است. با استفاده از این رویکرد ، Comcast می تواند ارتقاء ستون فقرات خود را به مدت 2 سال به تأخیر اندازد و هنوز هم می تواند SLA مورد نیاز برای ترافیک حساس را رعایت کند.

با اولین قانون ، نرخ انبساط شما توسط رشد ترافیک عمومی مشخص می شود زیرا شما باید استفاده از شبکه را کم نگه دارید. در مورد دوم ، سرعت انبساط شما با رشد بحرانی وسعت چرخه تجهیزات و شبکه (در دسترس شما) موظف است. ترافیک بحرانی 5 برابر کوچکتر از بهترین تلاش است ، بنابراین اگر به ترافیک بهترین تلاش اهمیتی نمی دهید سرعت گسترش شما 5 برابر کمتر خواهد بود.

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

چرا بخش مسیریابی؟

من می خواستم فناوری های میراث (RSVP ، LDP) را با SR مقایسه کنم ، اما فهمیدم این بی معنی است. برای من ، تنها دلیلی که میراث استفاده می کنید ، سازگاری عقب با تجهیزات موجود است. اشتباه نکنید ، RSVP کار را تمام می کند. همچنین ، ممکن است شما نتوانید هزینه آن را با SR جایگزین کنید یا شاید زیرساخت RSVP شما کاملاً کار کند و شما هم اکنون فرایندهای مناسبی را انجام دهید.

همه اینها گفتند ، SR ساده تر و بهتر است. برای کسب اطلاعات بیشتر در مورد RSVP ، خودتان را بررسی کنید:  http://packetpushers.net/rsvp-te-protocol-deep-dive/ . اگر چیزی در مورد SR نمی دانید ، http://www.segment-routing.net/ را بررسی  کنید .

به طور خلاصه ، SR یک معماری شبکه است که به شبکه اجازه می دهد حالت جریان نداشته باشد. در عوض فقط بسته های ارسال شده بر اساس آدرس مقصد IP ، آنها بر اساس آدرس بخش ارسال می شوند. این شبکه کوتاهترین مسیر را برای انتقال اطلاعات به هر بخش و مسیرهای پشتیبان حفظ می کند تا مسیر بازگشت سریع را انجام دهد. تغییر سریع سریع به خودی خود ارزش پول دارد ، SR TILFA امکان بازیابی خرابی زیر 50ms را فراهم می کند.

علاوه بر این ، معماری به شما امکان می دهد تا مسیریابی منبع سست را اعمال کنید. به عنوان مثال ، بگویید ، IGP OSPF مسیری 40ms خواهد داد ، برای هدایت ترافیک VoIP خود از طریق گره 104 ، شما فقط مسیریابی خود را در لبه شبکه تغییر می دهید تا آن بخش را قبل از مقصد نهایی شامل کنید.

 SR

آموزش

من قبلاً  در این مورد یک آموزش 2 ساله نوشتم . من فقط قصد دارم نکات اصلی را برجسته کنم.

شات صفحه نمایش 2015-08-13 در 4.46.02 PM.png

در این پیکربندی ، یک خوشه 3 کنترل کننده ONOS SDN دارید که پارچه ای از ستون فقرات برگ را کنترل می کنند. گره های ورودی ، یک جستجوی مسیر را انجام داده و بسته ها را با خبرنگار برچسب MPLS در گره خروجی محوطه کنید. سپس بسته بندی با استفاده از کوتاه ترین مسیر بر اساس برچسب MPLS ارسال می شود. این انتقال اصلی IP است. نکته جالب اینجاست که می توان تونل های حمل و نقل را به طور برنامه ای تنظیم کرد.

بیایید بگوییم که شما می خواهید همه ترافیک Netflix از ستون فقرات s105 بگذرد ، بنابراین اطمینان حاصل کنید که تمام ترافیک وب و صدا دارای 3 باند پهنای باند بوده و در نتیجه تاخیر کمتری دارند ، می توانید یک روش تونل را به روش زیر ایجاد کنید:

یک تونل به عنوان مجموعه ای از LABELS تعریف شده و مسیری را که توسط یک جریان انجام می شود ، تعریف می کند. دستور زیر یک تونل به نام FASTPATH ​​را از طریق روترهای 101 ، 105 و 102 به آن ترتیب فوری می کند.

onos> srtunnel-add FASTPATH 101,105,102

سپس ، می توانید یک سیاست برای زیرمجموعه های ترافیک اعمال کنید ، به عنوان مثال ، Policy1 = tcp_port = 80 >> fwd (TUNNEL_1)

onos> srpolicy-add p1 1000 10.1.1.1/24 80 10.0.2.2/24 80 TCP TUNNEL_FLOW FASTPATH

این تونل ها می توانند برای تقویت سیاست های TE و تضمین SLA و بهبود استفاده از شبکه استفاده شوند.

نتیجه

یک شبکه Segment Routing همراه با یک کنترلر متمرکز برای محاسبه مسیر می تواند قابلیت های پیشرفته مهندسی ترافیک Real-Time را فعال کند. به این ترتیب ، Segment Routing یک بازی مناسب برای SDN است.

برنامه های SDN قبلاً در پروژه های منبع باز مانند ONOS توسعه داده شده است. برنامه Segment Routing ذکر شده به TRELLIS تبدیل شده است ، که پارچه شبکه ای است که از Cord projec t پشتیبانی می کند . من از شما می خواهم که کار آنها را بررسی کنید.

لطفاً اگر سؤالی در مورد چگونگی پیشروی و اجرای این مسئله دارید ، با من تماس بگیرید.

 

پیام بگذارید

ملزومات DevOps: محیط توسعه دهنده

منتشر شده توسط castroflaviojr در 7 نوامبر 2017

“90٪ برنامه نویسی اشکال زدایی است ، 10٪ دیگر اشکالات را می نویسد.”

اگر کدی را تهیه کردید می دانید که این واقعیت چقدر صحیح است. این بدان معنی است که شما سرعت اشکالات را تصحیح می کنید همان چیزی است که واقعاً سرعت انتشار ویژگی شما را دیکته می کند. این مربوط به یک بخش مهم DevOps: CI / CD است. ادغام ادامه می دهد تا باگها سریعتر پیدا شوند ، استقرار مداوم اجازه می دهد تا اصلاحات سریعتر در تولید منتشر شود.

در این پست ، من در مورد اهمیت یک محیط توسعه دهنده پایدار (Dev Env) صحبت می کنم و یک آموزش کوتاه در مورد چگونگی راه اندازی یک محیط مسیریابی مجازی با ابزار منبع باز ارائه شده توسط Cumulus ارائه می دهم.

چرا اصلاً زحمت می کشید؟

DevEnv برای تست اسکریپت های اتوماسیون شما برای هر تیم توسعه موثری ضروری است. این اجازه می دهد تا شیاطین به جای چند روز مستقل از دیگران ، کد خود را تست کنند و سرعت آنها را به شدت افزایش دهد. همچنین با اطمینان از اینکه همه devs از همان نقطه پایدار شروع می کنند ، همکاری را بهبود می بخشد.

در اینجا مثالی از چقدر بد بودن آن آورده شده است: شرکت ABC فقط یک محیط آزمایش دارد که در آن تمام آزمایشات را انجام می دهد. بگویید یک فرایند برنامه ریزی خوب امکان استفاده از 50٪ را دارد و هر یک از برنامه ها 1 ساعت طول می کشد تا یک اسکریپت را اجرا کرده و نتیجه آن را تأیید کنید و یک ساعت دیگر برای پاکسازی محیط. یک روز کاری 8 ساعت است که در آن 4 ساعت استفاده می شود و بنابراین فقط 2 تست در روز می تواند انجام شود. در این حالت ، مهم نیست که تیم شما چقدر بزرگ باشد ، شما فقط می توانید در هر روز 2 ویژگی یا رفع را فشار دهید. این تقریباً یک کلاه ثابت در بهره وری تیم است.

انتخاب فناوری

مدتی است که می خواهم یک محیط مجازی ایجاد کنم. در ابتدا ، من سعی کردم از Mininet استفاده کنم ، در حالی که برای مسیریابی با استفاده از کواگا کافی است ، کار زیادی لازم بود تا آن را به روشی تنظیم کنم که بتوانم از آن برای تست اسکریپت ها استفاده کنم. گزینه های دیگر eve-ng (uNetLab) ، GNS3 و واژگون بود. من فوراً از GNS3 عبور کردم زیرا منحنی سربار و یادگیری قابل توجه است. اگر مجبور شدم IOS را اجرا کنم ، می خواستم برای شبانه روزی بروم ، اما چنین نمی کنم. علاوه بر این ، منحنی یادگیری برای آشفتگی کوتاه تر بود ، بنابراین برای بیشتر افراد مفید است.

Kudos to Cumulus برای تهیه منابع این امر ، بسیار شگفت آور است که فروشندگان به جای گرفتن کد از دیگران یا ترویج فن آوری های خاص خود ، به کدهای چند منظوره کمک می کنند و از شما می خواهم که کار آنها را بررسی کنید. می توانید از اینجا شروع کنید.

شروع سریع

سلب مسئولیت: این کد در دسترس است کومولوس گیتهاب . قبل از اجرای این نسخه ی نمایشی ، VirtualBox و Vagrant را نصب کنید.

### Bring up the vagrant topology
git clone https://github.com/cumulusnetworks/cldemo-vagrant
cd cldemo-vagrant
vagrant up oob-mgmt-server oob-mgmt-switch leaf01 leaf02 spine01 spine02 server01 server02

### setup oob mgmt server
vagrant ssh oob-mgmt-server

### Run the ROH demo
git clone https://github.com/cumulusnetworks/cldemo-roh-ansible
cd cldemo-roh-ansible
ansible-playbook run-demo.yml

### check reachability of server02 from server01
ssh server01
wget 10.0.0.32
cat index.html

توپولوژی سفارشی

برای اجرای این آموزش فقط به واگرا ، Virtualbox و git نیاز دارید. Vagrant واقعاً ساده است ، وقتی یک فایل vagrantFile دارید ، دقیقاً به یک خط کد احتیاج دارید تا محیط خود را ارتقا دهید. بخش دشوار ساخت فایل Vagrant است ، Cumulus نه تنها قالب ها بلکه ابزاری برای ایجاد پرونده از یک فایل توپولوژی را در اختیار شما قرار می دهد. این مبدل توپولوژی است.

cldemo_topology

شکل بالا توپولوژی پیش فرض را نشان می دهد ، می توانید با ویرایش پرونده توپولوژی آن را تغییر دهید و دوباره topology_converter را اجرا کنید:

python topology_converter.py topology.dot

پس از آن به سادگی انجام دهید. پررنگ و رونق.

vagrant up
vagrant ssh oob-mgmt-server

نتیجه

در این پست ، من در مورد اهمیت یک محیط توسعه دهنده پایدار و نحوه متناسب شدن آن در چارچوب DevOps صحبت کردم. من همچنین نمونه ای از چگونگی ایجاد یک محیط را ارائه کردم.

این پیوند به گزاره ارزش SDN باز می گردد: توانایی اجرای فرایندهای نرم افزاری برای بهبود زیرساخت های شما. اما ، مردم سالها دستگاههای شبکه را مجازی کرده اند ، چیز جدیدی در آنجا نیست. درست است که هنوز هم ، بخش قابل توجهی از اپراتورهای شبکه برای آزمایش سیستم هایشان ، محیط مجازی ندارند. از طرف دیگر ، با ظهور OpenVSwitch و ایجاد Mininet ، توسعه دهندگان SDN با استفاده از شبیه سازی شبکه برای توسعه سیستم های SDN شروع به استفاده کردند و همواره این امر را به عنوان یک افزایش چابکی توسعه در نظر گرفته اند.

این همچنین به من فکر می کند که چگونه P4  می تواند سیستم های سازمانی را بهبود ببخشد ، اما من این کار را برای پست آینده رها می کنم. باز هم لطفاً نظرات خود را در این باره به من اطلاع دهید

پیام بگذارید

آیا P4 می تواند شبکه تعریف شده توسط نرم افزار را نجات دهد؟

منتشر شده توسط castroflaviojr در تاریخ 24 اکتبر 2017

اکنون ، P4 به دلیل درگیر شدن بازیکنان بزرگی مانند Google و AT&T در حال افزایش است. P4 پتانسیل ایجاد تغییرات اساسی در صنعت و ارائه گزاره ارزش SDN را دارد. من می خواهم در مورد آن بحث کنم.

به طور خلاصه ، هدف P4 ارائه 3 هدف اصلی است:

  • تنظیم مجدد
  • استقلال پروتکل
  • استقلال هدف

OpenFlow نواقص خود را داشت: به نوعی تنوع استراتژیهای اجرای به ناسازگاری تبدیل شد. استقلال هدف P4 پیشنهاد می کند که این مسئله را با استفاده از کامپایلر برای ترجمه کد P4 به کد سوئیچ با در نظر گرفتن قابلیت های آن حل کنید.

عکس صفحه نمایش 2017-10-20 در ساعت 1.35.00 PM

برای فهمیدن این مسئله چقدر مختل کننده است ، بیایید به وضعیت کنونی نگاه کنیم: فروشندگان سیلیکون کالا مانند Broadcom و Mellanox از قبل API برای کنترل سوئیچ های خود دارند ، وجود این API در حال حاضر باعث اختلال در صنعت فعال سازی Cumulus ، SnapRoute شده است. و حتی آریستا اکنون ترجیح می دهید که فروشندگان سیلیکون شما رابط مشترک برقرار کنند ، یا ترجیح می دهید هر زمان که می خواهید یک فروشنده جدید سوئیچ را آزمایش کنید ، نرم افزاری را بازنویسی کنید؟ پاسخ واضح است: گزینه اول به نفع کاربران و فروشندگان جدید ، دوم مزایای فروشندگان تأسیس شده است. بازیکنان صنعت جدید یا اپراتورهای پرماجرا می توانند نرم افزاری را بالای P4 بنویسند و به هزینه نوشتن کامپایلر برای هر فروشنده ای که از آنها استفاده می کنند ، به ادغام چند فروشنده برسند.

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

بازیکنان صنعت جدید یا اپراتورهای ماجراجویانه از طرف دیگر ، می توانند نرم افزاری را در بالای P4 بنویسند و به قیمت نوشتن کامپایلر برای هر فروشنده ای که از آنها استفاده می کنند ، به یکپارچه سازی چند فروشنده بپردازند. این می تواند تغییر بازی کند ، سؤالات بزرگ این است: ” توسعه دهندگان چقدر مشتاق هستند که بتوانند نرم افزار P4 بنویسند؟” ،   “چقدر است که شخصی را برای انجام آن استخدام کنند؟” ، علاوه بر این ، ” چه کسی کامپایلر P4 خاص Cisco / Broadcom را خواهد نوشت. کد؟ “

فرصت های بی پایان وجود دارد: در یک جهان موازی ، AT&T سیسکو را مجبور می کند تا کامپایلر P4 را به دستگاه های خود فعال کند ، سیسکو کامپایلر بدی را می نویسد ، ادعا می کند که این فناوری بد است و به جای شما ACI را به شما می فروشد. در دنیای متفاوت ، Barefoot یک کامپایلر Broadcom را تأیید می کند که کار می کند ، اما پس از آن برخی منابع را برای تبلیغ یک رقیب “هدر می دهد”. کمی واقع بینانه تر ، SnapRoute یا Cumulus می توانند یک کامپایلر P4 را برای Broadcom Tomahawk بنویسند ، و بدین ترتیب قادر خواهند بود تا نرم افزارهای خود را در مجموعه دستگاههای موجود فعال کنند. حتی واقع بینانه تر ، Barefoot کامپایلر خود را به Tofino می نویسد و فروش P4 را به یک بازار محدود با طاقچه محدود ادامه می دهد.

حال اگر Barefoot مسئولیت نوشتن یک کامپایلر P4 برای Broadcom و Mellanox را بر عهده بگیرد که برای فروشندگان و اپراتورهای NOS به ارزش بسیار زیادی ترجمه شود. از آنجا که آنها قادر به تغییر یکپارچه فروشندگان هستند. این امر باعث افزایش حاشیه ای تصویب توفینو خواهد شد ، بنابراین این سؤال باقی می ماند ، چه کسی این هزینه را پرداخت می کند؟

اکنون چقدر برای اتخاذ P4 هزینه دارد؟

قبل از اینکه به این سؤال پاسخ دهم ، می خواهم به نقطهای قبلی بپردازم که در مورد جداسازی شبکه نوشتم . من این کار را پرسیدم: ” D Oes OpenFlow به طور مؤثر شما را قفل می کند؟” اکنون ممکن است همین سؤال در مورد P4 اعمال شود.

سوال به خودی خود گمراه کننده است. من فروشندگان را شنیده ام که می گویند “OpenFlow شما را قفل می کند ، ممکن است فقط SDN ما را بخرید” . همین خیلی اشتباه است OpenFlow بی نقص نیست ،  اما به شما امکان می دهد فرآیندهای نرم افزاری را برای ارائه ویژگی ها بسیار سریعتر از آنچه فروشنده شما انجام می دهد ، اتخاذ کنید.

هر انتخاب یک مانع بالقوه است و کمی شما را قفل می کند ، اما آنچه که همه هنگام صحبت از قفل به آن اشاره می کنند ، قفل کردن سخت افزار است. هنگامی که شما یک رایانه x86 عمومی را خریداری می کنید ، می توانید Ubuntu ، Debian ، Windows یا هر آنچه را دوست دارید نصب کنید ، هنگام خرید پلی استیشن ، فقط نمی توانید Xbox را روی آن نصب کنید ، این قفل فروشنده است ، هزینه های انجام آن که منع کننده هستند ، بهتر است فقط یک وسیله دیگر بخرید.

شما می توانید به سختی و بدون هیچ هزینه ای آزمایشگاه OpenFlow یا آزمایش میدانی را در دستگاه های شبکه مبتنی بر Broadcom انجام دهید و در صورت برآورده نشدن نیازهای شما به Cumulus مراجعه کنید. با کمال تعجب ، فروشندگان ادعا می کنند آزمایشات آزمایشگاهی به دلیل کیفیت محصول مورد نیاز نیست ، اما این تجربه به شما خواهد گفت که همیشه یک ویژگی از دست رفته وجود خواهد داشت.

اکنون P4 ، از منظر ماجراجویانه ، P4 عالی است ، شما فقط باید نرم افزارهای بیشتری بنویسید تا این کار را انجام دهد. برای هر کس دیگری هزینه قابل توجهی دارد: شما باید این کار را برای توسعه دهندگان حق بیمه خود انجام دهید یا خود Barefoot را انجام دهید. در صورت استفاده از Broadcom + Big Switch ممکن است این هزینه ناچیز باشد ، در حال حاضر به شما ابزاری برای بهبود روند فعلی خود می دهد.

OpenFlow vs P4

OpenFlow قرار است 10 سال دیگر سال آینده باشد ، مقدار قابل توجهی از منابع برای آزمایش آن استفاده شده است. اگر اشتباه نکنم این 3 سال است که توسط Big Switch برای تجارت پشتیبانی شده است. با قاطعیت می گویم که می توانید یک سال تولید راه حل OpenFlow را تهیه کنید. در واقع ، آیا می توانید P4 را آماده کنید تا در یک سال در تولید مستقر شود؟

تصورات غلط:

  • آیا P4 جایگزین OpenFlow خواهد شد؟ شاید. P4 گزاره ارزش دیگری را ارائه می دهد. عوامل OpenFlow ممکن است بالای P4 نوشته شود. اجرای عالی P4 ممکن است OF را منسوخ کند.
  • آیا P4 جایگزین Broadcom SDK خواهد شد؟ همان پاسخ ، P4 ممکن است یک API بسیار بهتر را در بالای خود بنویسد.
  • آیا P4 جایگزین OpenNSL خواهد شد؟  چرا که نه؟
  • آیا P4 جایگزین NetFlow / Sflow خواهد شد؟ No. Sflow پروتکل برای صادرات داده ها از سوئیچ ها است ، درمورد نحوه اجرای آن در بانک اطلاعاتی (مقدار زیادی) نمی گوید.
  • آیا P4 جایگزین Riverbed خواهد شد؟ به هیچ وجه.
  • آیا P4 جایگزین OpenConfig خواهد شد؟ نه ، آنها در واقع کاملاً مکمل هستند.

با تشکر از خواندن پست طولانی. من از هرگونه فکر یا سؤال استقبال می کنم.

6 نظر

کنترل تراکم TCP BBR در Mininet

منتشر شده توسط castroflaviojr در 10 اکتبر 2017

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

این پست به سه بخش تقسیم می شود: پیش زمینه در مورد چالش های BBR ، آموزش و فنی.

پیش زمینه در BBR

TCP BBR به طور قابل توجهی افزایش یافته و باعث کاهش تأخیر در شبکه های ستون فقرات داخلی گوگل می شود. از این منبع عالی:

TCP BBR  مبتنی بر نرخ است  نه مبتنی بر پنجره. یعنی در هر زمان ، TCP BBR به جای ارسال داده های جدید در پاسخ به هر ACK دریافت شده ، با یک نرخ محاسبه شده مشخص می فرستد  . به طور خاص ، TCP BBR مستقیماً ارسال داده های جدید را با دریافت ACK پیوند نمی دهد ، بنابراین ، به بیان دقیق ، در واقع اجرای پنجره های کشویی نیست. بنابراین ، ما نمی توانیم به درستی درباره پیروزی یا صحبت کنیم  cwnd. در عوض ، ما در مورد تعداد بسته های در پرواز صحبت می کنیم ، یعنی نرخ بار RTT واقعی است ، با این درک که این تعداد ممکن است با شرایط متفاوت باشد.

اصولاً ، BBR پهنای باند پهنای باند را با ردیابی میزان بازده محاسبه می کند: اگر افزایش در میزان ارسال کننده باعث افزایش محصول مشاهده نشود ، فرض می کنیم که پهنای باند موجود است. در انجام این کار از نظر منطقی مؤثر است و از این طریق کمترین صف را در شبکه فراهم می کند.

توان TCP معکوس با RTT متناسب است و اکثر پیاده سازی های TCP باعث تاخیرهای اضافی می شوند ، در نتیجه ، TCP به خودی خود هرگز نمی تواند به 100٪ استفاده برسد. BBR تغییر می کند ، به همین دلیل چنین دستاورد چشمگیر است.

شروع سریع

Open Source بسیار عالی است زیرا اجازه می دهد تا نوآوری بسیار سریعتر مستقر شود ، BBR در هسته لینوکس پیاده سازی شده است و با استفاده از Mininet می توانید بلافاصله آن را آزمایش کنید.

من مدتهاست که طرفداران وب سایت هستم: تولید مثل تحقیقات شبکه از استنفورد. من برای این آزمایش اکثر کد Mininet را از آنجا استفاده کردم.

حالا بیایید به آن برسیم !! این آموزش فرض می کند که شما واضح و واضح هستید. اگر این کار را نکنید ، وحشت نکنید ، این لینک را دنبال کنید . برای شروع شما نیاز به راه اندازی VM. من از تمام وابستگی های شما مراقبت کردم. اگر می خواهید آنچه را که من انجام می دهم را بررسی کنید و به نقش mininet در پوشه مناسب بپردازید.

git clone https://github.com/castroflavio/bbr-replication/
git checkout vagrant
vagrant up

این کار باید 10 دقیقه طول بکشد. بعد از اتمام کار ادامه دهید

vagrant ssh
cd mininet
sudo ./figure5.sh all

بعد از حدود 30 ثانیه آزمایش باید انجام شود و می توانید از VM خارج شوید:

exit
open figure5_mininet/figure5_mininet.png

این باید شکل زیر را باز کند:figure5_mininet

شکل موجود ، تأخیر را در TCP BBR و TCP CUBIC مقایسه می کند (کمتر بهتر است). و همانطور که مشاهده می کنید BBR تأخیر را از 150 میلیون پوند به 50 میلیون پوند (66٪) به طور متوسط ​​و از 400ms به 50ms (87٪) در بدترین حالت کاهش می دهد. این دیوانه است!

چالش های فنی

اولین چالش فنی ، یافتن هسته لینوکس است که BBR را پیاده سازی می کند ، و به نظر می رسد که در 4.9 اجرا شده است ، بنابراین به دنبال آن باشید. چالش دوم اجرای مکانیسم قدم زدن BBR بود که در وب سایت CS244 ذکر شد اما من در ابتدا آن را نفهمیدم.

BBR به مکانیسمی برای کنترل نرخ فرستنده احتیاج دارد و از ماژول tc (کنترل ترافیک) از لینوکس استفاده می کند. من در مورد tc می دانستم اما نمی دانستم چنین ابزاری قدرتمند است. بعد از تحقیقات درمورد مکانیزم های صف بندی لینوکس ، دریافتم که BBR به ردیف صف بندی fq (صف انتظار) نیاز دارد زیرا از آن استفاده می کند تا کنترل کننده فرستنده را کنترل کند. به نظر می رسد Mininet به دلایلی از fq پشتیبانی نمی کند ، و من مجبور شدم چند خط کد را تغییر دهم تا به آن پشتیبانی اضافه کنم.

نتیجه

TCP ده ها سال است که وجود دارد و ده ها سال در تلاش بودند تا آن را بهبود بخشند. در ابتدا ، مکانیسم کنترل تراکم TCP به معنای واقعی کلمه اینترنت را نجات داد ، اکنون می خواهم جسور باشم و می گویم BBR با ارائه یک کنترل احتقان “quueless” موجب صرفه جویی در برنامه های حساس به تأخیر می شود. این واقعاً کار بزرگی است. من شما را به شدت امتحان می کنم ، حداقل کاری که باید انجام دهید این است که مقاله زیر را بررسی کنید:  سرعت اینترنت سرور linux خود را با کنترل تراکم TCP BBR افزایش دهید.

برای مراجعات بعدی:

  • تولید مثل کنترل تراکم مبتنی بر تراکم با BBR
  • آشنایی با شبکه های رایانه ای از پیتر لارس دوردال: فصل 18 و فصل 15
  • صف بندی در پشته شبکه لینوکس توسط Dan Siemon
  • کنترل ترافیک
  • رشته های صف بندی کلاس
  • قدم زدن مبتنی بر HTB
تماس با ما