Привіт всім!
Мене останнім часом багато запитують про мережевий взаємодії в Azure і про те, як можна отримати статичні адреси на віртуальні машини. Відповідь по суті своїй простий, але я хочу написати окрему статтю на цю тему. У поточній статті я спробую дати трохи більш глибоке розуміння IP адрес для віртуальних машин і хмарних сервісів. Ще раз хочу звернути увагу, все що я буду зараз говорити, а точніше описувати, буде працювати абсолютно однаково як для віртуальних машин, так і для хмарних сервісів (веб / Воркер ролей), але налаштовувати це потрібно по різному. Для простоти написання статті я буду приводити все приклади настройки IP адрес тільки для віртуальних машин. Якщо буде необхідність показати приклади для хмарних сервісів (веб / Воркер ролей), то пишіть про це в коментарях і я це зроблю.
Azure і IP адреси - пролог.
Почнемо ми з вами з того, що ще раз подивимося з чого складаються наші віртуальні машини і хмарні сервіси.
Найважливіше в цій схемі те, що кожна віртуальна машина або екземпляр хмарного сервісу мають рівно одну мережеву карту. Це правило працює абсолютно для всіх варіантів використання різних IP адрес (принаймні це було так на момент написання статті). Отже, ваша машина завжди бачить тільки одну мережеву карту і у неї завжди сірий IP адреса. Але, насправді, підключитися до машини можна будь-яким з трьох можливих способів - через внутрішній IP адреса, через зовнішній виділений IP адреса, через IP адреса балансувальника навантаження. Вся ця неймовірна магія стає нам доступна завдяки різним способам мережевий комутації (хоч дана стаття і не зовсім про це).
Почнемо з простого - внутрішній IP.
Це і правда найпростіший для розуміння IP адреса. У різних документах його можуть називати по різному (Internal IP, Static IP, ...), але його суть від цього не змінюється. Це той IP адреса, який висить на внутрішньому інтерфейсі і який можна побачити явно в налаштуваннях мережевої карти нашої машини. Цей IP адреса завжди видається з сірого діапазону і використовувати його можна тільки для комунікації всередині одного хмарного сервісу (якщо ви не використовуєте віртуальну мережу) або всередині віртуальної мережі (якщо така використовується). Також, додатковою перевагою використання віртуальної мережі є те, що ви можете керувати тим, які саме адреси буде отримувати кожна машина, іншими словами - ви можете впливати на DHCP сервер.
Ось так це можна зробити за допомогою PowerShell
Get-AzureVM -ServiceName StaticDemo -Name VM2 `
| Set-AzureStaticVNetIP -IPAddress 192.168.4.7 `
| Update-AzureVM
Таким чином ми можемо розміщувати в хмарі ресурси, які вимагають внутрішньої статичної адресації, наприклад DNS сервера і / або інші подібні їм сервіси.
Також звична річ - віртуальний IP балансувальника навантаження.
Ця штука трохи складніше, але вона вже могла стати звичною для користувачів Azure. Всім добре відомо, що навіть за умови одиничного примірника, будь-яка віртуальна машина стоїть за балансувальник навантаження. Просто змиріться з цим фактом. У нашого балансувальника теж є свій IP адреса і він видається з білого діапазону. Цей IP адреса на балансувальник завжди один і всі машини, які стоять за ним, завжди виходять в мережу під цим IP адресою. Але балансувальник підступний і при роботі з ним треба завжди пам'ятати про наступні аспекти:
1. Балансувальник завжди працює в режимі NAT і вміє відкривати вхідні порти за двома принципами роботи:
* Прямий кидок.
У цьому режимі ми вибираємо зовнішній порт, внутрішній порт і внутрішній IP адреса. Всі запити на вказаний зовнішній порт балансувальника будуть перенаправлені на внутрішній порт однієї машини. Це зручно використовувати для того, щоб відкрити доступ на кожну машину по RDP протоколу.
* Балансування.
У цьому режимі ми обираємо зовнішній порт і внутрішній порт, після чого створюється правило (або скоріше шлюз) балансування. Після створення шлюзу балансування до нього подлкючаются віртуальні машини. Цей режим зручно використовувати для балансування навантаження між IIS серверами, які обслуговують наші сайти. Тут також потрібно відзначити одну важливу деталь - нас ніхто не змушує включати всі машини з хмарного сервісу в це правило балансування. Припустимо у мене є 2 машини, на яких стоїть IIS і ще 2 машини для SQL сервера. Я можу спокійно прокинути порт 80 тільки на перші дві машини. Також потрібно додати, що можна сміливо створювати подібні правила для однієї машини. З першого погляду це дуже схоже на варіант прямого проброса, але це дає нам шанс в майбутньому додати ще сервер в ферму і масштабироваться горизонтально.
2. Балансувальник може створити не більше ніж 150 правил, іншими словами - він не може відкрити більше 150 зовнішніх портів одночасно. Це робить, наприклад, створення FTP сервера досить важко здійснюваною завданням.
3. Балансувальник завжди зберігає своє доменне ім'я, АЛЕ він далеко не завжди зберігає свій IP адреса. Це мабуть самий підлий фортель, який вам може підкинути балансувальник і про нього дуже важливо знати.
Зовнішній IP адреса балансувальника буде змінений, якщо ми вимкнули, видалили або перезавантажили наші віртуальні машини з порталу. Аналогічно адреса бдет змінен якщо ми викотили нову версію облачниого сервісу шляхом застарілими, а заміни старої. Це може бути болючим досвідом, особливо якщо ви інтегруєте з системою, яка вимагає надати IP адреса для додавання його в список дозволених на файервол. Що є звичайною практикою для фінансових організацій.
Щоб такого не сталося ви можете використовувати зарезервований IP адреса. В такому випадку запитаний вами IP адреса закріплюється за вашої підпискою і вже нікуди від вас не втече.
Ось так це можна зробити за допомогою PowerShell
# Спершу резервуємо собі IP адреса
New-AzureReservedIP -ReservedIPName "MyReservedIP" -Label "ReservedIPLabel" -Location "East US"
# Але його можна використовувати тільки при створенні нового хмарного сервісу
New-AzureVMConfig -Name "CloudServer1" -InstanceSize "Small" -ImageName "Name_of_image" `
| Add-AzureProvisioningConfig -Windows -AdminUsername "cloudadmin" -Password "ABC123" `
| New-AzureVM -ServiceName "MyCloudServers" -ReservedIPName "MyReservedIP" -Location "East US"
Тут також варто відзначити важливу деталь - ви не можете сказати «хочу щоб цей IP адреса став зарезервованим», так як тимчасові і постійні адреси для балансувальника йдуть з різних діапазонів. Таким чином, як тільки ви приймаєте рішення змінити ваш IP адреса на зарезервований, або навпаки - відмовити від нього, - ви повинні розуміти що це обов'язково призведе до зміни поточного IP адреси вашого балансувальника.
І на закуску - виділений публічний IP.
Ця штука з'явилася однією з останніх, але це не означає що вона сама малозначима. Цей IP адреса завжди видається на одну віртуальну машину і завжди менят при виключенні або перезавантаження машини з порталу.
При роботі з балансувальник у нас завжди є обмеження на одночасне використання до 150 вхідних портів. І це зараз, а раніше їх було всього 25. Як я вже говорив, це змушує нас дуже сильно страждати при спробі конфігурувати FTP сервер або щось схоже. Але тут в гру вступає виділений публічний IP адреса, який завжди відмінний від адреси балансувальника і завжди ходить в обхід всіх його правил. Весь вихідний трафік для віртуальної машини буде проходити через виділений публічний IP адреса (якщо такий є). Також на виділеному публічному IP адресу немає обмеження за кількістю відкритих портів, що важливо для конфігурації нашого FTP сервера.
Для того, щоб запросити виділений публічний IP адреса за допомогою PowerShell, потрібно виконати
# Резервуємо виділений публічний IP адреса
Get-AzureVM -ServiceName FTPInAzure -Name FTPInstance `
| Set-AzurePublicIP -PublicIPName ftpip `
| Update-AzureVM
# Але його не можна побачити з порталу, так що будемо дивитися тут
Get-AzureRole -ServiceName FTPInAzure -Slot Production -InstanceDetails
На цьому все, сподіваюся я зміг пролити трохи більше світла на те, які IP адреси є в Azure, а також як і для чого ми можемо їх використовувати.
