새로운 프로즌 티어에서 검색 성능을 기존 Elasticsearch 데이터 티어와 비교하는 방법과 프로즌 티어에서 훨씬 더 많은 양의 데이터를 저장하고 검색하는 방법에 대해 알아보세요.

blog-banner-tree-icicles.jpg

blog-thumb-tree-icicles.jpg

Querying a petabyte of cloud storage in 10 minutes

10분 이내에 페타바이트 규모의 클라우드 저장 공간 쿼리 작업

콜드 티어가 Elasticsearch 7.11에서 정식 버전으로 제공됩니다. 이 기능이 완벽하게 작동하는지 확인하기 위해 어떤 테스트를 수행했는지 알아보세요.

Elasticsearch 7.10에서 베타 버전으로 제공되었던 검색 가능한 스냅샷의 <a href="/guide/en/elasticsearch/reference/7.11/searchable-snapshots.html">콜드 티어</a>가 이제 <a href="/kr/blog/whats-new-elastic-7-11-0-searchable-snapshots-schema-on-read">Elasticsearch 7.11에서 정식 버전으로 출시</a>되었습니다. 이 새로운 데이터 티어를 사용하면 핫 티어 및 웜 티어와 동일한 수준의 안정성과 중복성을 유지하면서 웜 티어와 비교하여 클러스터 저장 공간을 최대 50% 절감할 수 있습니다.&nbsp;
이 블로그에서는 Elastic에서 진행했던 시나리오를 함께 살펴보면서 콜드 티어가 대규모에서도 원활하게 작동하는지 확인하고, Elastic에서 솔루션의 품질과 안정성을 얼마나 중요하게 생각하는지 짚어봅니다.
<h2>콜드 티어 요약</h2>콜드 티어는 복제본 샤드의 필요성을 없애고 대신 스냅샷(AWS S3, Google Storage 또는 Microsoft Azure Storage와 같은 객체 스토어에 저장)을 사용하여 필요한 복원력을 제공함으로써 기본 샤드만 로컬 저장 공간에 보관하여 클러스터 비용을 절감합니다. 로컬 저장 공간은 기본적으로 리포지토리에 있는 스냅샷 데이터의 캐시된 버전처럼 작동합니다.
콜드 노드 또는 로컬 저장 공간에 오류가 발생하는 경우 검색 가능한 스냅샷에서 자동으로 복구를 수행하며 해당 샤드를 다른 노드로 리밸런싱합니다.
<a href="/guide/en/elasticsearch/reference/7.11/restart-cluster.html#restart-cluster-full">전체 클러스터</a> 또는 <a href="/guide/en/elasticsearch/reference/7.11/restart-cluster.html#restart-cluster-rolling">롤링</a> 재시작(또는 노드 재부팅)의 경우 로컬 저장 공간이 지속적으로 유지되며 로컬에서 사용 가능한 데이터는 스냅샷에서 다시 다운로드되지 않으므로, 정상 클러스터로 돌아가는 데 필요한 시간을 최소화할 수 있을 뿐만 아니라 불필요한 네트워크 비용도 방지할 수 있습니다.
운영 규모가 확장되어도 이 모든 기능이 정상적으로 작동하는지 확인하기 위해 다음 요소를 사용한 세 가지 시나리오에 검증 노력을 집중했습니다.
<ul>
	<li>Elasticsearch 노드 5개(16G 힙)</li>
	<li>RAID-0 구성의 2TB 마그네틱 디스크 6개</li>
	<li>각각 5개의 샤드가 있는 10개의 인덱스에 분산된 <a href="https://github.com/elastic/rally-eventdata-track#elasticlogs_bulk_source">로깅 데이터</a>가 하나의 세그먼트로 강제 병합된 5TB 스냅샷(강제 병합은 읽기 액세스를 위한 인덱스를 최적화하고 장애 발생 시 복원해야 하는 파일 수를 줄임)</li>
</ul><h2>시나리오 1: 전체 클러스터 재시작</h2>검증한 첫 번째 시나리오는 <a href="/guide/en/elasticsearch/reference/7.11/restart-cluster.html#restart-cluster-full">전체 클러스터 재시작</a>이었습니다. 이를 확인하기 위해 다음 단계를 수행했습니다.
<ol>
	<li>5TB의 검색 가능한 스냅샷을 마운트하고 로컬 캐시가 완전히 사전 워밍업될 때까지 기다립니다(페이즈 0).</li>
	<li><a href="/guide/en/elasticsearch/reference/7.11/restart-cluster.html#restart-cluster-full">전체 클러스터 재시작 지침</a>에 따라 전체 클러스터 재시작을 실행합니다.</li>
	<li>할당을 다시 활성화한 후 클러스터가 다음을 완료하는 데 걸리는 시간을 측정합니다.
	<ol>
		<li style="list-style-type: lower-alpha;">정상 상태로 전환</li>
		<li style="list-style-type: lower-alpha;">모든 백그라운드 다운로드를 완료하여 캐시 사전 워밍업</li>
	</ol></li>
	<li>3단계 이후에 추가로 샤드 리밸런싱이 일어나지 않도록 해야 합니다.</li>
</ol>Elasticsearch 7.11에 새롭게 도입된 영구 계층 덕분에 모든 노드를 시작하고 할당을 재활성화한 후에는 클러스터가 즉시 정상 상태가 되고 백그라운드 다운로드가 발생하지 않았습니다.
아래 그래프를 보면 마운트 중(페이즈 0)과 전체 클러스터 재시작 및 할당 재활성화 후(페이즈 1, 추가 네트워크 트래픽 없음)의 누적 네트워크 트래픽을 확인할 수 있습니다.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt35678fd5b13689c8/60302e8a52b0701387ca3379/blog-cold-tier-testing-1.png" data-sys-asset-uid="blt35678fd5b13689c8" alt="" style="display: block; margin: auto;">
<h2>시나리오 2: 롤링 재시작</h2>검증한 두 번째 시나리오는 일반적인 <a href="/guide/en/elasticsearch/reference/7.11/restart-cluster.html#restart-cluster-rolling">롤링 클러스터 재시작</a> 사례였습니다.
실험 방식은 전체 클러스터 재시작과 비슷했습니다.
<ol>
	<li>5TB의 검색 가능한 스냅샷을 마운트하고 로컬 캐시가 완전히 사전 워밍업될 때까지 기다립니다.</li>
	<li>각 노드를 중지하기 전에 샤드 할당을 비활성화하여 첫 번째 노드에 대한 <a href="/guide/en/elasticsearch/reference/7.11/restart-cluster.html#restart-cluster-rolling">롤링 재시작</a> 절차를 실행합니다.</li>
	<li>노드를 시작하고 샤드 할당을 다시 활성화한 후, 정상 상태로 전환되는 데 걸리는 시간을 측정합니다. 영구 캐시 덕분에 빠르게 전환될 것으로 예상했습니다. 또한 재시작 후 불필요한 백그라운드 다운로드가 발생하지 않도록 했습니다.</li>
	<li>클러스터의 다른 모든 노드에 대해 2단계와 3단계를 반복합니다.</li>
</ol>이 실험 또한 성공적이었습니다. Elasticsearch 7.11에 도입된 영구 캐시 덕분에 거의 즉각적으로 정상 상태로 전환되었으며 스냅샷에서 추가적인 백그라운드 다운로드가 발생하지 않았습니다.&nbsp;
<h2>시나리오 3: 노드 장애</h2>마지막으로 노드 하나에 장애가 발생할 때 적절한 조치가 이루어지는지 확인하고자 다음 실험을 수행했습니다.
<ol>
	<li>5TB의 검색 가능한 스냅샷을 마운트하고 로컬 캐시가 완전히 사전 워밍업될 때까지 기다립니다(페이즈 0).</li>
	<li>Elasticsearch 노드 5개 중 하나(node-1)를 <code>SIGKILL</code>을 사용하여 종료하고 클러스터가 다시 정상 상태로 바뀔 때까지 기다립니다(페이즈 1).
	<ol>
		<li style="list-style-type: lower-alpha;">종료된 노드에 호스팅된 샤드로부터 데이터를 수신하는 것과 백그라운드 다운로드가 관련이 있는지 확인합니다.</li>
		<li style="list-style-type: lower-alpha;">정상 상태로 전환된 후에는 추가적인 리밸런싱이 수행되어서는 안 됩니다.</li>
	</ol></li>
	<li>장애가 발생한 노드를 다시 시작합니다(페이즈 2).
	<ol>
		<li style="list-style-type: lower-alpha;">나머지 노드 4개에 모든 데이터가 있으므로 피어 복구만 수행하여 샤드를 리밸런싱해야 합니다.</li>
		<li style="list-style-type: lower-alpha;">클러스터가 정상 상태로 전환되어야 합니다.</li>
	</ol></li>
</ol>이번 실험도 성공적이었습니다. node-1이 종료된 후, 나머지 노드가 종료된 노드에 호스팅된 샤드를 검색 가능한 스냅샷에서 자동으로 복원했습니다.
노드별 네트워크 트래픽을 시각화한 아래 차트에서 볼 수 있듯이, 클러스터가 정상 상태로 전환된 후에는 추가적인 리밸런싱이 발생하지 않았습니다.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt01e78a88fe879418/60302ea42568577267da67a3/blog-cold-tier-testing-2.png" data-sys-asset-uid="blt01e78a88fe879418" alt="" style="display: block; margin: auto;">
누락된 노드를 되살린 후에는 피어 복구가 시작되었고 균등하게 분산된 클러스터를 만들기 위해 필요한 양만큼의 샤드를 node-1이 다시 호스팅하게 되었습니다.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt123c74ca4a9ccb9c/60302eb5b6ea0f77f34edd6a/blog-cold-tier-testing-3.png" data-sys-asset-uid="blt123c74ca4a9ccb9c" alt="" style="display: block; margin: auto;">
<h2>지금 바로 시작</h2>지금까지 기능 검증을 수행해 보았는데요. 흥미로운 시간이 되셨길 바랍니다!
검색 가능한 스냅샷을 시작하고 콜드 티어에 데이터를 저장하려면 <a href="https://info.elastic.co/elasticsearch-service-trial-30d.html">Elastic Cloud</a>에서 클러스터를 구동하거나 Elastic Stack의 <a href="/kr/downloads/">최신 버전을 설치</a>하세요. 이미 Elasticsearch를 실행 중이신가요? 그렇다면 클러스터를 7.11로 업그레이드하신 후 다시 사용해 보세요. 자세한 내용은 <a href="/guide/en/elasticsearch/reference/7.11/data-tiers.html">데이터 티어</a> 및 <a href="/guide/en/elasticsearch/reference/7.11/searchable-snapshots-apis.html">검색 가능한 스냅샷</a> 설명서에서 확인하실 수 있습니다.

blog-banner-ice-crystals.jpg

blog-thumb-ice-crystals.jpg

Testing the new Elasticsearch cold tier of searchable snapshots at scale

검색 가능한 스냅샷의 새로운 Elasticsearch 콜드 티어를 대규모 운영 환경에서 테스트

새로운 Elastic Stack 기능을 테스트하면서 특정 Linux 커널의 SSD 디스크에 영향을 미치는 Linux 커널 버그를 발견했습니다. 긴밀한 두 파트너 Google Cloud 및 Canonical과 함께 얼마나 훌륭하게 협력하며 조사가 진행되었는지 알아보세요.

Elastic은 끊임없이 새로운 기능을 혁신하고 출시하고 있습니다.&nbsp;새로운 기능을 출시할 때는 반드시 테스트를 거쳐 견고하며 안정적으로 작동하도록 작업 중입니다. 때로는 버그나 다른 문제를 발견하기도 합니다.
새로운 기능을 테스트하면서 특정 Linux 커널의 SSD 디스크에 영향을 미치는 Linux 커널 버그를 발견했습니다. 이 블로그 포스팅에서는 그 조사 작업과 긴밀한 두 파트너 Google Cloud 및 Canonical과 함께 얼마나 훌륭하게 협력하며 조사가 진행되었는지에 대한 이야기를 다룹니다.
이 조사는 <a href="#conclusion">이 문제를 해결하는</a> 새로운 Ubuntu 커널 출시로 이어졌습니다.
 <h2>시작 경위</h2>앞서 2019년 2월에 <a href="https://github.com/elastic/rally-eventdata-track/blob/master/eventdata/challenges/bulk-update.json">업데이트가 많은 수집 작업</a>을 이용해 표준 <a href="https://esrally.readthedocs.io/en/stable/">Elasticsearch 벤치마킹 도구인 Rally</a>로 <a href="/guide/en/elasticsearch/reference/7.8/xpack-ccr.html">클러스터 간 복제(CCR))</a>에 대한 <a href="/kr/blog/benchmarking-elasticsearch-cross-cluster-replication">10일 간의 안정성 테스트</a>를 실행했습니다. Elasticsearch 버전은 (당시로서는) 미출시 7.0 브랜치의 가장 최신 커밋이었습니다. 며칠이 지난 후 테스트는 다음과 같은 Elasticsearch 로그 보고와 함께 실패했습니다.
<pre class="prettyprint">… 
Caused by: org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?)
</pre>인덱스 손상을 탐색하게 되면[<a href="#ref1" id="1">1</a>], Elasticsearch는 복제본으로부터 복구를 시도하게 됩니다. 많은 경우에 복구는 원활하게 이루어지며, 사용자가 로그를 검토하지 않는 한 손상은 눈치채지 못한 상태로 넘어가게 됩니다. 복제본이 제공하는 중복을 통해서도 특정 상황에서는 데이터 손실이 가능합니다. 따라서 왜 손상이 발생하고 있으며 어떻게 그 문제를 해결할 수 있는지를 이해해보고자 했습니다.
처음에는 새로운 Elasticsearch 기능인 <a href="/guide/en/elasticsearch/reference/7.8/xpack-ccr.html">CCR</a>/<a href="https://github.com/elastic/elasticsearch/issues/29530">일시 삭제</a>가 문제를 일으키고 있다고 생각했습니다. 그러나 이러한 의심은 단일 클러스터를 사용하고 CCR/일시 삭제 기능을 비활성화하여 인덱스 손상을 재현할 수 있다는 것을 알게 되자 곧 사라졌습니다. 추가로 리서치를 진행한 후, CCR/일시 삭제 베타 출시에 선행하는 Elasticsearch의 이전 버전에서 그 문제를 재현할 수 있다는 것을 알게 되었습니다. 이것은 CCR/일시 삭제가 인덱스 손상의 원인이 아니라는 것을 보여줍니다.
그러나 우리는 인덱스 손상이라는 결과를 낳은 테스트와 리서치가 Google Cloud Platform(GCP)에서 <a href="https://console.cloud.google.com/marketplace/details/ubuntu-os-cloud/ubuntu-xenial">Canonical Ubuntu Xenial 이미지</a>와 <code>4.15-0-*-gcp</code> 커널의 <a href="https://cloud.google.com/compute/docs/disks/local-ssd">로컬 SSD</a>를 사용해 실시되었었고, 동일한 운영 체제와 SSD 디스크(4.13 또는 4.15 <a href="https://wiki.ubuntu.com/Kernel/LTSEnablementStack">HWE 커널</a> 어느 쪽이든)를 갖춘 베어 메탈 환경에서는 문제를 재현할 수 없었다는 것에 주목했습니다.
그 문제와 그 영향에 대한 더 많은 데이터를 얻기 위해 즉시 Elastic Cloud로 주의를 돌렸습니다. 병렬 작업 스트림에서 다른 파일 시스템을 테스트하고, RAID를 비활성화하고, 마침내 보다 새로운 메인라인 커널을 사용함으로써 수많은 의심을 제거해나갔지만, 이 중 어느 것도 손상을 완전히 없애지는 못했습니다.
 <h2>Google Cloud 지원팀과 함께 더 심층적인 조사 진행</h2>이 시점에서 우리는 재현 작업을 손쉽게 하기 위한 <a href="https://gist.github.com/dliappis/54a9eedd5a272cf13b49ecaa85f87c7f">간단한 재현 스크립트</a>를 생성했고, 파트너인 Google이 참여한 가운데 환경 문제에 대한 좀더 심층적인 조사에 착수했습니다.
GCP 지원팀은 제공된 스크립트를 사용해 문제를 안정적으로 재현할 수 있었습니다. 그 예시 오류 메시지는 다음과 같습니다.
<pre class="prettyprint">org.apache.lucene.index.CorruptIndexException: codec footer mismatch (file 
truncated?): actual footer=-2016340526 vs expected footer=-1071082520 
(resource=BufferedChecksumIndexInput(MMapIndexInput(path="/home/dl/es/data/nodes/0/indices/IF1vmFH6RY-MZuNfx2IO4w/0/index/_iya_1e_Lucene80_0.dvd")))
</pre>문제가 발생하는 시간 범위 동안, IO 처리량은 16,000 IOPS로 초당 160MB를 넘어갔습니다. 이러한 관측은 여러 테스트에 걸쳐 일관되게 나타났습니다. Elasticsearch(기본 설정)는 <a href="/guide/en/elasticsearch/reference/7.8/index-modules-store.html#file-system">일부 저장 공간의 경우 메모리 매핑된 파일</a>을 사용하기 때문에, 일부 파일 액세스가 더 많은 주요 페이지 폴트를 야기하는 원인이며, 디스크에 대한 IO 작업의 증가로 이어지고, 결국 문제를 촉발하게 되는 것이라는 생각이 들었습니다. 페이지 폴트의 발생을 줄이기 위해, 우리는 GCP 인스턴스의 메모리를 32GB에서 52GB로 늘려보았습니다. 메모리가 늘어나자마자, 문제는 더 이상 발생하지 않았고 IO 처리량은 4000 IOPS로 초당 50MB였습니다.&nbsp;
GCP와 베어 메탈 환경 간의 다른 점을 관측했을 때 첫 번째 돌파구가 생겼습니다. GCP 커널은 <a href="https://lwn.net/Articles/738449/">멀티 큐 블록 레이어</a>(blk_mq)라고 하는 기능을 활성화했고, 베어 메탈 커널은 그렇지 않았습니다[<a href="#ref2" id="2">2</a>]. 문제가 더 복잡해진 것은, 특정 버전 이후에[<a href="#ref3" id="3">3</a>] 더 이상 커널 옵션을 통해 Ubuntu Linux -gcp 이미지에서 blk_mq[<a href="#ref4" id="4">4</a>]를 비활성화할 수 없게 되었기 때문입니다. GCP 지원팀은 GCP의 Ubuntu 이미지를 내보내서 멀티 큐 SCSI[<a href="#ref5" id="5">5</a>]를 활성화하는 VIRTIO_SCSI_MULTIQUEUE guestOS 기능 없이 그것을 다시 생성함으로써 blk_mq를 비활성화하는 방법을 보여주었습니다.
두 번째 돌파구는 베어 메탈에서의 손상을 재현할 수 있게 된 것이었습니다. 즉, 보다 이전 커널인 <code>4.13.0-38-generic</code>을 사용해서도 <code>blk_mq</code>를 명시적으로 활성화함으로써만 손상을 재현할 수 있게 되었습니다. 우리는 또한 NVMe 디스크에서는 이러한 문제가 나타나지 않는다는 것을 확인했습니다.
이 시점에서 다음 두 가지 조건이 모두 부합될 때 손상이 발생한다는 것을 알게 되었습니다.
<ul>
	<li>SCSI 인터페이스를 사용하는 SSD 드라이브(NVMe 디스크는 영향을 받지 않음)</li>
	<li>blk_mq 활성화</li>
</ul>GCP 지원팀은 (NVMe 디스크만 사용한다는 것 이외에) 두 가지 추가 해결 방법을 공유해 주었습니다. 인스턴스 메모리를 늘리거나 멀티 큐 SCSI를 비활성화한 사용자 정의 인스턴스 이미지를 생성하는 것입니다.
 <h2>Canonical의 동참</h2>몇 가지 해결 방법을 찾았지만, 아직 만족스럽지는 않았습니다.
<ul>
	<li>문제는 GCP의 Ubuntu 이미지에만 특정한 것이 아니었습니다. 베어 메탈에서도 발생했습니다.</li>
	<li>우리는 어느 커널 커밋이 문제를 도입하는지 알 수 없었습니다.</li>
	<li>보다 새로운 커널에서 수정이 이미 이루어진 것인지도 알 수 없었습니다.</li>
</ul>이러한 점들을 해결하기 위해 우리는 파트너인 Canonical에게 요청하여 좀 더 심층적으로 조사해보았습니다.
Canonical은 <a href="https://gist.github.com/dliappis/54a9eedd5a272cf13b49ecaa85f87c7f">Elastic 재현 스크립트</a>를 이용해 방대한 테스트 작업을 시작했고, 먼저 손상이 SSD 드라이브를 사용하는 Ubuntu 메인라인 커널 &gt;=5.0에서는 발생하지 않는다는 것을 확인했습니다(아무 것도 사용하지 않거나 mq-deadline <a href="https://wiki.ubuntu.com/Kernel/Reference/IOSchedulers">멀티 큐 I/O 스케줄러 사용</a>).
다음 단계는 커널 버전을 다시 뒤로 돌려 손상을 나타내는 커널과 그렇지 않은 커널 간의 최소 변화량을 찾아내는 것이었습니다. 여러 병행 테스트 환경을 사용해(전체 테스트 실행이 최대 5일까지 걸릴 수 있으므로), Canonical은 <a href="https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19.8/">4.19.8</a>이 손상 수정이 포함되는 최초의 Ubuntu 메인라인 커널이라는 것을 찾아냈습니다[<a href="#ref6" id="6">6</a>].
4.15.0 커널과 그 파생 개체에 대한 백포트 누락은 Canonical의 버그 트래커의 <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739">LP#1848739</a>에 설명되어 있습니다. 더 자세한 사항은 <a href="https://lwn.net/Articles/774440/">이 포스팅</a>과 <a href="https://bugzilla.kernel.org/show_bug.cgi?id=201685">kernel.org 버그</a>에서 찾아보실 수 있습니다.
Elastic과 Canonical이 모든 필요한 백포트가 포함된 패치가 적용된 GCP 커널이 <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/9">문제를 수정</a>한다고 확인한 후에, 이를 Ubuntu 4.15.0 메인 커널로 <a href="https://lists.ubuntu.com/archives/kernel-team/2019-December/106382.html">병합했고</a> 결과적으로 모든 파생 커널(-gcp 포함)에서 문제가 수정되었습니다.
 <h2 id="conclusion">결론</h2>Elastic은 세 개의 주요 솔루션 각각을 개선하는 새로운 Elastic Stack 기능을 개발하고자 최선의 노력을 기울이고 있습니다. 이러한 노력은 사용자가 아무 걱정도 할 필요가 없도록 언제나 깨어서 작업하는 대단히 뛰어난 엔지니어 및 파트너들의 지원을 받아 이루어집니다. 테스트 중에 문제를 발견하는 경우, Elastic과 그 긴밀한 파트너 네트워크는 사용자에게 가능한 최상의 환경을 제공하기 위해 모든 것을 샅샅이 조사하여 해결합니다.
Google 및 Canonical과의 긴밀한 협조를 통해, 우리는 문제의 근본 원인을 파악할 수 있었고, 이는 다음의 <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739">수정판</a> HWE Ubuntu 커널 출시로 이어졌습니다.
<ul>
	<li>AWS: <a href="https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-aws/linux-aws_4.15.0-1061.65/changelog">2020년 2월 21일</a>에 출시된 <code>linux-aws - 4.15.0-1061.65</code>부터</li>
	<li>Azure: <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/12">2020년 1월 6일</a>에 출시된 <code>linux-azure - 4.15.0-1066.71</code>부터</li>
	<li>GCP: <a href="https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-gcp/linux-gcp_4.15.0-1053.57/changelog">2020년 2월 5일</a>에 출시된 <code>linux-gcp - 4.15.0-1053.57</code>부터</li>
	<li>일반: <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/15">2020년 2월 17일</a>에 출시된 <code>linux - 4.15.0-88.88</code>부터</li>
</ul>위의 버전이나 그 이후 버전을 사용하시면 SSD 디스크가 활성화된 SCSI blk-mq와 함께 사용되는 경우 손상을 피하게 됩니다.
이 데이터 손상으로부터 현재 환경이 보호되고 있는지 여부에 대해 걱정하고 싶지 않으시면, 저희 <a href="/kr/elasticsearch/service">Elastic Cloud</a>를 사용해 보세요. 저희 사용자는 이미 보호를 받고 계십니다.
 <h2>각주</h2>[<a href="#1" id="ref1">1</a>] Elasticsearch는 비용이 많이 드는 작업이기 때문에 체크섬을 늘 확인하지는 않습니다. 샤드 재배치와 같은 특정 행위가 체크섬 확인을 좀더 빈번하게 촉발할 수는 있습니다. 또는 스냅샷을 찍는 동안 이러한 행위가 원인이 되는 것처럼 밑에서 조용히 손상이 나타나기도 합니다.
[<a href="#2" id="ref2">2</a>] SCSI 또는 기기 매퍼 디스크에 대해 blk_mq가 사용 중인지 여부를 확인하려면 <code>cat /sys/module/{scsi_mod,dm_mod}/parameters/use_blk_mq</code>를 이용하세요.
[<a href="#3" id="ref3">3</a>] <a href="https://patchwork.kernel.org/patch/10198305">https://patchwork.kernel.org/patch/10198305</a> blk_mq가 SCSI 기기에 강제 적용되고 커널 옵션을 통해 비활성화될 수 없게 된 후. 이 패치는 Ubuntu <a href="https://launchpad.net/ubuntu/+source/linux-gcp/4.15.0-1010.10~16.04.1">linux-gcp</a>에서 백포트되었습니다.
[<a href="#4" id="ref4">4</a>] blk_mq를 비활성화하려면 grub을 통해 다음 매개변수를 커널로 보내야 합니다. <code>GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=N dm_mod.use_blk_mq=N"</code>. 이러한 옵션을 N으로 설정함으로써 활성화가 가능하지만 [3]에 유의하세요.
[<a href="#5" id="ref5">5</a>] Ubuntu 이미지를 다시 생성함으로써 VIRTIO_SCSI_MULTIQUEUE guestOS 기능을 비활성화하는 예시 gcloud 명령어:
<pre># gcloud compute images export --image-project ubuntu-os-cloud --image-family ubuntu-1604-lts --destination-uri=gs://YOUR_BUCKET/ubuntu_16.04.tar.gz 
# gcloud compute images create ubuntu-1604-test --family ubuntu-1604-lts --source-uri=gs://YOUR_BUCKET/ubuntu_16.04.tar.gz
</pre>[<a href="#6" id="ref6">6</a>] 백포트
<pre> - blk-mq: quiesce queue during switching io sched and updating nr_requests 
 - blk-mq: move hctx lock/unlock into a helper 
 - blk-mq: factor out a few helpers from __blk_mq_try_issue_directly 
 - blk-mq: improve DM's blk-mq IO merging via blk_insert_cloned_request feedback 
 - dm mpath: fix missing call of path selector type-&gt;end_io 
 - blk-mq-sched: remove unused 'can_block' arg from blk_mq_sched_insert_request 
 - blk-mq: don't dispatch request in blk_mq_request_direct_issue if queue is busy 
 - blk-mq: introduce BLK_STS_DEV_RESOURCE 
 - blk-mq: Rename blk_mq_request_direct_issue() into 
 blk_mq_request_issue_directly() 
 - blk-mq: don't queue more if we get a busy return 
 - blk-mq: dequeue request one by one from sw queue if hctx is busy 
 - blk-mq: issue directly if hw queue isn't busy in case of 'none' 
 - blk-mq: fix corruption with direct issue 
 - blk-mq: fail the request in case issue failure 
 - blk-mq: punt failed direct issue to dispatch list
</pre>

cloud-gcp-region-blog-banner.png

blog-thumb-cloud-gcp-region.png

Canonical, Elastic, and Google team up to prevent data corruption in Linux

Linux에서의 데이터 손상을 예방하기 위한 Canonical, Elastic, Google 팀의 공동 작업

일반적인 Linux 시스템에서 기본 TRIM 설정을 사용하여 SSD 드라이브에서 Elasticsearch 실행시 성능에 미치는 부정적인 영향을 최소화하는 방법

AUTHOR

의 글 Dimitrios Liappis

10분 이내에 페타바이트 규모의 클라우드 저장 공간 쿼리 작업

검색 가능한 스냅샷의 새로운 Elasticsearch 콜드 티어를 대규모 운영 환경에서 테스트

Linux에서의 데이터 손상을 예방하기 위한 Canonical, Elastic, Google 팀의 공동 작업

Elasticsearch에 Trim이 되어 있나요?

Elastic Cloud 무료 체험판 등록하기

제품과 솔루션

회사 소개

리소스

솔루션

Elastic (ELK) Stack

새 소식

AUTHOR

의 글 Dimitrios Liappis

10분 이내에 페타바이트 규모의 클라우드 저장 공간 쿼리 작업

검색 가능한 스냅샷의 새로운 Elasticsearch 콜드 티어를 대규모 운영 환경에서 테스트

Linux에서의 데이터 손상을 예방하기 위한 Canonical, Elastic, Google 팀의 공동 작업

Elasticsearch에 Trim이 되어 있나요?

Elastic Cloud 무료 체험판 등록하기

회사 소개

리소스