По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Часто бывает, что на системе Linux произошла незапланированная или по неизвестным очевидным причинам, перезагрузка. Поиск и устранение первопричины может помочь предотвратить повторение таких проблем и избежать незапланированных простоев. Есть несколько способов выяснить, что вызвало перезагрузку. В этой статье мы обсудим эти способы и способы использования доступных утилит и журналов в системе Linux для устранения таких сценариев. Проверка времени перезагрузки Чтобы посмотреть, когда именно произошла перезагрузка системы можно воспользоваться командами who и last Проверка системных журналов Кроме того, можно сопоставить время перезагрузки, которую требуется диагностировать, с системными сообщениями. Для систем CentOS/RHEL журналы можно найти по адресу /var/log/messages, а для систем Ubuntu/Debian - по адресу /var/log/syslog. Для фильтрации или поиска конкретных данных можно использовать команду tail или любимый текстовый редактор. Как видно из приведенных ниже журналов, такие записи предполагают завершение работы или перезагрузку, инициированную администратором или пользователем root. Эти сообщения могут варьироваться в зависимости от типа ОС и способа запуска перезагрузки или завершения работы, но вы всегда найдете полезную информацию, просматривая системные журналы, хотя этого не всегда может быть достаточно, чтобы определить причину. Ниже приведена одна такая команда, которую можно использовать для фильтрации системных журналов: sudo grep -iv ': starting|kernel: .*: Power Button|watching system buttons|Stopped Cleaning Up|Started Crash recovery kernel' /var/log/messages /var/log/syslog /var/log/apcupsd* | grep -iw 'recover[a-z]*|power[a-z]*|shut[a-z ]*down|rsyslogd|ups' Зафиксированные события не всегда могут быть конкретными. Всегда отслеживайте события, которые дают признаки предупреждений или ошибок, которые могут привести к выключению или сбою системы. Проверка журнала auditd Для систем, использующих auditd – это отличное место для проверки различных событий с помощью инструмента ausearch. Используйте приведенную ниже команду для проверки последних двух записей из журналов аудита. $ sudo ausearch -i -m system_boot,system_shutdown | tail -4 Появится сообщение о двух последних остановках или перезагрузках. Если это сообщает о SYSTEM_SHUTDOWN, за которым следует SYSTEM_BOOT, все должно быть хорошо. Но, если он сообщает две строки SYSTEM_BOOT подряд или только одно сообщение SYSTEM_BOOT, то, скорее всего, система некорректно завершила работу. Вывод при нормальной работе должен быть примерно следующим: $ sudo ausearch -i -m system_boot,system_shutdown | tail -4 ---- type=SYSTEM_SHUTDOWN msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' ---- type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' В приведенных ниже выходных данных перечислены два последовательных сообщения SYSTEM_BOOT, которые могут указывать на аварийное завершение работы, хотя результаты нужно скорректировать с данными системного журнала. $ sudo ausearch -i -m system_boot,system_shutdown | tail -4 ---- type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' ---- type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' Анализ журнала systemd Чтобы сохранить журнал системных логов на диске, необходимо иметь постоянный системный журнал, иначе логи будут очищаться при перезагрузке. Для этого можно либо внести изменения в /etc/systemd/journald.conf, либо создать каталог самостоятельно с помощью следующих команд: $ sudo mkdir /var/log/journal $ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null $ sudo systemctl -s SIGUSR1 kill systemd-journald После этого можно дополнительно перезагрузить систему для ввода нескольких записей перезагрузки в журнал, хотя это и не требуется. Приведенную ниже команда позволяет выводить список записанных событий о загрузке из журнала: $ journalctl --list-boots Вот его выходные данные на моем сервере: Как видно на рисунке, в системе есть несколько событий загрузки. Для дальнейшего анализа причины конкретной перезагрузки используйте: $ journalctl -b {num} –n Здесь {num} будет индексом, заданным в команде journalctl --list-boots в первом столбце. В приведенных выше выходных данных можно просмотреть сообщения, зарегистрированные в журнале, и отследить аномалии, если таковые имеются. Заключение Не всегда можно определить причину перезагрузки Linux с помощью одной команды или из одного файла журнала. Поэтому всегда удобно знать команды и журналы, которые фиксируют события, связанные с системой, и могут сократить время, необходимое для поиска первопричины. Приведенные выше примеры дают вам возможность начать поиск и устранение неисправностей. Используя комбинацию таких инструментов и журналов, вы можете быть уверены в том, что произошло и как перезагрузилась ваша система.
img
Повсеместное распространение компьютерных сетей в крупных корпорациях породило ряд проблем. Чем больше масштабы сети, тем дороже будет ее обслуживание. Действительно, при расширении территориальной деятельности организация должна закупать новое, зачастую дорогостоящее оборудование и объявлять тендер на услуги сетевых провайдеров связи. При этом если компания ориентируется на высокую скорость и надежность обмена данными, то эти предложения должны постоянно обновляться. Для оптимизации решения таких проблем и были созданы Software Defined Wide Area Network — программно-определяемые сети в рамках глобальной сети (WAN). Применение этой технологии позволяет серьезно сэкономить на каналах передачи данных, не теряя качества, а также ускорить включение в общую сеть организации новых территориально удаленных филиалов. Зачем нужна программно определяемая WAN сеть? Одной из главных возможностей, которые SD-WAN предоставляет пользователю, является оптимизация сетей VPN или MPLS. Как правило, небольшие организации с одним офисом могут вполне неплохо обходиться без данной технологии, однако крупные организации, имеющие филиалы в разных городах (или странах) вынуждены искать надежные и быстрые способы связи между офисами. Даже если у провайдера услуг связи есть покрытие на оба пункта – это не всегда является надежным решением, так как по пути пакеты данных могут теряться, информация может приходить поврежденной, несвоевременной или не в полном объеме. Если же покрытия основного провайдера на территории, где компания планирует открывать новый филиал, нет, то в данном случае нужно будет уже заключать второй договор на обслуживание уже с местным провайдером. При этом при передаче информации между VPN-сетями различных провайдеров пользователь также столкнется с вышеописанной проблемой, но уже более остро, поскольку чем большее количество сетей минует информация при передаче, тем выше вероятность ее повреждения либо перехвата. Кроме того, если организация серьезно озабочена проблемой надежной передачи данных, то не лишним будет запустить также дублирующий резервный канал связи, уже от другого поставщика телекоммуникационных услуг. Услуги эти, к слову, недешевы, да и помимо этого организация общей компьютерной сети организации с закупкой оборудования и прокладкой кабелей – дело затратное. Выгодно ли для бизнеса внедрение SD-WAN решений? Главным плюсом SD-WAN, в данном случае, является сокращение расходов на телекоммуникационные услуги и закупку более дорогого оборудования. Технически, программно-распределяемая сеть устроена следующим образом: компания закупает, устанавливает в центре обработки данных и настраивает модуль контроллера. Это самая основная (и дорогая) часть SD-WAN с технической точки зрения. К коммутатору контроллера подключаются основной и резервный каналы связи, при этом специализированные программы на борту контроллера будут анализировать загруженность каналов передачи данных и подбирать оптимальный баланс передачи. Кроме того, ПО контроллера создает надежную, безопасную и прозрачную сеть, в которой контроллер выступает в роли основного роутера и «мозга». Да, решение не из дешевых, но технология будет окупаться (по оценке специалистов, в среднем за 5 лет) за счет распределения передачи данных, а также за счет экономии оборудования, закупаемого для филиалов. Нет необходимости закупать более «умные» устройства, а контроллер может удаленно управлять и сетями попроще, причем в автоматическом режиме – достаточно подключить устройство в новом офисе к сети, а все настройки придут с основного модуля. Кроме того, благодаря использованию такой технологии может возрасти качество телефонной связи и качество предоставления других IT-услуг в организации, которые могут быть чувствительны к качеству канала и задержкам. На текущий момент многие компании занимаются созданием и оптимизацией функционала SD-WAN. Это и Huawei, и Mikrotik, и Cisco, а также многие другие разработчики. Поэтому у пользователя есть возможность ознакомиться с вариантами от разных поставщиков и подобрать для себя наиболее оптимальное решение.
img
Привет, друг! Если ты читаешь эту статью, то скорее всего столкнулся с ошибкой VT-x/AMD-V hardware acceleration is not available on your system когда пробовал создать виртуальную машину в Virtual Box, или такой ошибкой при работе с VMWare: This host supports Intel VT-x, but Intel VT-x is disabled или чем-то похожим при работе с другой средой виртуализации. Продолжай читать и ты обязательно найдёшь причину! Для начала, позволь вкратце объяснить, что такое VT-x и AMD-V. VT-x – это технология, разработанная компанией Intel в 2005 году, которая позволила процеcсорам (CPU) данного производителя поддерживать аппаратную виртуализацию. Грубо говоря, появилась возможность имея один компьютер, создать другой внутри него и даже с другой операционной системой! AMD-V - это технология аппаратной виртуализации от компании AMD. Первые процессоры от производителя AMD появились на рынке годом позже, в 2006 году. Итак, теперь вот тебе топ 3 причин, по которым ты мог встретить вышеупомянутые ошибки: Процессор твоего "комплюктера" попросту не поддерживает технологии виртуализации VT-x/AMD-V. Возможно ты являешься обладателем очень старого или наоборот крайне специфичного девайса, CPU которого просто не умеет в виртуализацию. В таком случае, ты не сможешь устранить те ошибки и запустить виртуалку в любой среде виртуализации. Но не огорчайся, есть масса способов покрутить виртуалки, например, воспользоваться услугами VDS/VPS хостера! VT-x/AMD-V отключила Hyper-V. Hyper-V это проприетарная технология виртуализации от Microsoft, которая по умолчанию вырубает поддержку VT-x/AMD-V, чтобы избежать конфликтов. Короче придётся выбирать между Hyper-V и другой конфликтующей средой виртуализации. Технология VT-x или AMD-V просто выключены и их нужно включить. По умолчанию, поддержка виртуализации выключена в BIOS и чтобы победить ошибки из начала статьи и, наконец запустить заветную виртуалку, тебе нужно просто зайти в BIOS и включить VT-x/AMD-V! В зависимости от производителя твоего компьютера, может быть несколько вариантов перехода в BIOS. Обычно, тебе нужно просто перезагрузить компьютер и дождаться на экране надписи: Press to enter BIOS, а вот какая-то кнопка может быть разной. Вот тебе несколько примеров для разных производителей: Asus, Lenovo, DELL Как правило просят нажать F2 Перейти на вкладку Advanced, выбрать Virtualization Technology и нажать Enter Сменить состояние строки с Disabled на Enabled после чего нажать F10, чтобы сохранить изменения и перезагрузить компьютер Acer, HP Как правило просят нажать F2 ну или F1 или же CTRL+ALT+ESC или F10 Нажать на правую стрелку и перейти на вкладку System Configuration, выбрать Virtualization Technology и нажать Enter Сменить состояние строки с Disabled на Enabled после чего нажать F10, чтобы сохранить изменения и перезагрузить компьютер Компьютеры с процессорами AMD Как правило просят нажать F2 Выбрать вкладку Advanced затем CPU Configuration, после чего выбрать SVM Mode и нажать Enter Сменить состояние строки с Disabled на Enabled после чего нажать F10, чтобы сохранить изменения и перезагрузить компьютер
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59