3. Дизайн мережі підприємства на комутаторах Extreme

Добрий день друзі! Сьогодні я продовжу цикл, присвячений комутаторам Extreme статтею з проектування мережі Enterprise.

У статті я постараюся по можливості коротко:

• описати модульний підхід до проектування мережі Etnterprise
• розглянути види побудови одного з найважливіших модулів мережі підприємства – опорної мережі (ip-campus)
• описати переваги та недоліки варіантів резервування критичних вузлів мережі
• на абстрактному прикладі спроектувати/оновити невелику мережу Enterprise
• вибрати комутатори Extreme для реалізації спроектованої мережі
• попрацювати з волокнами та IP адресацією

Ця стаття буде цікавою більшою мірою мережевим інженерам і адміністраторам мережі підприємств, які тільки починають свій шлях «мережі», ніж досвідченим інженерам, які багато років пропрацювали в операторах зв'язку або у великих корпораціях з географічно-розподіленими мережами.

У будь-якому випадку, хто зацікавився прошу під кат.

Модульний підхід проектування мережі

Почну я свою статтю з досить популярного модульного підходу при проектуванні мережі, який дозволяє зібрати пазл зі шматочків мережі в 1 цільну картину.

Спочатку трохи абстракції — я дуже часто уявляю цей підхід як zoom на гео-картах, коли у першому наближенні видно країну, у другому регіони, у третьому міста тощо.

Як приклад розглянемо такий приклад:

• 1-е наближення - вся мережа підприємства являє собою набір різних рівнів:
  • опорна мережа або campus
  • граничний рівень
  • рівень операторів зв'язку
  • віддалені зони

• 2-е наближення - кожен із цих рівнів деталізуються на окремі модулі
  • опорна мережа або campus складається з:
    • 3-х або 2-х рівнів модуля, що описує мережу підприємства та її рівні - доступ, розподіл та/або ядро
    • модуля, що описує ЦОД - центр обробки даних (по суті серверну частину інфраструктури)

  • граничний рівень у свою чергу складається з:
    • модуля підключення до Інтернету
    • модуля WAN та MAN, який відповідає за підключення географічно розподілених об'єктів підприємства
    • модуль для побудови VPN тунелів та Remote-Access доступу
    • найчастіше у багатьох невеликих підприємств кілька цих модулів або навіть всі з них виявляються поєднані в одному

  • рівень провайдерів:
    • в даний рівень входять зв'язки «в зовнішній світ» - темні оптоволокна (оренда волокон у операторів), канали зв'язку (Ethernet, G.703 і т.д.), доступ до Інтернету.

  • віддалений рівень:
    • здебільшого це філії підприємства, які розподілені у межах міста, області, країни і навіть континентів.
    • також до цієї зони можуть належати резервний ЦОД, який дублює роботу основного
    • і набирають останнім часом популярність — teleworkers (віддалені робочі місця)

• 3-тє наближення — кожен із модулів дробиться більш дрібні модулі чи рівні. Наприклад у campus-мережі:
  • 3-х рівнева мережа поділяється на:
    • рівень доступу
    • рівень розподілу
    • рівень ядра

  • ЦОД у складніших випадках може ділитися на:
    • 2-х або 3-х рівневу мережеву частину
    • серверну частину

  Все вищеописане я намагатимуся відобразити в наступному спрощеному малюнку:

  
  
  Як видно з малюнка вище, модульний підхід допомагає деталізувати і структурувати загальну картину на складові елементи, з якими надалі вже можна працювати.

  У рамках цієї статті я зупинюся на рівні Campus Enterprise та опишу його детальніше.

  Види IP-CAMPUS мереж

  Під час роботи в провайдері і особливо пізніше — в роботі інтегратора, я стикався з різною «зрілістю» мереж замовника. Я не даремно застосовую термін зрілість, тому що досить часто трапляються випадки, коли структура мережі зростає зі зростанням самої компанії, і це в принципі закономірно.

  У невеликій компанії, що знаходиться в межах однієї будівлі, мережа підприємства може складатися лише з 1 граничного маршрутизатора, що виконує роль міжмережевого екрану, декількох комутаторів доступу і пари-трійки серверів.

  Я називаю таку мережу для себе "однорівневою" мережею - в ній абсолютно відсутній явний рівень ядра мережі, рівень розподілу зміщений на граничний маршрутизатор (з функціями firewall, VPN і можливо proxy), а комутатори доступу обслуговують як комп'ютери співробітників, так і сервери.

  
  
  У разі зростання підприємства — збільшення кількості співробітників, сервісів та серверів, часто доводиться:

  • збільшувати кількість комутаторів у мережі та портів доступу
  • збільшувати серверні потужності
  • боротися з широкомовними доменами - впроваджувати сегментування мережі та маршрутизацію між сегментами
  • боротися зі збоями в роботі мережі, через які виникають простої у співробітників, оскільки це тягне за собою додаткові фінансові витрати для керівництва (співробітник простоює, зар. плата сплачується, а робота не робиться)
  • в процесі боротьби зі збоями, замислюватися про резервування критично важливих вузлів мережі - маршрутизаторів, комутаторів, серверів та сервісів
  • посилювати безпекову політику, оскільки можуть виникати комерційні ризики і знову ж таки — для більш стабільної роботи мережі

  Все це призводить до того, що інженер (адміністратор мережі) рано чи пізно замислюється про правильну побудову мережі і вже приходить до 2-х рівневої моделі.

  Ця модель вже явно виділяє із себе 2 рівні - рівень доступу і рівень розподілу, який за сумісництвом є і рівнем ядра (collapsed-core).

  Поєднаний рівень розподілу та ядра виконує такі функції:

  • агрегує в собі лінки від комутаторів доступу
  • вводить маршрутизацію сегментів мережі - користувачів і пристроїв стає так багато, що в одну мережу /24 вони не поміщаються, а якщо поміщаються, то broadcast-шторми викликають постійні збої (особливо якщо користувачі допомагають їм створюючи петлі)
  • забезпечує зв'язок між сусідніми сегментами комутаторів (за більш швидкісними лінками)
  • забезпечує зв'язок між користувачами та їх пристроями та серверною фермою, яка теж на цей час починає виділятися в окремий сегмент мережі - ЦОД.
  • починає забезпечувати спільно з комутаторами доступу тією чи іншою мірою політику безпеки, яка починає з'являтися у підприємства до цього часу. Компанія зростає, комерційні ризики також зростають (тут я маю на увазі не тільки положення про комерційну таємницю, розмежування політик доступу і т.д., але й про елементарні простої мережі та співробітників).

  Таким чином мережа рано чи пізно зростає до 2-х рівневої моделі:

  
  
  У цій моделі з'являються особливі вимоги як до комутаторів рівня доступу, які агрегують у собі лінки від користувачів та пристроїв мережі (принтери, точки доступу, VoIP пристрої, IP-телефонів, IP-камер тощо), так і до комутаторів рівня розподілу. та ядра.

  Комутатори доступу повинні бути вже більш інтелектуальні та функціональні, щоб задовольняти вимоги продуктивності, безпеки та гнучкості мережі, та повинні:

  • мати різні види портів доступу та магістральних портів — бажано з можливістю запасу як для зростання трафіку, так і за кількістю портів
  • мати достатню комутаційну ємність та пропускну здатність
  • мати необхідний функціонал безпеки, який задовольняв би поточну безпекову політику (а в ідеалі та зростання її подальших вимог)
  • мати можливість живлення важкодоступних мережевих пристроїв з можливістю віддаленого перезавантаження їх живлення (PoE, PoE+)
  • мати можливість резервувати власне електроживлення, щоб використовувати це в тих місцях, де це необхідно
  • мати (по можливості) подальший потенціал зростання функціоналу — частий приклад, коли комутатор доступу з часом перетворюється на комутатор розподілу.

  До комутаторів розподілу у свою чергу також пред'являються відповідні вимоги:

  • як у частині магістральних низхідних портів у бік комутаторів доступу, так і в сторону peer інтерфейсів сусідніх комутаторів розподілу (а в подальшому і можливих uplink інтерфейсів у бік ядра)
  • у частині L2 та L3 функціоналу
  • у частині функціоналу безпеки
  • у частині забезпечення відмовостійкості (резервування, кластеризація та резервування ел. харчування)
  • щодо забезпечення гнучкості при балансуванні трафіку
  • мати (по можливості) подальший потенціал зростання функціоналу (трансформація з часом влаштування агрегації в ядро)
  • у деяких випадках на комутаторах розподілу може бути доречним використовувати PoE, PoE+ порти.

  Далі — більше: у разі проведення керівництвом політики активного зростання та розвитку підприємства мережа надалі також продовжуватиме розвиватися — підприємство може почати орендувати сусідні будівлі, будувати свої власні корпуси або поглинати дрібніших конкурентів, збільшуючи тим самим кількість робочих місць для співробітників. Водночас відбувається зростання мережі, яке вимагає:

  • забезпечення співробітників робочими місцями - необхідні нові комутатори доступу з портами доступу
  • наявність нових комутаторів розподілу для агрегування лінків від комутаторів доступу
  • побудови нових, а також модернізації існуючих ліній зв'язку

  Як наслідок відбувається зростання трафіку з таких причин:

  • через збільшення портів доступу та відповідно користувачів мережі
  • через збільшення трафіку суміжних підсистем, які обирають для себе як транспорт мережу підприємства — телефонія, безпека, інженерні системи тощо.
  • через впровадження додаткових сервісів — зі зростанням персоналу з'являються нові відділи, які потребують певного програмного забезпечення
  • збільшуються обчислювальні потужності ЦОД, щоб задовольняти вимоги інфраструктури та додатків
  • зростають вимоги безпеки до мережі та інформації - знаменита тріада ЦРУ (жарт), а якщо серйозно, то CIA - Confidentiality, Integrity and Availability:
    • у зв'язку з цим, до критичних рівнів мережі — розподілу та ЦОД з'являються додаткові вимоги щодо відмовостійкості та резервування
    • знову ж таки відбувається зростання трафіку через впровадження нових систем безпеки - наприклад РКВІ і т.д.

  Рано чи пізно зростання трафіку, сервісів та кількості користувачів призведе до необхідності впровадження додаткового рівня мережі — ядра, яке виконуватиме високошвидкісну комутацію/маршрутизацію пакетів із використанням високошвидкісних лінків зв'язку.

  У цей момент підприємство може перейти до 3-х рівнів моделі мережі:

  
  
  Як видно на малюнку вище — у такій мережі є рівень ядра, який агрегує в собі швидкісні лінки від комутаторів розподілу. Таким чином до комутаторів ядра також висуваються вимоги щодо:

  • пропускну здатність інтерфейсів - 1GE, 2.5GE,10GE, 40GE, 100GE
  • продуктивності комутатора (switching capacity і forwarding perfomance)
  • типів інтерфейсів - 1000BASE-T, SFP, SFP+, QSFP, QSFP+
  • кількості та набору інтерфейсів
  • можливостей резервування (стекування, кластеризація, резервування плат управління (актуально для модульних комутаторів), резервування ел. харчування тощо)
  • функціоналу

  На такому рівні мережі безперечно необхідна як її технічна модифікація:

  • резервування вузлів та зв'язків ядра (дуже-дуже-дуже бажано)
  • резервування вузлів та лінків зв'язків рівня розподілу (залежно від критичності)
  • резервування лінків зв'язку між комутаторами доступу та рівнем розподілу (за потребою)
  • введення протоколів динамічної маршрутизації
  • балансування трафіку як у ядрі так і на рівнях розподілу та доступу (за потреби)
  • впровадження додаткових сервісів як транспортних, так і сервісів безпеки (при необхідності)

  так і юридична, що визначає мережеву безпекову політику підприємства, яка доповнює загальну безпекову політику в частині:

  • вимог щодо впровадження та налаштування тих чи інших функцій безпеки на комутаторах доступу та розподілу
  • вимог доступу, моніторингу та управління обладнанням мережі (протоколи віддаленого доступу, дозволені для управління сегментами мережі, налаштування логування тощо)
  • вимог до резервування
  • вимог до формування мінімально необхідного ЗІП-комплекту

  У цьому розділі я коротко описав еволюцію мережі та підприємства від кількох комутаторів та пари десятків співробітників до кількох десятків (а може бути і сотень комутаторів) та кількох сотень (а то й тисяч) лише тих співробітників, які безпосередньо працюють у мережі підприємства (адже є ще виробничі департаменти та інженерні мережі).
  Зрозуміло, що насправді такого «чудового» та швидкого розвитку підприємства не відбувається.
  Зазвичай минають роки, щоб підприємство та мережа зросла від свого початкового 1 рівня, до 3-го, що описується мною.

  Навіщо я пишу всі ці великі істини? Тому, що хочу тут згадати такий термін як ROI — return-on-investment (повернення/окупність інвестицій) і розглянути ту сторону, яка стосується безпосередньо вибору мережевого обладнання.

  При виборі обладнання, мережеві інженери та їх керівники найчастіше вибирають обладнання виходячи з 2-х факторів - поточної ціни обладнання та мінімального технічного функціоналу, який необхідний на даний момент для вирішення конкретного завдання, або завдань (про закупівлю обладнання для резервування розповім далі).

  При цьому рідко розглядаються можливості подальшого «зростання» обладнання. При виникненні ситуації, коли обладнання себе вичерпає за функціоналом або продуктивністю, то надалі закуповується потужніше і функціональніше, а старе здається на склад, або кудись на мережу за принципом «щоб стояло» (це до речі теж є причиною появи великого зоопарку обладнання та закупівлі купи інформаційних систем, що працюють з ним).

  Таким чином, замість купівлі частини ліцензій на дод. функціонал і продуктивність, які коштують набагато дешевше, ніж нове більш високопродуктивне обладнання, доводиться купувати нову залізницю і переплачувати з наступних причин:

  • мережа часто зростає повільно і розширення функціоналу, або продуктивності комутатора вашої мережі може вистачити ще довгий час
  • не секрет, що обладнання іноземних вендорів прив'язане до закордонної валюти (долар або євро). Якщо бути чесним — зростання долара чи євро (або періодична міні-девальвація рубля, як тут подивитися) призводить до того, що долар 10 років тому і долар зараз це зовсім різні речі з точки зору рубля

  Підсумовуючи все вище сказане, хочу зауважити, що купівля мережного обладнання з ширшим функціоналом зараз може призвести до економії надалі.
  Тут витрати на закупівлю обладнання я розглядаю у контексті інвестування у свою мережу та інфраструктуру.

  Таким чином багато вендоров (не тільки Extreme) дотримуються принципу pay-as-you-grow, закладаючи в обладнання купу функціоналу та можливостей щодо збільшення продуктивності інтерфейсів, які надалі активуються покупкою окремих ліцензій. Також вони пропонують модульні комутатори з широким набором інтерфейсних та процесорних карток та можливістю послідовного нарощування як їх кількості, так і продуктивності.

  Резервування критичних вузлів

  У цій частині статті я хотів би описати основні принципи резервування таких важливих вузлів мережі, як комутатори ядра, ЦОД або розподілу. І почати хочу з розгляду загальних видів резервування — стекування та кластеризації.

  Кожен із методів має свої плюси та мінуси, про які я й хотів би поговорити.

  Нижче представлена ​​загальна зведена таблиця порівняння 2-х методів:

  
  

  • управління - як видно з таблиці, у цьому плані перевага у стекування так як з точки зору керування стек з декількох комутаторів представляється одним комутатором з великою кількістю портів. Замість управління, наприклад, 8-ма різними комутаторами при кластеризації, ви можете керувати тільки одним при стекуванні.
  • відстань — на даний момент, строго кажучи, перевага кластеризації не є такою вже явною, оскільки з'явилися технології стекування комутаторів через порти стекування або порти подвійного призначення (наприклад SummitStack-V Extreme, VSS — Cisco і т.д.), які також залежить від типів трансіверів. Тут перевага віддана кластеризації за принципом того, що при стекуванні існують варіанти, при яких доводиться використовувати звичайні порти стекування, які найчастіше підключаються спеціальними кабелями обмеженої довжини — 0.5, 1, 1.5, 3 або 5 метрів.
  • оновлення ПЗ — тут ми бачимо, що кластеризація має перевагу перед стекуванням і справа в наступному — при оновленні версії ПЗ обладнання при стекуванні ви оновлюєте ПЗ на майстер-комутаторі, який надалі бере на себе роль розміщення нового ПЗ на standby-member комутаторах стеку. З одного боку це полегшує вашу роботу, але оновлення ПЗ часто вимагає апаратного перезавантаження обладнання, що призводить до перезавантаження всього стеку і таким чином до перерви його роботи і всіх зав'язаних на нього сервісів на час = часу перезавантаження. Зазвичай це дуже критично для ядра та ЦОД. При кластеризації - у вас є 2 незалежних один від одного пристрої, на яких ви можете оновлювати програмне забезпечення послідовно один за одним. При цьому перерв у сервісах можна уникнути.
  • конфігурація налаштувань - тут перевага звичайно у стекування, так як у випадку і з керуванням вам необхідно правити налаштування тільки для одного пристрою та конфігураційного файлу. У кластеризації кількість файлів конфігурації дорівнюватиме кількості вузлів кластера.
  • відмовостійкість — тут обидві технології приблизно рівні, але невелика перевага все-таки має кластеризацію. Причина криється в наступному — якщо розглядати стек з точки зору запущених процесів і протоколів, то побачимо наступне:
    • є master-switch, на якому запущені всі основні процеси та протоколи (наприклад, протокол динамічної маршрутизації — OSPF)
    • є інші slave-switch комутатори, на яких запущені основні процеси, необхідні для роботи в стеку та обслуговуванні трафіку, що проходить через них
    • при виході з ладу master-switch комутатора, наступний за пріоритетом slave-switch комутатор виявляє відмову майстра
    • він ініціює себе як майстра і запускає всі процеси, які працювали на майстрі (у тому числі і протокол OSPF, що спостерігається нами)
    • після деякого часу старту процесів (зазвичай досить маленького) починає відпрацьовувати вже сам протокол OSPF
    • таким чином OSPF при відмові одного з вузлів при кластеризації відпрацює трохи швидше ніж при стекуванні (на час, необхідний запуску та ініціалізації процесів та протоколів на slave комутаторі стеку). Хоча повинен зауважити, що сучасні протоколи стекування та комутатори відпрацьовують дуже швидко, найчастіше тривалість перерви по трафіку при перемиканні стеку займає менше однієї секунди, але номінально кластеризація виграє за даним параметром.

  • складність - Як видно з таблиці, у плані складності виграє стекування. Це прямий наслідок пунктів "керування" та "конфігурації налаштувань". Одиночний вузол займає набагато менше часу для налаштувань та керування. Також при кластеризації часто доводиться налаштовувати додаткові протоколи маршрутизації або протоколи резервування шлюзів — VRRP, HSRP та інші.
  • заміна вузлів - Тут однозначна перевага у стекування. Дуже часто для заміни комутатора в стеку необхідно провести мінімально необхідні налаштування обладнання, наприклад:
    • оновити програмне забезпечення нового комутатора до версії програмного забезпечення стека (а це можна робити відразу при вступі комутаторів в ЗІП)
    • налаштувати кілька базових команд для стекування (а для деяких видів комутаторів це навіть не потрібно)
    • витягнути комутатор стека, що вийшов з ладу, і підключити новий
    • підключити електроживлення та патчкорди

  • пружність - я розглядаю для себе як один із основних параметрів. В цілому пружність це комплексна характеристика, яка означає властивість чогось змінюватися під дією навантаження і повертатися до первісного виду після її зникнення. Як не дивно для кластеризації, вона буде вищою навіть з урахуванням рахунку 4:3 за характеристиками на користь стекування. Вся справа у людському факторі. Так-так, не дивуйтеся - в силі таких параметрах стекування, як єдине управління, конфігурація налаштувань і полегшена складність і криється слабкість стекування, коли входить людський фактор.

  За свою роботу в галузі IT я багато разів зустрічав ситуації (та чого вже гріха таїти і сам наступав на ці ж граблі, особливо на початку), коли при налаштуванні стеку інженер помилявся у введенні тієї чи іншої команди або включенням/відключенням того чи іншого функціоналу на устаткуванні, що призводило до відмови всього стеку та його ручки. Окремо варто згадати любителів програми Putty для Windows (Ох це копіювання правою кнопкою миші).

  Насправді обидві технології досить хороші (особливо порівняно з відсутністю резервування) і кожна має свої сильні й слабкі сторони, але для рівня ядра і для високонавантаженого ЦОД я хотів би все-таки використовувати кластеризацію.

  Хоча це лише моя думка. Багато професійних інженерів, які вже багато років на професійному рівні займаються підтримкою мережі, можуть однаково користуватися обома технологіями — тут все залежить від досвіду та кваліфікації.

  Крім технологій стекування та резервування вузлів мережі, існують також загальні принципи резервування частин самого вузла мережі та зв'язків між вузлами:

  Під резервуванням усередині вузла мережі я розумію:

  • резервування блоків живлення - установка 2-х блоків живлення, що дублюють один одного (та ще бажано підключена до 1-ї категорії електроживлення) може значно полегшити вам життя.
  • резервування плат управління — переважно відноситься до модульних комутаторів, які мають підключення кількох дублюючих одне одного плат управління.
  • резервування інтерфейсних карт - також відноситься здебільшого до модульних комутаторів.

  Під резервуванням зв'язків/лінків розуміється переважно наявність дублюючих один одного кабельних трас (або радіолінків у разі відкритих просторів) з:

  • розподілом по різних кабельних шахтах і каналах усередині будівлі
  • географічним розподілом територією на рівні 2-х і більше будівель, міста, області або країни (так звані об'ємні кільця)

  При цьому при побудові резервних лінків зв'язку необхідно дотримуватись ряду рекомендацій для обладнання:

  • у разі дублювання інтерфейсних карток модульного комутатора, або за наявності стека, необхідно розподіляти лінки між юнітами — інтерфейсними картками у разі модульних комутаторів та комутаторами у разі стеку.
  • бажано використовувати протоколи агрегування зв'язку (LACP, MLT, PAgP тощо) для об'єднання лінків у групи та балансування навантаження між ними.
  • використовувати маршрутизатори, що підтримують протоколи ECMP (Equal-Cost-Multi-Path) — коли при доставці кількох пакетів по одному маршруту ці пакети йдуть не через один best path (та інтерфейс), а розподіляються за декількома best-path (і декількома інтерфейсами), які визначаються по рівності метрик протоколу маршрутизації, що у свою чергу відповідає за наповнення підсумкової таблиці маршрутизації.

  А тепер, як і обіцяв, опишу реальний випадок із моєї практики та принцип економії при резервуванні критичних вузлів, який стався кілька років тому:

  • в одній компанії, назву її X, була стандартна 3-х рівнева модель мережі:
    • з кількома ядрами
    • кількома десятками агрегацій
    • кількома тисячами комутаторів доступу
    • кількома десятками тисяч користувачів

  • мережа була досить складно збудована:
    • з купою динамічних протоколів маршрутизації та протоколів - OSPF, MP-BGP, MPLS, PIM, IGMP, IPv6 і т.д.
    • купою сервісів - доступ в інтернет, L2 і L3 VPN, VoIP, IPTV, виділених ліній і т.д.

  • але було одне вузьке місце в мережі - граничний маршрутизатор, який поєднував у собі функції BGP-бордера і термінував деякі сервіси користувача
  • так, він коштував як крило літака (кілька мільйонів рублів)
  • так, на той момент він був одним з топових пристроїв у лінійки у найвідомішого мережевого вендора
  • так, він повинен був бути дуже надійним - з відмінним показником MTBF
  • так, у нього було 4 блоки живлення, зібрані за схемою 2х2 і включені з різних УЕПС і вводів.

  Але все це не скасовував того факту, що він був єдиною точкою відмови мережі.

  І в один, далеко не прекрасний для мене і моїх колег день цей маршрутизатор наказав довго жити (надалі вже з'ясували, що стався якийсь збій на лінії ел. харчування через УЕПС, який привів до виходу одночасно 2-х блоків живлення цьому один із блоків спалив модуль RP маршрутизатора та інтерфейсну карту, які були підключені до загальної шини даних пристрою).

  Резервних плат - RP та інтерфейсної картки у нас не було, але був контракт на заміну обладнання або його комплектуючих з одним із партнерів за схемою NBD.

  На жаль у партнерів на той момент на складі виявилася тільки інтерфейсна картка, але не було плати RP, вона прийшла лише через кілька днів (через 3 дні).

  У результаті наявність єдиної точки відмови у мережі (навіть із наявністю контракту підтримки та заміни обладнання) вилилося у такі фінансові витрати:

  • частка послуг компанії, що припадає або пов'язана з цим бордером, становила близько 60-70%.
  • Як потім було підраховано, денний прибуток становив близько 900 тис. рублів (приблизно) на той момент
  • таким чином за 3 дні простою теоретично було втрачено прибуток у розмірі від 1 млн 620 тис. рублів до 1 млн 890 тис. рублів

  Звичайно чисті втрати були меншими, оскільки компенсації основної частини користувачів були повернуті не у вигляді грошей, а у вигляді послуг, але вони все одно були:

  • частина компенсацій корпоративним користувачам
  • підвищені витрати на співробітників підприємства, які працювали всі ці 3-4 дні у повному складі – переробки, нічні чергування, збільшення змін тощо.
  • репутаційні втрати, що теж не маловажливо
  • і найважливіше — нерви, як керівництва і співробітників, і клієнтів

  У результаті політика компанії було переглянуто:

  • відмовилися від контракту заміни за умовою NBD
  • залишили звичайний сервісний контракт
  • закупили дублюючий маршрутизатор вартістю приблизно 1 - 1.3 млн рублів для резервування 90% основного функціоналу

  Надалі закупівля додаткового обладнання та резервування основного дозволило збалансувати між ними навантаження по зовнішніх лінках, трафіку та користувачам, та забезпечило у подальших аваріях запас міцності для компанії.

  Приклад проектування мережі Enterprise

  У цій частині статті я постараюся викласти основні моменти під час розрахунку опорної мережі підприємства. Я не перевантажуватиму вас всією методикою PPDIOO (Prepare-Planning-Design-Implement-Operate-Optimize), а лише позначу головні її моменти:

  • Prepare/Підготовка — необхідно визначитися зі своїм керівництвом про цілі модернізації мережі, яких ви хочете досягти — підвищити стійкість до відмов, впровадити нові сервіси або технології. Визначення обмежень — технічних та організаційних я тут пропущу, тому що припускаю, що ви є співробітником організації і маєте великий запас часу на їх подолання. До теми бюджету повернусь нижче.
  • Планування/Планування — тут ви повинні побудувати повну характеристику вашої поточної мережі (якщо її ще знаєте), тобто. описати мережу як вона є зараз:
    • кількість та тип обладнання
    • кількість та типи портів
    • існуючі кабельні траси та схеми комутації всередині будівель та між ними
    • схеми електроживлення
    • L2 та L3 адресації
    • побудувати карти мереж Wi-Fi із зазначенням точок доступу та контролерів
    • описати свою серверну ферму
    • бажано описати всі свої сервіси та зв'язки між ними
    • якщо у вас уже впроваджена у тому чи іншому вигляді політика мережної безпеки та розмежування мережного доступу обов'язково врахувати її при проектуванні
    • Одночасно зауважу, що другий крок, по суті, являє собою повну інвентаризацію мережі, починаючи від кабельної інфраструктури та схем електроживлення, і закінчуючи сервісами (додатками та їх портами). Цей крок дуже трудомісткий і навіть часом нудний. Якщо ви чи ваш попередник не вів документації чи навіть елементарної системи моніторингу, то саме час подумати про це. Мережа має тенденцію змінюватися з часом з тією чи іншою швидкістю і лише ведення актуальної документації чи системи моніторингу може допомогти вам встежити за її станом та полегшити її адміністрування. Але це вже стосується кроку operate.

  • Design/Проектування - озброївшись повними знаннями про вашу мережу, отриманими на попередньому кроці, ви нарешті сідаєте і думаєте як модернізувати вашу мережу. Нижче я спробую продемонструвати невеликий приклад розрахунку мережі.

  Для себе я склав невеликий список з вихідними даними, яким я керуватимуся при розрахунку та проектуванні опорної мережі.

  Представимо крок Prepare у вигляді списку того, що у нас є і що планується зробити:

  • є досить велике підприємство з приблизною кількістю робочих місць, близько 700-800 шт (тут я маю на увазі тих співробітників, яким потрібний доступ до мережі підприємства)
  • є кілька окремо-стоящих будівель у межах території підприємства:
  • Основні корпуси:
    • кількість будівель - 2 шт
    • кількість поверхів у будівлі - 7 шт
    • кількість телекомунікаційних шаф на поверсі в одному будинку - 3 (всього 21) шт
    • кількість співробітників у будівлі = ~ 250 осіб

  • Додаткові корпуси:
    • кількість будівель - 10 шт
    • кількість поверхів у будівлі/цеху - 2 шт
    • кількість телекомунікаційних шаф у будівлі - 3 шт
    • кількість співробітників у будівлі = ~ 20 осіб

  • Поточний рівень ядра мережі (до речі дуже поширена схема, яка зустрічалася мені не раз у тому чи іншому вигляді та складі портів) представлений:
    • 2-ма комутаторами L2:
      • 1Gb порти типу RJ-45 - 24 шт
      • 1Gb SFP порти - 4 шт
    • 1-м комутатором L2:
      • 1Gb SFP порти - 24 шт
    • топологія ядра - кільце
    • peer-to-peer лінки між комутаторами включені з використанням оптичних волокон
    • комутатори розташовуються в невеликих серверних кімнатах з шафами
  • Поточний рівень розподілу:
    • поєднаний з рівнем ядра мережі в частині агрегування лінків від комутаторів доступу
    • L3 адресація винесена на граничний маршрутизатор та/або міжмережевий екран
  • Поточний рівень доступу:
    • комутатори L2 з 16 x 100 Mb портами доступу RJ-45 та 2-х гігабітними аплінками combo-портами RJ-45/SFP
    • комутатори розташовуються у шафах на поверхах
    • топологія комутаторів доступу:
      • зірка (hub-and-spoke - маточина і спиці) з комутатором ядра/розподілу в середині
      • промінь/spoke являє собою гілку комутаторів по поверхах - 3 шт в ланцюжку
    • є некеровані комутатори доступу
    • комутатори в 9 додаткових корпусах включені через медіаконвертора (перетворювачі оптичного сигналу на електричний)
  • Поточна кабельна інфраструктура:
    • Кабельна система між будинками:
      • є оптичний кабель між двома основними будинками ємністю 2 волокон
      • є по 1-му оптичному кабелю між одним з додаткових корпусів (де встановлений комутатор ядра) і кожним з основних будов ємністю 8 волокон кожен
      • є по 1-му оптичному кабелю між дод. корпусами та корпусами з встановленими комутаторами ядра ємністю 4 волокна (їх розподіл показано на малюнку нижче)
      • тип волокон у всіх кабелях - одномодовий/SMF
      • використовуються 2-х волоконні одномодові SFP трансівери.
      • частина кабелів термінуються на оптичних кросах (ODF) в окремих приміщеннях (крос-зали/серверні), а частина кабелів у поверхових ШТО

    • Кабельна система всередині будівель:
      • є змішана кабельна структура між серверними кімнатами та першими шафами на поверхах:
      • мідні кабелі Cat5e - 10 шт (або 100 парні кабелі)
      • оптоволоконний багатомодовий/MMF кабель на 4 або 8 волокон - 1 шт.
      • оптоволоконний багатомодовий/MMF кабель на 4 волокна між поверховими шафами
      • мідні кабелі Cat5e між поверховими шафами та розетками доступу
    • поточний ЦОД:
      • є кілька серверів, наприклад, 6 штук
      • включені 1Gb портами в комутатор ядра в 1-му основному будинку
      • всі програми підприємства винесені на сервери
    • адресація L2, L3 та маршрутизація:
      • у мережі є кілька VLAN - 2,3 штуки на будівлю
      • сервери виділені в окрему мережу /24
      • для внутрішніх потреб використовуються сірі мережі класу B, що входять до діапазону — 172.16.0.0/16
      • L3 адреси термінуються на граничному маршрутизаторі та/або на міжмережевому екрані
      • використовується статична маршрутизація
    • додаткова інформація:
      • телефонія:
        • у будівлях та деяких корпусах розгорнуто традиційну телефонію з використанням цифрових АТС старого зразка (не IP-АТС)
        • необхідно телефонізувати нові корпуси, без витрат на протяжку дорогих мідних кабельних ліній певної ємності та побудови дублюючої СКС для телефонії всередині будівель
        • згодом планується впроваджувати IP-телефонію на всій території підприємства, поєднувати її з CRM-системами та перекладати на неї всіх співробітників
      • ємність портів:
        • необхідно проаналізувати поточну ємність магістральних портів та портів доступу, та зарезервувати не менше 25-30% під майбутні потреби
        • проаналізувати достатність поточної пропускної спроможності портів доступу та магістральних лінків
        • передбачити наявність PoE/PoE+ портів доступу для пристроїв із суміжних систем — відеоспостереження та телефонії
      • відеоспостереження:
        • планується використовувати мережу підприємства як транспорт для мережі відеоспостереження
        • необхідно передбачити наявність портів PoE для камер відеоспостереження
      • бездротові системи:
        • надалі планується впровадити бездротову інфраструктуру для мобільності працівників
        • необхідно передбачити наявність PoE портів для точок доступу
      • бюджет, терміни та вимоги до обладнання:
        • використовувати наявне обладнання по максимуму
        • при проектуванні мережі врахувати можливість розширення пропускної спроможності мережі на N років наперед
        • при проектуванні мережі врахувати підтримку різноманітних функцій безпеки - тут список функціонала, починаючи від port-security і закінчуючи автентифікацією та авторизацією користувачів по 802.1х.
        • максимально можливо зарезервувати критичні вузли мережі першорядної важливості – ядро ​​та ЦОД, та передбачити можливість резервування вузлів другорядної важливості – вузлів розподілу
        • бюджет проекту має передбачати послідовне фінансування у кілька етапів
        • сума бюджету - тут уже кожне підприємство визначає для себе, керуючись своїми фінансовими показниками
        • терміни - в ідеальному випадку тут не буде явних термінів, оскільки це внутрішній проект компанії, який реалізується силами своїх співробітників, або вони будуть відносно комфортні - наприклад, 1 рік (і більше). У гіршому випадку — можливо від 3-х місяців до півроку.
      • усунути поточні проблеми в мережі:
        • втрати пакетів
        • проблеми з DHCP на більш-менш інтелектуальних комутаторах доступу, пов'язані з використанням сімейства протоколів STP для боротьби з петлями на портах доступу.
        • позбавитися наявності інтерфейсу DHCP сервера в кожному VLAN співробітників
        • виникнення петель комутації, пов'язаних із самовільним включенням керованих/некерованих комутаторів у кабінетах та підключенням до них усіляких пристроїв
        • список можна продовжувати та продовжувати…

      Крок Planning — характеристика стану вашої поточної мережі, як я вже писав, залежить від наявності якісної системи моніторингу та її документованості. На цьому кроці вам доведеться:

      • як мінімум замалювати існуючу мережу для подальшого аналізу
      • зібрати дані з обладнання:
        • трафік магістральними портами
        • помилки на портах
        • завантаження CPU та витрата пам'яті на комутаторах та маршрутизаторах
        • розписати L2-L3 схеми за VLAN-ами та IP адресами
      • підняти схеми кабельних трас:
        • поволоконні схеми та схеми розпаювання оптичних кросов
        • схеми мідних кабельних розподілів між серверними та поверхами
        • схеми мідних кабельних розподілів між поверхами та кабінетами
        • перевірити наявність оптичних кросів та патч-панелей у серверних та шафах
      • перевірити схеми електроживлення в серверних та поверхових шафах
      • перевірити наявність ДБЖ та АКБ на критичних вузлах
      • проаналізувати усі дані

      Керуючись даними з етапу підготовки, у мене вийшла приблизна логічна схема:

      
      
      Далі, слідуючи модульному підходу, необхідно виділити рівні та модулі підприємства:

      
      
      Кордони (Edge) у цій статті я не торкатимуся, а коротко нагадаю базові тези щодо кожного з модулів Campus:

      • Доступ — на цьому рівні має забезпечувати:
        • необхідна кількість портів для доступу користувачів до мережі
        • виконання політик безпеки — фільтрація трафіку та протоколів
        • стиснення широкомовних доменів та сегментування мережі за допомогою VLAN
        • впровадження окремих VLAN для голосового трафіку
        • підтримку QoS
        • підтримку PoE портів доступу
        • підтримку IP multicast
        • відмовостійкість висхідних лінків зв'язку спільно з рівнем розподілу (бажано)
      • Розподіл — на цьому рівні має забезпечуватись:
        • необхідна кількість портів для підключення комутаторів доступу
        • агрегування та резервування лінків комутаторів доступу
        • IP маршрутизація
        • фільтрація пакетів
        • підтримка QoS
        • відмовостійкість на рівні лінків, обладнання та електроживлення (дуже бажано)
      • Ядро має забезпечувати:
        • високу швидкість комутації та маршрутизації пакетів
        • необхідна кількість портів для підключення комутаторів розподілу
        • підтримку IP маршрутизації та динамічних протоколів маршрутизації зі швидкою збіжністю мережі
        • підтримку QoS
        • функціонал безпеки для захисту доступу до обладнання та сontrol plane
        • відмовостійкість на рівні обладнання та електроживлення (обов'язково)
      • ЦОД — мережевий рівень цього модуля має забезпечувати:
        • високошвидкісні лінки зв'язку
        • необхідна кількість портів для підключення серверів
        • резервування лінків зв'язку як між серверами та комутаторами ЦОД, так і між комутаторами ЦОД та ядром мережі (обов'язково)
        • резервування обладнання та електроживлення (обов'язково)
        • підтримку QoS

      Далі нам потрібно порахувати наші порти та лінки зв'язку та визначити вимоги.
      Рівень доступу – таблиця розрахунку портів

      Отже, ми отримали дані розподілу портів доступу до будівель. Тепер необхідно проаналізувати вимоги до рівня доступу та зауваження та намітити варіанти рішення.
      Рівень доступу - вимоги та варіанти вирішення

      Далі порахуємо порти та лінки зв'язку для наступних рівнів:

      Рівень розподілу

      Рівень ядра

      Рівень ЦОД

      При розрахунку ми отримали таке:

      • рівень доступу — потрібні 24-х та 48-ми портові комутатори доступу, бажано з 1Gb портами доступу та з оптичними uplink портами SFP з підтримкою PoE та широким функціоналом:
        • в сумі вони дадуть 504 порти доступу, що в принципі покриє вимоги spare портів, якщо буде прийнято рішення використовувати 2 порти на робоче місце - IP-телефон та порт даних.
        • можливе використання на кожному поверсі одного 48 портового комутатора з PoE функціоналом, що забезпечує порти доступу для вимог:
          • резерву - приблизно 102 spare порти (22%) на головних будинках. Для додаткових корпусів трохи більше – 25%.
          • відеоспостереження
          • бездротової мережі
      • рівень розподілу — потрібні комутатори з набором портів SFP від ​​12 до 48 портів з наявністю SFP+ портів не менше 2-х штук, з можливістю стекування і розширеним функціоналом, а також наявністю резервних блоків живлення.
      • рівень ядра — потрібні високошвидкісні комутатори від 12 до 24 SFP/SFP+ портів з підтримкою як стекування, так і кластеризації з підтримкою MC-LAG. Слід зазначити, що можливе використання та засобів маршрутизації для балансування трафіку. Останні покоління L3 комутаторів та маршрутизаторів підтримують ECMP з балансуванням трафіку по 4 і більше маршрутах з однаковою метрикою.
      • рівень ЦОД — потрібні комутатори від 8 до 24 SFP/SFP+ портів з підтримкою як стекування, так і кластеризації з підтримкою MC-LAG.

      Цільова схема мережі в результаті вийшла такий

      Вибір комутаторів Extreme для реалізації проекту

      Ну ось ми й підійшли до головного моменту вибору комутаторів для реалізації нашого проекту. Для цільової схеми, що вийшла, підійдуть наступні комутатори Extreme:

      Рівень
      Модель
      порти
      Опис

      ядро
      x620-16x-Base *

      x670-G2-48x-4q-Base*
      16 x 10GE SFP+
       
       
       
      48x10GE SFP+ та 4×40 GE QSFP+
      Для основних потреб ядра:

      • високошвидкісні лінки
      • розширений функціонал маршрутизації та безпеки
      • резервування електроживлення дод. блоками живлення
      • підтримка стекування та кластеризації

      З найменшими вимогами підійде комутатор серії x620.
      У разі розширених вимог до кількості портів та ширшого функціоналу варто розглядати комутатори серії x670-G2.

      ЦОД

      x620-16x-Base*

      x590-24x-1q-2c *

      x670-G2-48x-4q-Base*

      16 x 10GE SFP+
       
       
       
      24x10GE SFP, 1xQSFP+, 2xQSFP28
       
       
      48x10GE SFP+ та 4×40 GE QSFP+

      Для основних потреб ЦОД:

      • високошвидкісні лінки
      • резервування електроживлення дод. блоками живлення
      • підтримка стекування та кластеризації

      З найменшими вимогами підійде комутатор серії x620.
      У разі розширених вимог до кількості портів та ширшого функціоналу варто розглядати комутатори серії x670-G2 та x590-24x-1q-2c.

      розподіл

      X460-G2-24x-10GE4-Base*

      X460-G2-48x-10GE4-Base*

      24×1GE SFP, 8×1000 RJ-45, 4×10GE SFP+
       
       
       
      48x1GE SFP, 4x10GE SFP+

      Для основних потреб розподілу:

      • необхідна кількість оптичних портів
      • резервування електроживлення дод. блоками живлення
      • підтримка стекування та кластеризації
      • необхідний L3 функціонал

      Ідеально підійдуть комутатори серії x460-G2. Наявність резервних блоків живлення з можливістю розширення та додавання портів 10G, CX (для стекування) та QSFP+ робить їх ідеальними комутаторами для рівня розподілу з портами до 1Gb.

      доступ

      X440-G2-24p-10GE4*

      X440-G2-24t-10GE4*

      X440-G2-48t-10GE4*

      X440-G2-48p-10GE4*

      24x1000BASE-T(4 x SFP combo), 4x10GE SFP+ (PoE бюджет 380 Вт)
       
      24x1000BASE-T(4 x SFP combo), 4x10GE SFP+
       
       
      24x1000BASE-T(4 x SFP combo), 4x10GE SFP+ combo ports
       
      48x1000BASE-T(4 x SFP combo), 4x10GE SFP+ combo ports (PoE бюджет 740 Вт)

      Для потреб доступу:

      • необхідна кількість портів доступу
      • підтримка PoE/PoE+
      • функціонал та можливість розширення портів
      • додатковий бонус у вигляді підтримки стекування 10Gb портами «з коробки»

      Рекомендую звернути увагу на цю лінійку у вигляді її гнучкості у частині портів, продуктивності та функціоналу.

      *специфікацію вибраних комутаторів можна переглянути в першій статті циклу - огляд комутаторів Extreme

      На цьому мені можна було б закінчити статтю, але я хотів би висвітлити додатково два аспекти, з якими зіткнеться будь-який інженер при розвитку або модернізації своєї мережі:

      • робота з кабельними трасами — волокнами та мідними лініями
      • IP адресація

      Робота з волокнами

      Вище я навів цільову схему, до якої необхідно прийти. Для її реалізації потрібна наступна кількість зв'язків для обладнання:

      кількість лінків зв'язку

      Як видно з таблиці мінімальна кількість волокон потрібна для забезпечення стійкості до відмови рівнів мережі (модуля ядра, цод і розподілів у 2-х будівель) - 10 штук.

      На етапі характеризації мережі ми з'ясували, що у кабелі між будинками всього 8 волокон. Що ж робити у такій ситуації?

      Я наведу кілька рішень:

      • перший очевидний крок - використовувати вільні волокна в кабелі між будинком 1 - корпусом 1 і корпусом 1 - будинком 2 (як видно з таблиці - використовується тільки 2 з 8 волокон у кожному кабелі). Для цього достатньо поставити оптичні кросування між кросами в корпусі 1 і при необхідності використовувати модулі SFP з запасом оптичного бюджету.
      • другим кроком — можливе використання технології CWDM — ущільнення несучих довжин хвиль у межах одного волокна. Ця технологія набагато дешевша за DWMD і досить проста для реалізації. В основному вимоги пред'являються до якості оптичних волокон та SFP/SFP+ трансіверам певної довжини та бюджету. Як я вже говорив у попередній статті, можливість комутаторів розпізнавати трансівери сторонніх виробників може сильно полегшити нам життя і знизити капітальні витрати на будівництво додаткових оптичних кабелів.
      • Третім кроком слід розглядати можливість збільшення волокон шляхом прокладання додаткових оптичних кабелів.

      Далі ми дивимося на кількість волокон між будинками із встановленими комутаторами розподілу та доп. корпусами 2-10. Тут теж далеко не все так однозначно:

      • по-перше, не вистачає волокон для реалізації нашої цільової схеми - на кожен комутатор по 2 волокна (як ми пам'ятаємо у нас кабелі з 4 ОВ на кожен корпус)
      • по-друге, навіть за наявності достатньої кількості волокон між будинками, усередині корпусів використовуються MMF волокна, які не дозволять нам просто так зстикувати волокна SMF і MMF (я говорю про відстані між будинками понад 300-400 метрів)

      У таких випадках можна розглядати такі варіанти:

      • забезпечення кожного комутатора SMF волокнами:
        • якщо дозволяє відстань - можна протягнути додаткові довгі патчкорди між комутаторами. У свій час ми користувалися патчкордами 30-50 м довжини.
        • прокласти відносно дешевий SMF оптичний кабель малої ємності між шафами
        • на крайній варіант використовувати різні SMF-MMF перетворювачі
      • Для мінімізації використовуваних волокон між будинками можна:
        • використовувати функціонал стекування комутаторів доступу x440-G2 — при цьому використовувати по 1 SMF волокну до кожного комутатора на поверсі, що дозволить замість 6 волокон та портів використовувати 3 волокна та порти на кожній стороні
        • використовувати по 2 волокна для підключення першого комутатора у гілці та останнього. Агрегувати лінки на граничних комутаторах доступу і використовувати протоколи STP в кільці.

      IP-адресація

      Тут я наведу приблизний розрахунок адресації нашої схеми.

      На даний момент у нас є кілька мереж B класу – 172.16.0.0/16. При розрахунку IP адресного простору я керуватимуся такими міркуваннями:

      • 4 біти другого октету позначатимуть будівлі - 172.16.0.0/12.
      • 3 жовтня буде позначати номер поверху в будівлі.
      • 3 октет = 255 буде виділено для point-to-point лінків обладнання та мережі управління.
      • один management VLAN на поверх для управління комутаторами.
      • один власний VLAN на комутатор (в середньому 24 порти).
      • один Voice VLAN на комутатор (в середньому 24 порти).
      • один VLAN для системи відеоспостереження на поверх.
      • один влан для Wi-Fi пристроїв на поверх.

      У мене вийшло приблизно такі таблиці:
      мережа 172.16.0.0/14
      мережа 172.20.0.0/14

      У таблиці вище я навів зразкове рознесення мереж по будинках і поверхах з одного боку і мереж (користувацькі, управління та службові) з іншого.

      Насправді вибір сірої мережі 172.16.0.0/12 є не найоптимальнішим, тому що обмежує нас у кількості мереж (з 16 до 31) для будівель, а є ще й віддалені офіси, яким також необхідно нарізати блоки мереж, можливо більш оптимальним буде варіант з використанням 10.0.0.0/8 мереж, або спільного використання 172.16.0.0/12 мереж (наприклад для службових потреб та серверів) та 10.0.0.0/8 (для мереж користувача).

      В цілому підхід до виділення IP-мереж також є модульним і бажано дотримуватися правил підсумовування підмереж в одну summary-мережу на рівнях розподілу, а також на граничних маршрутизаторах у віддалених філіях. Робиться це з кількох причин:

      • для мінімізації таблиць маршрутизації на роутерах
      • для мінімізації службового трафіку протоколів маршрутизації (усіляких update повідомленнях, при недоступності вкладених підмереж)
      • для спрощення адміністрування та кращої читальності L3 мереж

      Хоча за першими 2-ма пунктами варто зауважити, що потужності сучасних маршрутизаторів набагато вищі, ніж ті, які були 15-20 років тому і дозволяють утримувати у своїй оперативній пам'яті великі таблиці маршрутизації, та й співвідношення ціни та пропускної спроможності каналів зв'язку знизилося порівняно із цінами часів повального використання потоків E1/T1 (G.703).

      Висновок

      Друзі, у цій статті я спробував якомога скоріше розповісти про основні принципи проектування кампусних мереж. Так, матеріалу вийшло досить багато і це при тому, що я не торкався таких тем як:

      • організація кордону підприємства (а це окрема історія зі своїми комутаторами, бордерами, firewall, IPS/IDS системами, DMZ, VPN та іншими штуками)
      • організація Wi-Fi мереж
      • організація VoIP мереж
      • організація ЦОД
      • безпека (а це теж свій окремий світ, який за обсягом та вимогами не поступається проектуванню чистої мережевої інфраструктури, а часом і перевершує її)
      • енергетика
      • список можна продовжувати та продовжувати

      Насправді проектування та побудова мережі підприємства є досить кропітким завданням, що потребує великої кількості часу та ресурсів.

      Але сподіваюся, моя стаття допоможе вам оцінити і на початковому рівні розібратися як підійти до цього завдання.

      Це далеко не остання стаття з Екстремальні мережі, так що слідкуйте за оновленнями (Telegram, Facebook, VK, TS Solution Blog)!

Джерело: habr.com