7-3-8. Clusters Are Living, Breathing Creatures

Once you get a cluster into production, you’ll find that it takes on a life of its own. Elasticsearch works hard to make clusters self-sufficient and just work. But a cluster still requires routine care and feeding, such as routine backups and upgrades.

제품에 cluster를 적용하면, 저절로 운영되는 것을 볼 수 있다. cluster가 혼자서 그냥 동작 할 수 있도록, Elasticsearch는 최선을 다해 작동한다. 그러나, cluster는 여전히 일상적인 백업이나 업그레이드 같은 일반적인 관리를 필요로 한다.

Elasticsearch releases new versions with bug fixes and performance enhancements at a very fast pace, and it is always a good idea to keep your cluster current. Similarly, Lucene continues to find new and exciting bugs in the JVM itself, which means you should always try to keep your JVM up-to-date.

Elasticsearch는 매우 빠른 속도로, 버그 수정과 성능 향상이 된 새로운 버전을 출시하고 있다. 따라서, cluster를 항상 최신 버전으로 유지하는 것이 좋다. 마찬가지로, Lucene은 JVM 자체에서 새롭고 흥미로운 버그를 계속 발견하고 있다. 이것은 JVM을 항상 최신으로 유지해야 한다는 것을 의미한다.

This means it is a good idea to have a standardized, routine way to perform rolling restarts and upgrades in your cluster. Upgrading should be a routine process, rather than a once-yearly fiasco that requires countless hours of precise planning.

즉, cluster의 규칙적인 재 시작과 업그레이드를 수행하는, 표준적이고 일상적인 방법을 가지는 것이 좋다. 업그레이드는, 정확한 계획을 위해 수많은 시간을 필요로 하는 연례 행사라기 보다는, 일상적인 프로세스이어야 한다.

Similarly, it is important to have disaster recovery plans in place. Take frequent snapshots of your cluster—and periodically test those snapshots by performing a real recovery! It is all too common for organizations to make routine backups but never test their recovery strategy. Often you’ll find a glaring deficiency the first time you perform a real recovery (such as users being unaware of which drive to mount). It’s better to work these bugs out of your process with routine testing, rather than at 3 a.m. when there is a crisis.

마찬가지로, 준비된 재해 복구 계획을 준비하는 것도 중요하다. 자주 cluster의 snapshot을 생성하고, 주기적으로 실제 복구를 수행하여, 해당 snapshot을 테스트 해야 한다. 조직이 일상적인 백업을 만들지만, 절대로 그들의 복구 전략을 테스트하지 않는 것은 너무나 흔한 일이다. 명백한 결함을 발견하면, 실제 복구를 처음으로(마운트할 드라이브를 알지 못하는 사용자처럼) 실행할 것이다. 위기에 처한 새벽 3시보다는 일상적인 테스트로 프로세스의 버그를 찾아내는 것이 더 낫다.