이미징 저는 exim4(또는 데이터베이스, syslog 데몬...)와 같은 메일 서버를 실행하고 있습니다. 이제 이 패키지를 업데이트할 때 업데이트 후에 애플리케이션을 중지하거나 최소한 다시 시작해야 한다고 가정합니다. 이 시간 내에 이메일을 보내면 실패합니다. 업데이트할 때 이런 상황을 고려하는 건가요, 어떤 대책이 있는 건가요, 아니면 이메일을 나중에 다시 보내는 소프트웨어인가요?
답변1
일반적으로 이메일은 서비스가 제공될 때까지 대기열에 넣어 두는 소프트웨어를 통해 전송됩니다. 서버에 연결할 수 없는 경우 여러 가지 이유가 있을 수 있습니다. 즉, 서버에 연결하는 소프트웨어 전송에는 트랜잭션을 다시 연결하고 재시도하는 메커니즘이 있어야 합니다.
그 외에도 가동 중지 시간이 없다는 것을 알고 있다면 시스템의 소프트웨어를 업그레이드할 이유가 무엇인지 묻고 싶습니다. 특정 소프트웨어의 실행 파일 및 공유 라이브러리를 다운로드(?)하고 압축을 풀고(?) 교체하고 있는데, 이 작업이 실패하여 시스템을 사용할 수 없게 될 수 있는데, 다운타임을 피할 수 없다면 왜 그렇게 하시겠습니까?
답변2
이는 모두 소프트웨어의 기능과 패키지의 설치/업데이트 스크립트에 따라 다릅니다.
일부 프로그램은 업그레이드 중에도 정상적으로 계속 작동하며 업그레이드가 완료된 후에만 다시 시작하면 됩니다. 그리고 종종 패키지 관리자는 패키징 스크립트를 통해 이 사실을 활용합니다.
(업그레이드 중에 패키지가 불필요하게 중지되는 경우 일반적으로 이를 버그로 보고합니다. 예를 들어 apt-get dist-upgrade업그레이드해야 할 패키지가 많거나 패키지 중 하나를 업그레이드할 때 오류가 발생하는 경우 매우 긴 중단이 발생할 수 있기 때문입니다. 문제는 가동 중지 시간을 최소화하기 위해 분산 업그레이드의 일부가 아닌 가장 중요한 서비스를 개별적으로 업그레이드하는 것을 선호합니다. 물론 비프로덕션 시스템에서는 업그레이드를 테스트한 후입니다.
다른 프로그램은 실행 중 환경 변화를 허용할 수 없으므로 업그레이드 프로세스 중에 중지해야 합니다. 다시 말하지만, 이는 일반적으로 패키지 관리자의 스크립트에 의해 자동으로 처리됩니다.
두 경우 모두 가장 적절한 조치를 취하기 위해 패키징하는 소프트웨어를 완전히 이해하는 것이 패키지 관리자의 임무입니다.
답변3
대부분의 MTA 작동 방식은 전자 메일 메시지를 대기열 디렉터리에 넣은 다음 대기열에 있는 파일을 선택하여 가능한 경우 보내는 것입니다. MTA 업그레이드 중에 이메일을 보내는 데몬은 잠시 동안 중지되지만 클라이언트 프로그램이 이메일을 보내는 경우 데몬이 다시 시작될 때 이메일은 처리를 위해 계속 대기열에 대기하게 됩니다.
반면, 다른 서버가 이 서버에 접속을 시도했지만 업그레이드가 진행 중이어서 응답을 받지 못한 경우, 다른 서버는 이메일을 대기열에 넣고 잠시 후에 다시 시도합니다. 이메일 전달은 매우 안정적으로 설계되었습니다(대부분 스팸 및 스팸 대책의 영향으로 인해 예전만큼 안정적이지는 않지만).
다른 유형의 소프트웨어의 경우 데몬이 다시 시작되는 동안 잠시 가동 중지 시간이 있을 수 있습니다. 이러한 가동 중지 시간은 일반적으로 여러 대의 서버 시스템을 보유하고 이들 사이의 연결 균형을 조정하여 처리됩니다. 그럼에도 불구하고 이러한 중복성은 고가용성 시스템에 필요합니다(하드웨어 오류는 항상 가능함).
답변4
다운타임 없이 업데이트할 수 있는 소프트웨어가 있습니다. 따라서 소프트웨어는 두 가지 버전, 즉 새 버전과 이전 버전을 동시에 실행할 수 있어야 합니다. 업데이트 중에도 이전 버전은 연결된 클라이언트에 계속 서비스를 제공합니다. 업데이트 후에는 새 버전이 제어권을 넘겨받아 새 클라이언트를 처리합니다. 이전 버전은 마지막 클라이언트의 연결이 끊어진 후 닫히고 삭제될 수 있습니다(또는 새 버전이 제대로 작동하지 않는 경우 우아한 성능 저하 메커니즘이 구현되어 대체 모드로 백그라운드에 남아 있을 수 있습니다.) 그러나 이러한 메커니즘은 다음에서 구현되었습니다. 사용 사례가 거의 없습니다.
그렇지 않으면 해고에 대한 조던의 발언은 정확합니다.