리눅스로 다운 타임을 피하는 방법?

우분투 소프트웨어를 자주 업데이트하려면 재부팅해야합니다 (다운 타임과 같은 부작용이 발생할 수 있음).

Ubuntu에 재부팅하지 않고 커널 업데이트를 허용하는 https://www.ubuntu.com/livepatch 가 있지만 유료 서비스입니다. 도 있습니다 Ksplice에서가 .

업그레이드 / 패치가 재부팅을 요구하지 않는 Linux 배포판 / 프로세스가 있습니까?

(I는 고 가용성 (HA) 서버를 설정하고 일회용 서버가있는 모범 사례를 알고 - 나는거야 그래서 없는 서비스를 유지 대해 물어하지만, 실제 서버에.)

귀하의 질문에, "업그레이드 / 패치가 재부팅을 요구하지 않는 Linux 배포판 / 프로세스가 있습니까?", 나는 전혀 모른다. 라이브 패치가 왜 어디서나 사용 가능한 경험이 아닌지에 대한 Michael Hampton의 의견 외에도 라이브 패치는 재부팅과 동일한 결과를 얻지 못합니다.

이를 설명하기위한 일화 : 최근에 특정 유틸리티가 다수의 컴퓨터에서 segfaulting을 시작한 문제를 조사했습니다. 최근에 업그레이드 한 항목이 손상되었는지 확인하는 데 사용 된 공유 라이브러리를 살펴 보았습니다. ldd는 실행 파일이 아니라고 말했다. (같은 바이너리를 랩톱으로 가져 왔을 때 ldd는 공유 라이브러리 종속성을 잘 볼 수 있음). gdb에서 단계별로 시도했습니다. 그것은 심지어 첫 번째 지시에 도달하기 전에 segfaulted.

결함의 타이밍을 살펴보면 Ksplice 패치가 최근에 적용된 것을 발견했습니다. 나는 패치를 제거했고 바이너리는 segfault가 아니었다가 다시 추가했다가 다시 segfaulting을 시작했다. 동등하게 패치 된 커널로 재부팅하면 정상적으로 작동했습니다. Ksplice 사람들이 제대로 적용하지 않은 32 비트 지원용 패치로 밝혀졌습니다. 그들의 신용으로 그들은 몇 시간 안에 고정 된 패치를 발행했으며 개입없이 우리 함대에서 올바르게 작동하도록 돌아 왔습니다.

또 다른 예 : Meltdown / Spectre 패치는 매우 침습적이어서 우분투 커널 팀은 라이브 패치가 실용적이지 않다고 판단하여 라이브 패치를 다시 받기 전에 시스템을 고정 커널로 재부팅해야했습니다.

우리는 많은 Ksplice 및 Canonical Livepatch 시스템과 함께 많은 물리적 서버와 가상 서버를 운영하고 있습니다. 둘 다 다른 많은 소프트웨어보다 훨씬 안정적이지만 커널 라이브 패치에 의존하는 것보다 재부팅하기 쉬운 아키텍처로 설계된 서비스를 여전히보고 싶습니다.

서비스의 가용성을 높이는 것과 개별 시스템의 가용성을 높이는 것에는 중요한 차이점이 있습니다.

대부분의 경우 서비스의 가용성을 높이는 것이 목표이며 개별 시스템의 가용성은 해당 목표를 달성하기위한 수단 일뿐입니다. 그러나 개별 머신의 가용성을 개선하여 목표를 달성 할 수있는 범위에는 한계가 있습니다.

소프트웨어를 업데이트해야하기 때문에 다운 타임을 모두 제거 할 수 있어도 개별 시스템을 100 % 사용할 수는 없습니다. 따라서 개별 시스템의 가용성보다 서비스 가용성을 높이려면 중복성을 더 높은 수준으로 설계해야합니다. 질문의 마지막 문장은 적어도 원칙적으로 이것을 알고 있음을 보여줍니다.

개별 시스템이 제공 할 수있는 것보다 더 가용성이 높은 서비스를 설계하면 더 이상 개별 시스템의 고 가용성을 달성해야하는 부담이 없습니다. 따라서 고 가용성 서비스의 경우 재부팅을 피할 필요가 없습니다. 대신 개별 장비의 신뢰성을 희생하여 절감 효과를 높이면 신뢰성을 훨씬 더 높일 수있는 다른 영역에 적용 할 수 있습니다.

개별 하드웨어 구성 요소가 커널의 실시간 패치에 실패하는 경우 높은 수준의 시스템이 안정적으로 설계되면 이점이 위험에서 위험으로 바뀝니다.

라이브 패치 된 시스템과 최신 커널 버전으로 부팅 된 시스템의 동작에 미묘한 차이가있을 수 있으므로 위험합니다. 이로 인해 다음에 시스템을 재부팅 할 때 중단이 발생할 수있는 잠재적 인 버그가 발생할 수 있습니다. 이 문제는 일부 슬레이트를 완화하는 방법으로 깨끗한 슬레이트가 나타나도록 재부팅하여 증폭됩니다.

언젠가는 시스템 재부팅이 도움이 될 수 있다고 생각되는 중단이 발생할 수 있습니다. 그러나 다시 부팅하면 잠재적 버그로 인해 시스템이 원하는 상태로 돌아 오지 못하게됩니다. 라이브 패치는 잠재적 인 버그가 발생할 수있는 유일한 방법은 아닙니다. 서비스가 수동으로 활성화되고 부팅 중에 시작하도록 구성되지 않았거나 너무 일찍 시작하도록 구성되어 있지 않은 등의 평범한 문제로 인해 발생할 수도 있습니다. 불만족스러운 종속성으로 인해 나타나지 않습니다.

이러한 이유로 인해 문제가 발생하면 문제를 감지하고 재부팅 순서를 일시 중지 할 수있을 정도로 느린 속도로 개별 시스템을 정기적으로 재부팅하면 실제로 고 가용성 서비스를보다 쉽게 ​​달성 할 수 있습니다.