Відмінності Azure Resource Manager і Microsoft Service Manager — погляд розробника, частина друга, про Networking

Висловлюємо подяку за підготовку статті Михайлу Тряхову (@PerseptronYar з компанії Akvelon (Ярославль) за допомогу в написанні цієї статті. Михайло працює в команді розробників Microsoft Azure CLI (Command Line Interface) зі спеціалізацією на Networking Services.
Вітаю Вас, дорогі читачі!
Продовжимо опис основних засобів розробки Microsoft Azure, розпочатий місяць тому в статті про перші кроки у Microsoft Resource Manager (ARM). Ми встигли поговорити про основні відмінності класичного (Azure Service Management) підходу від нового режиму ARM. Розглянули способи роботи з JSON-шаблони (templates), що дозволяють більш простим чином розгортати і модифікувати архітектуру. При першій же можливості продемонстрували способи налаштування політики безпеки на прикладі трирівневого програми.
Я дуже дякую за фідбек, отриманий нехай і в скромному обсязі, але в конструктивному ключі. Ваші питання наштовхнули мене на необхідність опису процесу створення гібридних рішень — і вже в цій статті ми торкнемося деякі кейси цієї предметної області. Нагадаю, ми розглядали приклад архітектури, схематично зображеною нижче.



Для початку мені хотілося б продовжити роботу з Networking сервісами в ARM. Отже, давайте розглянемо взаємодію між внутрішніми рівнями програми.



Нагадаю, ми вже прописали політику безпеки через Network Security Groups, заборонивши, зокрема, доступ до сервісів баз даних (backend) безпосередньо з інтернету.

{
"name": "Block_Internet",
"properties": {
"description": "Block Internet",
"protocol": ".*",
"sourcePortRange": ".*",
"destinationPortRange": ".*",
"sourceAddressPrefix": ".*",
"destinationAddressPrefix": "Internet",
"access": "Deny",
"priority": 200,
"direction": "Outbound"
}
}

Крім цього, предметна область може вимагати від нас та інших ратних подвигів. Для того, щоб забезпечити коректне взаємодія між рівнями нашого додатка, нам необхідно сконфігурувати routing. Більшість необхідних кейсів чудово покривається надаються за замовчуванням System Routes. Це дозволяє не мучитися налаштуванням зв'язків між віртуальними машинами в рамках virtual network, безвідносно підмереж (subnets), до яких вони відносяться. Системні маршрути, до того ж, забезпечують обмін даних і поза створеної мережі (інтернет, в інші мережі через VPN). Автоматично створюються згідно з таблицею маршрутів (route table). Для того, щоб знизити розмір нашого шаблону, пропоную винести дану задачу в дещо спрощеному вигляді.



Але ми тут не для того, щоб витрачати багато часу на дані за замовчуванням сервіси. Розглянемо менш тривіальні кейси, коли нам не обійтися базової системної маршрутизацією. Для таких цілей може використовуватися User Defined Routing (UDR). З його допомогою ми зможемо створити маршрути, визначені користувачем і реалізувати більш складний кастомный сценарій. Приміром, UDR допоможе використовувати віртуальні пристрої в архітектурі Azure, забезпечити доступ до інтернету через вашу локальну мережу.



Реалізація такого завдання може вирішуватися саме за рахунок User Defined Routes. Іншими випадками, де потрібність UDR очевидна — це налаштування Firewall-a, побудова більш глибокого аналізу переданих по мережі даних. Подібний спосіб побудови маршрутизації може також допомогти в більш корисною кастомізації системи логгирования.

Отже, розглянемо приклад побудови UDR. Ми модифікуємо дефолтний випадок з System Routes і додаємо третю віртуалку, через яку будемо проганяти наш трафік для виконання поставлених завдань.



Пропоную знову виробляти розгортання інфраструктури допомогу JSON-шаблону, який ми вирішили вважати найбільш наочним. Працювати з ним будемо в одному з уже звичних редакторів. Першим ділом ми, природно, запустимо Visual Studio, але для наведеного нами прикладу настільки потужна IDE — достатньо "важке" рішення. В якості альтернативи можна використовувати будь-який редактор, що підтримує роботу з JSON. Одним з відносно нових виходів із ситуації потенційних синтаксичних помилок в JSON є VS Code, доступний, наприклад, бета-версії marketplace.

Його код доступний з цьому посиланню. Думаю, якщо ви заглянете в нього, то його обсяг дасть розуміння, чому я малодушно виніс цей таск з первісної трирівневої схеми. Як і раніше, не лякаємося і продовжуємо. В шаблоні ми створюємо віртуальну мережу і три підмережі: frontend, backend і проміжна між ними Virtual Appliance (subnet3). Frontend підмережа (subnet1) ми, крім NSG, співвідносимо з таблицею маршрутів (route table), яка буде направляти вихідний трафік. Зазначу, що User Defined Routes придатні для конфігурування тільки вихідного трафіку, до того ж маршрутизація повинна відбуватися поза рамкок одній і тій же підмережі.

У кожній підмережі ми розгортаємо віртуальні машини і ставимо їм у відповідність Public IP адреси, конфігуруємо network security groups, додаючи до дефолтних правилами своє, дозволяючи доступ по RDP. Ну і на десерт – додаємо згадувану вище route table, в якій прописуємо правило, відбиває пункт призначення нашого маршруту (destination route).

{
"type": "Microsoft.Network/routeTables",
"name": "[variables('routeTableName')]",
"apiVersion": "2015-05-01-preview",
"location": "[parameters('location')]",
"properties": {
"routes": [
{
"name": "VirtualApplianceRouteToSubnet3",
"properties": {
"addressPrefix": "[parameters('subnet3Prefix')]",
"nextHopType": "VirtualAppliance",
"nextHopIpAddress": "[variables('NvmPrivateIPAddress')]"
}
}
]
}
}

Я прошу звернути увагу на важливий момент – ми вказуємо тип і адреса наступного одержувача нашого трафіку. У нашому випадку ми вказуємо, що якщо трафік прийшов у Subnet 3 (Virtual Appliance), то ми перенаправляємо його на наступний (приватний) IP-адресу.
Додатковий крок, який потрібно, це встановити необхідний зв'язок між фінальної Backend підмережею, її приватним IP-адресою і нашою таблицею маршрутів. Для цього ми створюємо Network Interfaces (NIC) для кожної підмережі. Якщо для Frontend підмережі всі безробітні і малоцікаво, то в конфігурації Backend-a все не так просто. У ній ми вказуємо зв'язок публічного і приватного IP-адрес, а також допускаємо пересилання IP. Отримали жаданий маршрутизатор.

"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Static",
"privateIPAddress": "[variables('NvmPrivateIPAddress')]",
"publicIPAddress": {
"id": "[resourceId('Microsoft.Network/publicIPAddresses', parameters('PublicIPNameForVM2'))]"
},
"subnet": {
"id": "[variables('subnet2Ref')]"
}
}
}
],
"enableIPForwarding": true
}

Інші особливості конфігурації (Network interfaces та інше), знову ж таки, переконливо прошу відстежити в доступному шаблоне. Там же вносимо всі необхідні параметри для створення віртуальних машин, вказавши їх Network Interfaces. Бачимо також очевидні в контексті описаного вище налаштування віртуальних машин на ОС Windows.

Отже, розгорнувши бажану інфраструктуру, ми можемо потестувати, що ж у підсумку вийшло. Наприклад, можемо відстежити, що Virtual Appliance (VM3) має вільний доступ до Backend-рівня (VM2). Звернувшись з першої виртуаки (Frontend Layer, VM1), ми можемо відстежити як відбувається очікуваний редирект.



Сподіваюся, це вже не настільки простий кейс додав вам деякого розуміння методи створення User Defined Routing рішень. І вже якщо ця стаття і не підштовхне Вас до негайних експериментів, то вже точно опиниться в закладках на швидке майбутнє.

Не можна не сказати пару слів про використання Express Routes, базовим кейсом для використання яких є потреба у підключенні сервісів мережі до Azure та інших хмарних сервісів Microsoft (Office 365, CRM Online). Існуюча інфраструктура може розташовуватися у вашому дата-центрі (on-premises), або розміщене в різних місцях. Що важливо — встановлене з'єднання при цьому ізольовано від загального інтернет-з'єднання, а буде проводитися по виділеному каналу (Express route circuit). Виключено з'єднання не тільки з іншими інтернет-ресурсами, але навіть з сервісами Microsoft Azure (Storage, SQL database). Динамічна маршрутизація буде проходити за стандартними протоколами (BGP). Існує кілька способів підключення локальної мережі до хмарних сервісів Microsoft.



У разі Cloud Exchange co-location, підключення проводиться через Ethernet Exchange постачальника спільного розміщення. Даний спосіб підключення дозволить, наприклад, забезпечити віртуальне крос-з'єднання з Azure.

Підключення типу point-to-point забезпечує Ethernet мережу між локальним дата-центром вашої компанії і Azure. Доступ як і раніше здійснюється по виділених каналах і доступ через публічний інтернет виключена.

Мережі типу any to any дозволяють здійснити інтеграцію з хмарою Azure глобальної обчислювальної мережі WAN (наприклад, кампус великого університету, офіс, практикуючий віддалену роботу). Виробляється це за допомогою VPN-мережі на основі MPLS. У контексті Azure це називається IPVPN, що дозволяє в рамках WAN сприймати Azure як ще один кампус або віддалений офіс.

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

Під кінець хочу сказати пару слів, як описані вище способи здійснення підключень взаємодіють один з одним. Коли ми явно не вказуємо route table для підмережі (subnet), за замовчуванням використовуються System Routes. Якщо ж таблиця вказана і зв'язок встановлено, routing проводиться за збігом найбільш довгого префікса (LPM) серед UDR і System Routes. При наявності декількох маршрутів з співпадаючими значеннями LPM, маршрут вибирається по джерелу в наступному порядку:
  • UDR
  • маршрут BGP (якщо використовується ExpressRoute);
  • Системні маршрути

    Сподіваюся, ця стаття додала розуміння в питаннях маршрутизації засобами Microsoft Azure у новому Microsoft Resource Manager. Попереду — балансування навантаження і гібридні рішення ARM, ASM, on-premises. Як і раніше, дуже чекаю Ваших питань і побажань. Спасибі за увагу!


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.