QEMU 패치에 대한 종합 가이드

패치가 적용되지 않은 서비스 하나만 있어도 피해를 입힐 수 있는 침입의 문이 열리기 때문에 패치를 철저하게 적용하는 것은 매우 중요한 부분입니다. 그 결과 정기적인 패치가 필요한 디바이스, 서비스 및 애플리케이션의 목록이 길어지며, 여기에는 QEMU와 같이 백그라운드에서 실행되는 서비스도 포함됩니다.

물론 기업 환경에서 대규모의 복잡한 워크로드를 보다 효율적으로 실행할 수 있게 해주는 인기 가상화 도구인 QEMU(Quick EMUlator )가 있습니다. QEMU는 백그라운드에서 조용히 작동하지만 지속적으로 패치를 적용해야 하는 필수 서비스입니다.

그러나 QEMU를 패치하는 것은 혼란을 야기할 수 있기 때문에 때때로 패치 작업의 후순위에 놓일 수 있습니다. 이 글에서는 QEMU 패치가 왜 중요한지 간략하게 설명하고 QEMU를 안전하게 패치하기 위해 취할 수 있는 조치에 대해 설명합니다. 또한 QEMU 패치를 위한 중단 없는 방법인 실시간 패치에 대해서도 다룹니다.

내용:
1 - QEMU 패치가 중요한 이유는 무엇이며 왜 그렇게 까다로운가요?
2 - QEMU 패치 가이드
3 - 빠르고 더럽지만 부주의한 방법
4 - 시스템 관리자 접근 방식
5 - 모범 사례, 엔터프라이즈급 접근 방식
6 - 라이브 패치는 대안입니다
7 - 결론

QEMU 패치가 중요한 이유는 무엇이며, 왜 그렇게 까다로운가요?

컴퓨터의 거의 모든 애플리케이션과 서비스는 해커의 표적이 될 수 있으며, 그것이 실행 중이라면 해커의 표적이 될 수 있습니다. 백그라운드에서 보이지 않는 작업을 수행하며 깊숙이 실행되든 상관없습니다.

QEMU는 워크로드에서 가장 눈에 띄는 요소가 아니더라도 다른 서비스와 마찬가지로 패치를 적용해야 합니다. 사용 중인 다른 서비스 및 애플리케이션과 마찬가지로 QEMU의 취약점도 찾아볼 수 있습니다.

예를 들어 2019년에 취약점이 보고되었습니다. vhost/vhost_net 네트워크 백엔드를 사용하는 QEMU-KVM의 가상 인스턴스에 영향을 미치는 취약점이 보고되었습니다. 가상 머신을 강제로 마이그레이션하면 커널이 로그의 범위를 확인하지 않아 더티 페이지의 로그가 오버플로될 수 있습니다.

2015년에 또 다른 QEMU 취약점이 발견되었습니다.이번에는 QEMU의 가상 플로피 제어 취약점이었습니다. 이 취약점은 Venom이라고 불렸으며 QEMU 내에서 코드가 항상 활성화되어 있기 때문에 QEMU가 플로피 드라이브로 구성되지 않은 시스템에도 영향을 미쳤습니다.

QEMU에 영향을 미치는 취약점은 계속 누적될 것입니다. 이러한 취약점은 특히 악의적인데, 이는 QEMU 서비스에 영향을 미치는 모든 취약점이 클라이언트의 가상 머신을 포함하여 QEMU에서 실행되는 가상 머신에도 영향을 미치기 때문입니다.

그렇기 때문에 다른 기술 도구와 마찬가지로 QEMU도 꾸준히 패치해야 합니다. 하지만 가상 환경을 패치하면 가상 환경에서 실행 중인 머신에도 영향을 미치기 때문에 QEMU 패치를 소홀히 할 수 있습니다.

즉, QEMU 패치를 위해 선택한 방법에 따라 패치로 인해 상당한 다운타임이 발생할 수 있으며, 이는 고객이나 다른 이해관계자가 완전히 만족하지 못할 수도 있습니다.

QEMU 패치 가이드

이 섹션에서는 몇 가지 방법으로 QEMU를 패치할 수 있는 방법을 안내해 드립니다. 어떤 접근 방식을 택하느냐에 따라 패치 작업으로 인해 발생하는 위험의 정도와 패치 작업으로 인한 업무 중단의 정도가 결정됩니다.

아래에 나열된 접근 방식은 라이브 패치를 제외하고는 단계가 약간 다를 수 있지만 VMware, Xen, Hyper-V 등 대부분의 가상화 솔루션에 적용할 수 있다는 점에 유의하세요.

빠르고 더럽지만 부주의한 방법

급한 경우에는 별다른 계획 없이 패치를 적용하는 방법을 선택할 수도 있습니다. 이렇게 하면 됩니다:

1. 호스트에 로그인하고 선택한 패키지 관리자를 사용하여 QEMU 및 해당 종속성을 업데이트합니다.

2. 패키지 관리자는 패치를 적용하고 영향을 받는 서비스를 즉시 다시 시작할 수도 있고 그렇지 않을 수도 있으며, 실행 중인 가상 머신을 중지했다가 다시 시작할 수도 있습니다.

3. QEMU를 다시 시작하여 업데이트를 받으면 모든 가상 머신이 효과적으로 중지됩니다.

4. 가상 머신 테넌트 및 이해관계자는 업무가 영향을 받거나 중단되거나 파괴된 것에 대해 불만을 품고 있습니다.

5. 가상 머신이 자동으로 워크로드를 다시 시작하기를 바라며 가상 머신을 다시 시작합니다.

단일 시스템, 단일 사용자 홈 랩을 운영하는 경우 이 방법을 사용할 수 있지만, 라이브 워크로드를 이렇게 엉성한 방식으로 패치하려고 하면 고용주 또는 고객과 심각한 문제를 일으킬 수 있습니다. 간단히 말해, 이런 식으로 QEMU 패치를 시도하면 일주일 내내 자신을 설명하고 자신과 동료의 애플리케이션을 수정하는 데 시간을 보내게 될 것입니다.

시스템 관리자 접근 방식

물론 전문 시스템 관리자라면 더 잘 알고 계실 것입니다. 이 섹션에서는 보다 현명한 QEMU 패치 방법에 대해 설명합니다.

1. 필요한 시간, 영향을 받는 가상 머신 목록, 가상 머신과 상호 작용하는 다른 시스템에 미치는 영향을 포함하여 유지 관리 기간을 계획하는 것부터 시작합니다.

2. 이해 관계자에게 다운타임에 대해 알리고 한 달 정도 후에 작업에 대한 승인을 받습니다. 이 공지의 기간은 취약점의 위험도에 따라 달라지며, 취약점의 위험도가 높을수록 더 빨리 패치를 적용해야 합니다.

3. 유지보수를 시작하기까지 한 달을 기다리시고 그 사이에 해킹을 당하지 않기를 바랍니다.

4. 모든 가상 머신을 정상적으로 종료하고 배포용 패키지 관리자를 사용하여 QEMU에 대한 모든 업데이트를 적용합니다.

5. QEMU를 다시 시작하고 모든 가상 머신을 다시 시작합니다.

6. 모든 것이 계획대로 진행되면 유지 관리 작업을 종료하고 이해 관계자에게 모든 것이 정상으로 돌아왔음을 알립니다.

7. 부팅 프로세스에서 멈춘 가상 머신을 추적하여 문제를 해결하는 등 문제 해결에 며칠을 소비합니다.

위의 접근 방식을 따르면 많은 사람들을 화나게 하지 않고 고장난 애플리케이션과 서비스를 수정하는 데 많은 시간을 낭비하지 않을 수 있습니다. 엔터프라이즈 환경에서는 효과가 있지만 실제로 엔터프라이즈급 접근 방식은 아니며 일부 조건에서는 허용되지 않을 수 있습니다. 특히 이 접근 방식을 사용하면 도중에 예상치 못한 모든 종류의 문제를 발견할 위험이 여전히 존재합니다.

모범 사례, 엔터프라이즈급 접근 방식

인생에서와 마찬가지로 기술에도 항상 장단점이 존재하며, 모범 사례 방법도 마찬가지입니다. 다음 방법은 가장 안전하고 방해가 가장 적은 QEMU 패치 방법이지만, 가장 복잡하고 기술팀의 리소스가 많이 필요한 방법이기도 합니다.

그럼에도 불구하고 QEMU에 의존하는 워크로드를 합리적으로 중단 없이 패치하는 방법을 원한다면 다음 단계를 따르는 것이 좋습니다:

1. 먼저 워크로드가 여러 QEMU 호스트에 의존하도록 하여 가상 머신에 워크로드를 분할하고 노드 중 하나에 장애가 발생할 경우 일종의 이중화 역할을 하도록 합니다.

2. 서로 다른 노드의 가상 머신 간에 고가용성 메커니즘을 구축하여 호스트와 가상 워크로드 모두를 장애로부터 보호합니다.

3. 패치 프로세스가 시작될 때 동일한 서비스의 일부인 서로 다른 고가용성 가상 머신이 동일한 가상화 호스트에 있을 수 없다는 점과 같은 주요 세부 사항을 고려하여 유지 관리 작업을 계획합니다. 이 프로세스를 "오케스트레이션"이라고 합니다.

4. 이해관계자에게 유지보수 작업이 있을 예정이며 성능 저하를 예상해야 하지만 서비스 이용이 불가능하지는 않음을 알립니다.

5. 작업을 진행하기 위한 승인을 요청하고 서비스 중단이 예상되지 않으므로 즉시 이 승인을 받습니다.

6. 첫 번째 QEMU 노드에서 유지 관리 작업을 시작하면 여러 단계로 구성된 유지 관리 작업이 차례로 시작됩니다:

A. 가상 머신을 다른 노드로 라이브 마이그레이션하여 동일한 고가용성 서비스의 가상 머신 노드를 계속 분리하여 유지하면 해당 서비스에서 고가용성을 잃을 수 있습니다.

마이그레이션 명령의 예는 다음과 같습니다:

virsh 마이그레이션 웹1 qemu+ssh://desthost/system

이 작업을 수행하는 방법은 여러 가지가 있으며, 이것은 마이그레이션 명령의 예일 뿐입니다.

B. 필요한 데이터가 네트워크를 통해 전송될 때까지 일정 시간 동안 기다립니다. 마이그레이션을 위해 보조 네트워크 연결을 사용할 수 있거나 사용하는 것이 좋으며, 이 명령으로 제어할 수 있습니다:

virsh 마이그레이션 웹1 qemu://desthost/system tcp://10.0.0.1/

이 마이그레이션 단계는 가상 머신의 수가 많거나 네트워크를 통해 전송해야 하는 마이그레이션된 각 가상 머신에 영향을 받는 RAM/리소스로 인해 상당히 오래 걸릴 수 있습니다.

7. 모든 가상 머신을 마이그레이션한 후에는 QEMU를 중지합니다.
8. 패키지 관리자를 사용하여 QEMU 및 종속성을 업데이트합니다.
9. QEMU를 시작합니다.
10. 가상 머신을 라이브 마이그레이션합니다.
11. 각 가상화 노드에서 6~10단계를 반복합니다.
12. 유지 관리 작업을 종료하고 이해 관계자에게 운영이 정상으로 복구되었음을 알립니다.

가상 머신을 라이브 마이그레이션했으니 중단이 없기를 바라며, 실제로 그럴 일은 없을 것입니다. 하지만 한 가지 주의해야 할 점은 일부 워크로드는 마이그레이션 작업 중 사소한 패킷 손실에도 매우 민감할 수 있으며, 일부 극한 상황에서는 이러한 패킷 손실로 인해 문제가 발생할 수 있다는 점입니다. 이해 관계자가 이러한 위험을 인지하고 각 가상 머신에서 모든 것이 실제로 정상인지 확인하도록 하세요.

라이브 패치는 대안입니다.

세 번째 제안은 워크로드를 안전하게 마이그레이션하는 방법이지만, 리소스를 많이 사용하며 고가용성을 제공하여 다운타임이 없도록 하려면 높은 수준의 기술력이 필요합니다.

다음과 같은 형태의 대안이 있습니다. 턱스케어의 큐뮤케어 라이브 패칭 에이전트. QEMU 인스턴스를 중단시키는 패치를 수행하는 대신, TuxCare의 패치 솔루션은 QEMU가 라이브 및 실행 중인 동안 코드 수정을 적용합니다.

TuxCare에서 QEMU 라이브 패치를 쉽게 시작할 수 있습니다. 한 번의 작업으로 TuxCare 라이브 패치 에이전트를 설치하고 적절한 라이선스를 추가하기만 하면 됩니다. Ansible 또는 다른 자동화 도구를 사용하여 TuxCare 에이전트를 배포하면 여러 서버에 걸쳐 설치 속도를 높일 수 있습니다.

설치가 완료되면 TuxCare의 라이브 패치 도구가 QEMU에서 실행 중인 가상 머신을 중단시키지 않고 QEMU 인스턴스를 지속적으로 패치합니다.

결론

QEMU 인스턴스를 패치할 때 사용할 수 있는 다양한 옵션에 대해 자세히 살펴보았습니다. 첫 번째 옵션은 테스트 또는 실험용 시스템을 패치하는 경우가 아니라면 실제로 사용할 수 없습니다. 리소스와 워크로드의 복잡성에 따라 두 번째 또는 세 번째 옵션을 선택할 수 있으며, 대부분의 심각한 엔터프라이즈 워크로드는 아마도 세 번째 옵션을 선택할 것입니다.

마지막 옵션인 TuxCare의 라이브 패치는 문제가 될 수 있는 많은 단계를 제거하고 전체 프로세스를 단순화하여 다른 QEMU 패치 방법과 비교할 수 없을 정도로 간소화합니다. 말할 필요도 없이 라이브 QEMU 패치는 고려할 가치가 있습니다.

어떤 패치 옵션을 선택하든, 패치는 SecOps의 중요한 부분이며 QEMU를 포함하여 프로세스의 모든 서비스에 영향을 미치는 패치를 철저하게 수행해야 한다는 점은 변함없습니다.