Amazon OpenSearch Serverless – це повністю керована служба пошуку та аналітики, яка автоматично забезпечує інфраструктуру та масштаби інфраструктури, щоб допомогти вам запустити робочі навантаження на пошук та аналітику без управління кластерами. За допомогою OpenSearch Serverless ви можете швидко створити можливості пошуку та аналітики у свої програми.
Оскільки організації масштабують їх використання без серверів OpenSearch, розуміння архітектури мережі та управління DNS стає все більш важливим. Спираючись на шаблони підключення, обговорені в наших попередніх шаблонах підключення до мережі для Amazon OpenSearch Serverless, ця публікація охоплює розширені сценарії розгортання, орієнтовані на централізовані та розподілені шаблони доступу-конкретно, як підприємства можуть спростити мережеві підключення до декількох облікових записів AWS та розширити доступ до середовища у виробництві для їхніх бездоганних розгортання.
Ми окреслюємо дві ключові схеми розгортання:
- Візерунок 1 – Централізована модель кінцевої точки, де інтерфейс Virtual Private Cloud (VPC) Кінцеві точки для OpenSearch Server без сервера розгорнуті в спільних службах VPC, що дозволяє говорити VPC з інших облікових записів AWS та в приміщеннях для доступу до колекцій без Server Server через ці консолідовані кінцеві точки.
- Візерунок 2 -Розподілена модель кінцевої точки, де інтерфейс VPC кінцевих точок створюється в окремих VPC, що розмовляють, з кількома споживачами (центральний рахунок, локальні мережі та інші рахунки, що розмовляють), які отримують доступ до цих кінцевих точок через централізоване управління DNS. Цей підхід забезпечує пряме зв’язок у кожному розмові VPC, зберігаючи централізований контроль та управління DNS у всій організації.
Перш ніж зануритися в розширені шаблони розгортання, давайте переглянемо поведінку DNS OpenSearch Server без доступу через інтерфейс VPC Endpoint (AWS PrivateLink). Розуміння цього основоположного аспекту може допомогти уточнити моделі зв’язку, які ми досліджуємо в цій публікації.
Роздільна здатність DNS DNS без сервера без сервера
Під час створення інтерфейсу без сервера OpenSearch без сервера VPC, послуга автоматично забезпечує три приватні розміщені зони: одна видима приватна зона розміщення us-east-1.aoss.amazonaws.com
Це обробляє роздільну здатність домену для колекції та приладної панелі без серверів OpenSearch, ще одна видима приватна зона розміщення us-east-1.opensearch.amazonaws.com
Це керує роздільною здатністю для інтерфейсу OpenSearch (інформаційні панелі OpenSearch) та одна прихована внутрішня приватна зона, яка керує остаточною роздільною здатністю DNS на приватні IP -адреси.
Наша мета в цій публікації – вивчити, як дві приватні зони розміщення для OpenSearch без сервера працюють разом: видима приватна зона розміщення us-east-1.aoss.amazonaws.com
Для колекцій та інформаційних панелей та прихованої приватної розміщення зони для остаточного вирішення DNS до приватних IP -адрес. Ми вивчаємо, як ці приватні зонів, що розміщуються, дозволяють масштабовану роздільну здатність DNS як в централізованих, так і в розподілених архітектурах. Наступна схема робочого процесу показує потік роздільної здатності DNS для us-east-1
Регіон AWS. Така ж модель стосується інших регіонів, при цьому регіонні ідентифікатори в записах DNS змінюються відповідно.
Робочий процес складається з наступних кроків:
- Користувач запитує доступ до URL -адреси колекції (наприклад,
abc.us-east-1.aoss.amazonaws.com
.). - Запит DNS надсилається на Resolver Amazon Route 53, який перевіряє видимій приватній зоні розміщення
us-east-1.aoss.amazonaws.com
і знаходить запис CNAME, що вказує на домен, що стосується кінцевої точки. - Route 53 Resolver використовує приховану внутрішню приватну зону, що розміщується для вирішення цього домену, що стосується кінцевої точки, до приватної IP-адреси VPC Endpoint.
- Трафік дозволений лише в тому випадку, якщо він походить від кінцевої точки VPC інтерфейсу, затвердженої мережевими політиками без серверів.
Хоча цей процес роздільної здатності DNS забезпечує гнучкий та безпечний приватний доступ, він стає складним, коли вам потрібна підключення від декількох VPC, різних облікових записів AWS або локальних мереж. Наступні закономірності стосуються цих викликів та окреслення стратегій для спрощення доступу до мережі та управління DNS для OpenSearch Server Wless у таких середовищах.
Шаблон 1: Централізований інтерфейс VPC Endpoint для OpenSearch Serverless
Ця схема використовує централізований підхід, де акаунт AWS спільного сервісу з спільними службами VPC розміщує інтерфейс VPC Endpoint VPC та колекцію без серверів OpenSearch без сервера. Звідти інші облікові записи AWS з Amazon VPC (Spoke VPC) повинні мати можливість отримати доступ до колекцій без серверів OpenSearch через цю центральну кінцеву точку. Організації зазвичай впроваджують цю установку в дизайні мережі Hub-Spoke, які з'єднують їх VPC, використовуючи або AWS Transit Gateway, або AWS Cloud Wan. Наступна схема ілюструє цю архітектуру.
Оскаржувати
Під час доступу до локальних мереж, як мережевий доступ, так і роздільна здатність DNS для інтерфейсу без сервера OpenSearch без сервера, що працює в успішному режимі VPC. Однак, хоча кінцева точка доступна в мережі від VPC, що розмовляють (наприклад, через транзитний шлюз або AWS Cloud Wan), роздільна здатність DNS з цих VPC не вдається.
Це трапляється тому us-east-1.aoss.amazonaws.com
Це пов'язано лише з VPC, що містить кінцеву точку, в цьому випадку спільні послуги VPC. Просто ділитися цією приватною розміщеною зоною з VPC Spoke VPC не вирішує проблему, тому privatelink.c0X.sgw.iad.prod.aoss.searchservices.aws.dev
. Цю назву DNS не можна вирішити з інших VPC без додаткової конфігурації, оскільки воно належить до приватної розміщеної зони privatelink.c0X.sgw.iad.prod.aoss.searchservices.aws.dev
Це пов'язано лише з спільними послугами VPC. Ця приватна розміщена зона не видно у вашому обліковому записі і контролюється AWS.
Рішення: Використовуйте профілі Amazon Route 53 для роздільної здатності DNS Cross-VPC
Щоб увімкнути централізовану роздільну здатність DNS, ви можете використовувати профілі Amazon Route 53. За допомогою профілів Route 53 ви можете керувати та застосовувати конфігурації Amazon Route 53, пов'язані з DNS, у декількох облікових записах VPC та AWS. Наступна схема ілюструє архітектуру рішення.
Рішення складається з наступних кроків:
- Створіть кінцеву точку VPC без сервера OpenSearch без серверів у спільних службах VPC. Це автоматично створює та асоціює наступне:
-
- Дві приватні зони за замовчуванням.
- Одна прихована приватна зона, що розміщується з цим VPC.
-
- Створіть профіль маршруту 53 в обліковому записі спільних служб.
- Асофігуруйте інтерфейс VPC Endpoint для OpenSearch Server без профілю Route 53.
- Профіль Route 53 автоматично асоціює приховану приватну зону розміщення з профілем.
- Асоціюйте приватну приймальну зону
us-east-1.aoss.amazonaws.com
Це було автоматично створено OpenSearch Server без профілю Route 53. - Поділіться профілем маршруту 53 з іншими обліковими записами AWS у вашій організації за допомогою Manager Access Access Access Access (AWS RAM).
- Об'єднайте VPC, що розмовляють (розташовані в різних облікових записах) з профілем маршруту 53.
Якщо у вас є існуючий профіль маршруту 53 у вашому обліковому записі спільних служб, який вже пов'язаний з розмовою VPC, ви можете просто пов’язати кінцеву точку VPC без серверів OpenSearch та приватну зону розміщення us-east-1.aoss.amazonaws.com
до цього профілю.
Після завершення цих кроків роздільна здатність DNS для колекції без серверів OpenSearch та кінцеві точки приладної панелі безперешкодно працює з VPC, пов'язаних з профілем маршруту 53. Клієнти, що розмовляють VPC, можуть вирішити та отримувати доступ до колекцій без серверів OpenSearch без серверів через централізовану кінцеву точку VPC.
Шаблон 2: Розширений інтерфейс VPC Endpoint для OpenSearch Serverless
Кожен розмовляв VPC, що проживає у відповідному обліковому записі AWS, розміщує власну колекцію без серверів OpenSearch та інтерфейс VPC Endpoint. Тепер ми хочемо досягти наступного:
- Централізуйте управління DNS у спільних послугах VPC для надання послідовної роздільної здатності для колекцій без серверів OpenSearch, розгорнутого в декількох облікових записах
- Забезпечте локальні ресурси з можливістю роздільної здатності DNS для всіх колекцій без серверів OpenSearch по всій організації через вхідну точку Route 53 Resolver у спільних послугах VPC
Наступна схема ілюструє цю архітектуру.
Оскаржувати
Управління роздільною здатністю DNS для колекцій без серверів OpenSearch та інформаційних панелей стає складним у цій розподіленій моделі, оскільки кожна кінцева точка VPC інтерфейсу створює власний набір приватних розміщених зон, які пов'язані лише з відповідними VPC. Це створює роздроблений ландшафт DNS, де спільні послуги VPC та локальні мережі потребують консолідованого способу для вирішення доменів колекцій без серверів OpenSearch та інформаційних панелей на кількох облікових записах.
Рішення: Використовуйте самостійно керовану зону приватного розміщення у спільних послугах VPC для RE-PREM DNS
Щоб увімкнути централізовану роздільну здатність DNS для розподілених кінцевих точок, створіть самостійно керовану приватну зону розміщення в обліковому записі спільних послуг та пов’язати її з VPC спільними послугами. У цій приватній зоні розміщення ви можете створити записи CNAME, які відображають кожну кінцеву точку колекції без серверів OpenSearch на відповідний інтерфейс VPC Endpoint DNS в облікових записах. Наступна схема ілюструє цю архітектуру.
Реалізація складається з наступних кроків:
- Створіть самостійно керовану приватну зону розміщення в обліковому записі спільних послуг із доменним іменем
us-east-1.aoss.amazonaws.com
і пов'язуйте його з спільними послугами VPC. Для кожної колекції без серверів OpenSearch створіть запис CNAME, який вказує на регіональну назву DNS відповідної кінцевої точки VPC інтерфейсу.
Ця конфігурація дозволяє як локальні ресурси, так і ресурси в спільних сервісах VPC для вирішення кінцевих точок без серверів OpenSearch, які знаходяться в облікових записах.
Після завершення цих кроків кожен інтерфейс VPC без сервера OpenSearch залишається в межах свого початкового облікового запису AWS, підтримуючи межі безпеки та автономію на рівні облікових записів. Локальні системи можуть отримати доступ до колекцій без серверів OpenSearch без серверів, використовуючи оригінальні імена колекції DNS (наприклад, {collection-name}.us-east-1.aoss.amazonaws.com
) через резолюцію DNS, що надається приватною розміщеною зоною у спільних послугах VPC.
Висновок
Оскільки організації масштабують своє прийняття без серверів OpenSearch, встановлення безпечного та централізованого доступу до мережі стає все більш важливим. У цій публікації ми дослідили дві архітектурні зразки, спеціально навколо управління DNS:
- Централізована модель кінцевої точки – Ця шаблон ідеально підходить, коли акаунт спільних служб керує інтерфейсом без серверів OpenSearch без серверів VPC, що дозволяє декілька облікових записів для доступу до OpenSearch без серверів та інформаційних панелей через централізований набір мережевих ресурсів.
- Розподілена модель кінцевої точки з централізованою DNS – Ця закономірність підходить для організацій, які потребують самостійності на рівні облікових записів, де кожен обліковий запис AWS управляє власним інтерфейсом без серверів OpenSearch без серверів VPC, тоді як DNS-роздільна здатність централізується за допомогою спільної приватної зони, що займається приватним розміщенням у акаунті спільних послуг.
Розуміючи архітектуру DNS OpenSearch Server без серверів та використовуючи такі послуги, як маршрут 53 профілі та оперативна пам’ять AWS, організації можуть створити безпечні та надійні схеми доступу, які відповідають їх організаційній структурі та потребам.
Про авторів
Анкуш Гоял – це підтримка підприємства в підтримці AWS Enterprise, яка допомагає клієнтам впорядкувати свої хмарні операції на AWS. Він є професіоналом, орієнтованим на результати, який має понад 20 років досвіду.
Anvesh Koganti є архітектором Solutions в AWS, що спеціалізується на мережах. Він зосереджується на тому, щоб допомогти клієнтам будувати мережеві архітектури для широко масштабованих та стійких середовищ AWS. Поза межами роботи Anvesh захоплюється технологіями споживачів і любить слухати подкасти на технологіях та бізнесі. Відключуючись від цифрового світу, Anvesh проводить час на свіжому повітрі та на велосипеді.
Салман Ахмед є старшим менеджером технічного облікового запису в підтримці AWS Enterprise. Він спеціалізується на керівництві клієнтів за допомогою дизайну, впровадження та підтримки AWS Solutions. Поєднуючи свою мережеву експертизу з прагненням досліджувати нові технології, він допомагає організаціям успішно орієнтуватися на свою хмарну подорож. Поза межами роботи він насолоджується фотографією, подорожуючи та спостерігаючи за своїми улюбленими спортивними командами.