Иван Шумов
Несмотря на то, что ваши советы правильные и хорошие в этом треде, реальность иногда выбивает из под нас табуретку.
Проводил исследование на предмет уменьшения времени ответа для одного сервиса. Сервис в us-east-1 а клиент в Австралии :D
Опробованы Global accelerator, CF, точка входа на GCE
чистый EIP из австралии - 1500ms
GA - 1800-2000ms
CDN(делал как чистый, так и через APIGW) - ~1200ms
Точка входа через google (тупой TCP прокси, так, попробовать, поднятый в европе) - 900ms
Как говорится делайте выводы =)
sailorpapay С пирингом: до определенного момента вы все делали правильно. Последовательность действий:
1. создать пиринг и принять его (здесь насколько я понимаю у вас все было правильно сделано)
2. настроить роутинг между сетями: регион A:
добавить в route table той подсети где находится ec2 инстанс, маршрут на 172.30.0.0/16 (CIDR VPC региона Б) через идентификатор пиринга в VPC региона A (с регионом Б они разные!) Регион Б:
(то же самое но напишу) добавить в route table тех подсетей где развернут RDS, маршрут на 172.31.0.0/16 (CIDR VPC региона A) через идентификатор пиринга в регионе Б(еще раз, они разные с регионом A)
3. Добавить в Security Group ec2 инстанса подсеть региона Б. Добавить в Security Group RDS инстансов подсеть региона A.
Удостовериться что доступ есть. Если нет - проверьте, может быть вы еще Network ACL накрутили, тогда и его надо проверять.
4. Только после этого можно попробовать убрать маршрут 0.0.0.0/0 через igw из таблицы маршрутизации подсети ec2 инстанса(если это действительно необходимо)
P.S. Что-то мне подсказывает что у вас маловато опыта в AWS. Пройдите курсы, как чуть выше написали, особенно по VPC и Networking.
На https://www.qwiklabs.com/home?locale=en есть еще тренинги где можно бесплатно потыркаться.
Два года назад cloud academy давал триал где можно было основы послушать
(с) Лучше день потерять чем потом за 5 минут долететь.
P.S. да, я даю не оптимальные советы, потому что можно еще роуты прописать только на CIDRы сабнетов.
Можно добавить доступ между security groups - чтобы сделать правильно и как рекомендует AWS. Но автор, как мне кажется, решает не проблему "идеально сделать" а "сделать чтобы работало.
Ах да, судя по сложностям которые вы описываете, вы все еще не создаете private VPC для работы базы. Если она у вас в Default VPC в аккаунте то вам ОЧЕНЬ нужно послушать и поучиться VPC и Networking в AWS.
вот так выглядит вход в аккаунт, не требующий alias\account-id
А вот так - требующий
Со второго можно перейти в первый нажав ссылку внизу с "root account credentials"
Вам, насколько я понял, нужно попасть именно в root
kaddata, простите, не понял вопроса
этот "пинг" выполняется на движке google scripts
High Availability для него обеспечивает гугл.
Для вас это, можно сказать, самый настоящий serverless
Ошибки и проблемы выполнения скрипта придут вам на почту, как "автору" проекта в google scripts.
Так же вы можете дописать скрипт который разработал автор (автор - не я ) под ваши нужды : после копирования документа теперь это ваш скрипт :D
Дмитрий Шумов, ссылочка на форумы MS как диагностировать такую проблему и в чем может быть причина почему оно пустое.
Однако же, и это лично мое мнение, данные методы погрузят вас глубже в знание того как работает аутентификация в AD(это хорошо), но совершенно необязательно помогут решить вашу проблему(и это не очень хорошо).
А потому я посоветовал бы вам завести другую учетную запись с такими же правами, например pukcab(да, я люблю пошутить), для целей бэкапа и все процессы, завязанные на старую запись с очевидным именем переключить на нее. Если проблема с новой учеткой повторится, то у вас как раз на виду будут все места где вы вбили новую учетку и нужно будет изучать логи того ПО которое ее использует на предмет ошибок входа в AD.
Этот EventID - сообщение о том что для данной учетки неверно вводится пароль и срабатывает политика блокировок, как вам уже сказали выше в комментах
В доках MS указано, что в ивенте есть поле Additional Information: Caller Computer Name указывающее на машины где произошел неверный ввод пароля.
Есть ощущение что это невозможно. Уже очень давно, например, мне не удается восстановить пароль от скайпа, используя skype username - перебрасывает на ввод live аккаунта. Возможно, MS это просто выключили. На всякий случай подпишусь на вопрос, вдруг есть другие мнения
Так же добавлю что отлично умеет показывать текущие соединения (в том числе и с разбивкой по программам кто соединяется или принимает) встроенная утилита resmon
В Security Group есть вкладки ingress и egress rules
первые - входящие подключения, вторые - исходящие.
Да, надо добавить правило доступа с 0.0.0.0/0 в ingress
и правило доступа на 0.0.0.0/0 в egress (если его там нет)
Несмотря на то, что ваши советы правильные и хорошие в этом треде, реальность иногда выбивает из под нас табуретку.
Проводил исследование на предмет уменьшения времени ответа для одного сервиса. Сервис в us-east-1 а клиент в Австралии :D
Опробованы Global accelerator, CF, точка входа на GCE
чистый EIP из австралии - 1500ms
GA - 1800-2000ms
CDN(делал как чистый, так и через APIGW) - ~1200ms
Точка входа через google (тупой TCP прокси, так, попробовать, поднятый в европе) - 900ms
Как говорится делайте выводы =)
sailorpapay С пирингом: до определенного момента вы все делали правильно. Последовательность действий:
1. создать пиринг и принять его (здесь насколько я понимаю у вас все было правильно сделано)
2. настроить роутинг между сетями:
регион A:
добавить в route table той подсети где находится ec2 инстанс, маршрут на 172.30.0.0/16 (CIDR VPC региона Б) через идентификатор пиринга в VPC региона A (с регионом Б они разные!)
Регион Б:
(то же самое но напишу) добавить в route table тех подсетей где развернут RDS, маршрут на 172.31.0.0/16 (CIDR VPC региона A) через идентификатор пиринга в регионе Б(еще раз, они разные с регионом A)
3. Добавить в Security Group ec2 инстанса подсеть региона Б. Добавить в Security Group RDS инстансов подсеть региона A.
Удостовериться что доступ есть. Если нет - проверьте, может быть вы еще Network ACL накрутили, тогда и его надо проверять.
4. Только после этого можно попробовать убрать маршрут 0.0.0.0/0 через igw из таблицы маршрутизации подсети ec2 инстанса(если это действительно необходимо)
P.S. Что-то мне подсказывает что у вас маловато опыта в AWS. Пройдите курсы, как чуть выше написали, особенно по VPC и Networking.
На https://www.qwiklabs.com/home?locale=en есть еще тренинги где можно бесплатно потыркаться.
Два года назад cloud academy давал триал где можно было основы послушать
(с) Лучше день потерять чем потом за 5 минут долететь.
P.S. да, я даю не оптимальные советы, потому что можно еще роуты прописать только на CIDRы сабнетов.
Можно добавить доступ между security groups - чтобы сделать правильно и как рекомендует AWS. Но автор, как мне кажется, решает не проблему "идеально сделать" а "сделать чтобы работало.
Ах да, судя по сложностям которые вы описываете, вы все еще не создаете private VPC для работы базы. Если она у вас в Default VPC в аккаунте то вам ОЧЕНЬ нужно послушать и поучиться VPC и Networking в AWS.