질문
네트워크 구성을 원격으로 변경할 때 오류가 발생할 경우 네트워킹에서 다른 구성 파일을 사용하려고 시도할 수 있는 방법이 있습니까?
배경- tldr;
나는 주변을 검색했지만 ifup에 파일을 전달하는 것과 같은 작업을 수행하는 것에 대한 참조를 실제로 보지 못했습니다. 비록 그것이 ifup에 대한 매뉴얼 페이지를 확인하는 아이디어를 주었지만 상관없이 말입니다. 지금은 테스트할 수 없습니다.
저는 여기 다른 도시에서 일하고 있는 동안 우리 서버는 데이터 센터로 이전되었습니다. 네트워킹은 내 강점이 아니었고 설치 후 처리량을 향상시키기 위해 두 개의 NIC를 함께 결합하고 싶었습니다. 그러나 그렇게 하면 네트워킹 인터페이스가 초기화에 실패하여 연결이 끊어졌습니다.
나는 /etc/sysconfig/network-scripts에 가질 본드를 설정하려고 시도했습니다.
bond0: eth0과 eth1 가져오기 eth0: eth1 결합 설정: 결합 설정 후 eth1:1은 내가 다시 차단될 경우를 대비해 IP를 여기에 바인딩할 수 있다고 생각합니다...
불행하게도 이것은 효과가 없었으며 데이터 센터에 가서 지원을 수행할 수 있는 자격을 갖춘 유일한 사람은 내 상사뿐이었습니다. 좋은 상황은 아닙니다. (그리고 연결이 끊어지지 않도록 가상 서버에서 두 번 테스트했습니다.)
이제 우리는 그것을 결합했지만 내가 알 수 있는 한 "만약의 경우" 구성을 수행할 수 있는 방법은 없습니다...
따라서 오늘은 서버 내부의 VM에 대한 연결을 브리지해야 했습니다.... 앗, 그런데 또 연결이 끊어졌습니다. 이번 달에 상사가 데이터 센터를 방문하는 것은 이번이 두 번째입니다. :얼굴 손바닥:
인터페이스가 감지되지 않는 경우 네트워킹이 완전히 다른 구성 파일 세트를 사용하는 방법이 있어야 합니다. 즉, 안전 장치를 사용하여 네트워킹 시도가 실패한 후 5번마다 cron 작업이 실행되도록 하는 방법이 있습니다. 네트워크가 다운된 경우 몇 분 안에 안전 장치에 대한 네트워크 연결이 다시 설정됩니다.
지금 당장 리눅스 박스에 접근할 수 있었으면 좋겠지만, 보통 서비스 네트워크 재시작 명령을 수행하여 네트워크를 확인합니다. 네트워크가 감지되지 않으면 네트워크가 작동될 때까지 다른 비상 안전 구성을 시도하도록 비상 안전 명령을 내리는 방법이 있습니까?
답변1
요약: OOB를 선택하고 구성 관리를 살펴보세요. 그렇지 않으면 자체 솔루션을 구축해야 합니다.
저는 이런 종류의 작업을 수행하기 위해 Linux에 사전 구축된 항목에 익숙하지 않습니다. 일반적으로 IPMI/ILOM/OOB가 사용됩니다. 호스트에 대한 원격 콘솔 액세스가 가능할 뿐만 아니라 (일반적으로) 하드웨어 상태를 확인하고, 하드웨어가 잠겨 있는 경우 원격 재부팅을 실행하는 등의 작업도 수행할 수 있습니다.
OOB가 옵션이 아닌 경우 cron 작업을 설정하여 다양한 시나리오를 확인하고 호스트가 연결할 수 없는 상태인지 확인하고 자체 복구를 시도하는 작업을 수행하는 것을 고려할 수 있습니다.
물론 여기에는 큰 위험이 따릅니다. 다양한 시나리오를 고려해야 합니다. 게이트웨이 IP 주소에 도달할 수 있는지 확인하고 싶지만 게이트웨이가 잠시 사라집니다. 문제가 아닌 경우 호스트가 인터페이스를 재구성하는 것을 원하지 않을 수 있습니다. 상자와 함께 있지만 상류에 있는 것입니다.
로컬 시스템을 예상 상태로 복원/매시간 예상 상태인지 확인하도록 구성할 수 있는 구성 관리 제어 옵션도 있습니다. 구성 파일의 로컬 복사본을 사용하는 대신 구성 파일의 로컬 복사본을 사용하도록 해당 애플리케이션을 구성해야 합니다. 원격 서버와 대화하는 것보다 가능합니다. 이는 관리하는 시스템 수에 따라 다소 과도할 수 있습니다(5개 이상인 경우 일반적으로 구성 관리를 살펴보는 것이 좋습니다. 그러면 많은 시간이 절약됩니다).
변경 사항을 위해 박스 모니터에 일부 스크립트를 두는 경로로 가고 싶다면 꽤 오랫동안 테스트 실행 모드로 설정하는 것이 좋습니다. 이렇게 하면 네트워크 인터페이스를 재구성해야 한다고 생각했을 때 로그를 남길 수 있으므로 서비스를 시작하기 전에 기능을 디버그/테스트/온전성 검사할 수 있습니다.
더 좋은 점은 두 번째 또는 세 번째 인터페이스(본딩을 원하므로)를 호스트에 케이블로 연결하고 해당 인터페이스 구성을 절대 건드리지 않거나 스크립트가 해당 인터페이스를 사용하여 서비스 자체를 복원하도록 할 수 있다는 것입니다. 나쁘다고 생각하는 인터페이스를 잠재적으로 방해하는 것이 아니라 이 목적으로만 사용하는 세 번째 인터페이스일 뿐입니다.