Внезапный сбой SSH-подключения к экземпляру виртуальной машины

Внезапный сбой SSH-подключения к экземпляру виртуальной машины

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

Мне бы не хотелось повторять всю свою работу, создавая новый экземпляр. И я не знаю, связана ли проблема с дисковым пространством.

Может кто-нибудь помочь?

решение1

Сначала вам следуетсобирать журналы:

  1. Перейдите в Compute Engine-> VM instances-> нажмите на NAME_OF_YOUR_VM -> в VM instance detailsразделе поискаЖурналыи нажмите наSerial port 1 (console)
  2. Перезагрузите экземпляр виртуальной машины еще раз.
  3. Проверьте полный журнал загрузки на наличие ошибок и/или предупреждений.

Если вы обнаружили ошибки/предупреждения, связанные с дисковым пространствомвы можете попробовать изменить его размер в соответствии с документациейИзменение размера зонального постоянного диска, также согласно статьеВосстановление недоступного экземпляра или полного загрузочного диска:

Если экземпляр полностью исчерпал дисковое пространство или не работает в гостевой среде Linux, то автоматическое изменение размера корневой файловой системы невозможно, даже после увеличения размера постоянного диска, который ее поддерживает. Если вы не можете подключиться к своему экземпляру или ваш загрузочный диск заполнен и вы не можете изменить его размер, вам необходимо создать новый экземпляр и заново создать загрузочный диск из снимка, чтобы изменить его размер.

В противном случае попробуйтеустранение неполадок вашего экземпляра виртуальной машины через последовательную консоль:

  1. Включить последовательное консольное соединениес gcloudкомандой:

     gcloud compute instances add-metadata NAME_OF_YOUR_VM_INSTANCE \
     --metadata serial-port-enable=TRUE
    

или перейти Compute Engine-> VM instances-> нажать NAME_OF_YOUR_VM_INSTANCE-> нажать EDIT-> перейти в разделRemote accessи проверьтеEnable connecting to serial ports

  1. Создайте временного пользователя и пароль для входа: выключите виртуальную машину и установитескрипт запускадобавив в разделCustom metadataключ startup-scriptи значение:

     #!/bin/bash
     useradd --groups google_sudoers tempuser
     echo "tempuser:password" | chpasswd
    

и затем запустите свою виртуальную машину.

  1. Подключитесь к своей виртуальной машине через последовательный порт.с gcloudкомандой:

     gcloud compute connect-to-serial-port NAME_OF_YOUR_VM_INSTANCE
    

    или перейдите к Compute Engine-> VM instances-> нажмите NAME_OF_YOUR_VM_INSTANCE-> и нажмитеConnect to serial console

  2. Проверьте, что пошло не так.

  3. Отключить доступ через последовательный портс gcloudкомандой:

     gcloud compute instances add-metadata NAME_OF_YOUR_VM_INSTANCE \
     --metadata serial-port-enable=FALSE
    

или перейти Compute Engine-> VM instances-> нажать NAME_OF_YOUR_VM_INSTANCE-> нажать EDIT-> перейти в разделRemote accessи снимите флажок Enable connecting to serial ports. Имейте в виду, что в соответствии с документациейВзаимодействие с последовательной консолью:

Осторожность: Интерактивная последовательная консоль не поддерживает ограничения доступа на основе IP, такие как белые списки IP. Если вы включите интерактивную последовательную консоль на экземпляре, клиенты смогут попытаться подключиться к этому экземпляру с любого IP-адреса. Любой может подключиться к этому экземпляру, если он знает правильный ключ SSH, имя пользователя, идентификатор проекта, зону и имя экземпляра. Используйте правила брандмауэра для управления доступом к вашей сети и определенным портам.

Если вам не удалось подключиться через последовательную консоль, попробуйте следовать документацииУстранение неполадок SSHразделПроверьте экземпляр виртуальной машины, не выключая ееипроверьте диск вашей виртуальной машины на другой виртуальной машине. Таким же образом вы можете перенести свои данные на другой работающий экземпляр виртуальной машины.

решение2

Что сработало для меня, чтобы перейти на экземпляр VM и сделать сброс. Я ничего не потерял, и мой сайт WordPress был по-прежнему настроен правильно после сброса и мог войти обратно в экземпляр VM

Связанный контент