облако sql для нескольких регионов - PullRequest
Новая
       69

облако sql для нескольких регионов

0 голосов
/ 22 января 2020

Я создаю настройку облака Google с несколькими группами экземпляров (3) в нескольких регионах. Все они находятся в одном VP C.

Регионы:

  • us-central1
  • европа-север1
  • азия-восток1

Все три группы экземпляров имеют 2 виртуальные машины. Он работает как балансировщик нагрузки HTTP (S), и когда я захожу на publi c IP-адрес балансировщика нагрузки, я вижу страницу приветствия apache (apache установлена ​​на виртуальных машинах). Так что это работает.

У меня также есть база данных Cloud SQL (PostgreSQL). Я хочу получить доступ к этой базе данных через ее частный IP. Я связал сеть VP C, которую используют виртуальные машины, с частным IP-адресом экземпляра Cloud SQL. Этот экземпляр работает в регионе us-central1.

Теперь проблема в том, что он не работает. :) Я провел некоторые исследования в документации и обнаружил следующее:

Вы должны выбрать сеть VP C для использования. Ресурсы Google Cloud, которые вы будете использовать для подключения к своему экземпляру Cloud SQL (экземплярам Compute Engine [VM] или экземплярам Google Kubernetes Engine), должны использовать эту сеть VP C для подключения. Эти ресурсы также должны находиться в том же регионе, что и ваш экземпляр Cloud SQL.

Источник: https://cloud.google.com/sql/docs/postgres/configure-private-ip

Кому тест, я добавляю новую виртуальную машину в регионе us-central1 (не связан с группой экземпляров) и с правильным VP C. Когда я устанавливаю postgresql -клиента на этой виртуальной машине, я могу подключиться к базе данных. Но когда я создаю другую виртуальную машину в регионе europe-north1 (также не связанной с группой экземпляров) и с правильным VP C, я не могу подключиться к базе данных. Таким образом, документация (неожиданно) верна: экземпляры в другом регионе, отличном от региона, в котором работает экземпляр Cloud SQL, не могут подключиться к Cloud SQL через частный IP-адрес.

Мой вопрос сейчас является: каков наилучший способ решить эту проблему, чтобы все виртуальные машины в разных группах экземпляров могли подключаться к одной и той же базе данных. Должен ли я создать несколько экземпляров Cloud SQL в разных регионах и копировать каждую базу данных всякий раз, когда некоторые данные вставляются / обновляются / удаляются? Мне кажется, это много ненужных траффиков c и загрузки.

Другой вариант (я думаю) - использовать Cloud Spanner. Я только что обнаружил эту опцию и сейчас читаю документы. Это путь к go?

Редактировать: Облачный гаечный ключ кажется многообещающим, но я также вижу, что он очень дорогой. Стоимость 1 узла с хранилищем 1 ГБ составляет около 650 долларов США в месяц.

Другой вариант - доступ к облачной базе данных SQL через IP-адрес publi c. Проблема в том, что я должен вносить в белый список каждый IP-адрес виртуальной машины, и поскольку я использую автоматическое масштабирование, виртуальные машины создаются на go (с новыми IP-адресами). Как я могу решить эту проблему, чтобы новые виртуальные машины автоматически помещались в белый список базы данных?

Редактировать: с ответом Гейба Вейса, я создал новую (тестовую) виртуальную машину и установил ее облачный SQL прокси и postgresql -клиент. Это работает, когда я устанавливаю соединение или делаю запрос, все хорошо.

Теперь проблема в том, что это не работает в моем nodejs -app. Я использую node- postgres (https://node-postgres.com/), и моя конфигурация подключения выглядит следующим образом: 

const db = new Pool({
    host: '127.0.0.1',
    port: 5432,
    user: 'postgres',
    password: 'postgres',
    database: 'postgres'
})

Я также попытался заменить '127.0.0.1' на localhost, я удалил порт, ... ничего не работает. Учетные данные верны.

Редактировать 2: Когда я запускаю cloud_sql_proxy в фоновом режиме, а также запускаю свое приложение nodejs и я перехожу к http://external_ip_address : 8000 / узел , я вижу журнал в консоли: 

2020/01/22 17:55:20 New connection for "project-id:region:instance-name"

Но через 10 секунд я получаю это: 

2020/01/22 17:57:00 Client closed local connection on 127.0.0.1:5432

Редактировать 3:

Я также попытался изменить хост на / cloudsql / instance_connection_name, но также не дал результатов. 

const db = new Pool({
    host: '/cloudsql/[project-id]:[region]:[instance-name]',
    port: 5432,
    user: 'postgres',
    password: 'postgres',
    database: 'postgres'
})

Ответы [ 2 ]

1 голос
/ 22 января 2020

Решение

Таким образом, решение довольно простое: оно не имело ничего общего с какой-то конфигурацией, но с моим nodejs кодом. Я забыл, что запрос postgresql - это обещание, поэтому я должен дождаться возвращения результатов. Добавление async / await решило проблему.

1 голос
/ 22 января 2020

Spanner, безусловно, вариант, так как вы, скорее всего, получите лучшую задержку для глобально согласованной установки с Spanner, чем при подключении к облаку SQL кросс-регион.

Другой вариант - посмотреть в VP C Peering: https://cloud.google.com/vpc/docs/vpc-peering Я думаю, что вы можете сделать это кросс-регион, хотя я не играл с ним, чтобы быть уверенным, но это может тогда просто "работать" с частными IP-адресами.

Или, если у вас все в порядке с некоторой задержкой в ​​приложении, подключение через publi c IP к облаку SQL является хорошим вариантом, но не используйте разрешенные сети (белые списки). Либо используйте прокси-сервер всякий раз, когда это возможно, либо настройте SSL-соединения (что немного сложно, но определенно стоит) ..

У меня есть подробный блог по использованию publi c IP + Cloud SQL Прокси здесь: https://medium.com/@GabeWeiss / connect-cloud- * sql -publi c -ip- sql -proxy-5513f59e5a9e , что является относительно простым способом go от ваших виртуальных машин.

...