Difference between revisions of "Translations:ReleaseNotes/Kilo/38/ko"

Latest revision as of 18:01, 3 May 2015

Information about message (contribute)

This message has no documentation. If you know where or how this message is used, you can help other translators by adding documentation to this message.

Message definition (ReleaseNotes/Kilo)

* Evacuate recovery code has the potential to destroy data. On nova-compute startup, instances reported by the hypervisor are examined to see if they have moved (i.e. been evacuated) from the current host during the outage. If the determination is made that they were, then they are destroyed locally. This has the potential to choose incorrectly and destroy instances unexpectedly. On libvirt-like nodes, this can be triggered by changing the system hostname. On vmware-like nodes, this can be triggered by attempting to manage a single vcenter deployment from two different hosts (with different hostnames). This will be fixed properly in Liberty, but for now deployments that wish to disable this behavior as a preventive measure can set workarounds.destroy_after_evacuate=False. NOTE: This is not a regression and has been a flaw in the design of the evacuate feature since its introduction. There is no easy fix for this, hence this workaround to limit the potential for damage. The proposed fix in liberty is here: https://review.openstack.org/#/c/161444/.

* Evacuate recovery code has the potential to destroy data. On nova-compute startup, instances reported by the hypervisor are examined to see if they have moved (i.e. been evacuated) from the current host during the outage. If the determination is made that they were, then they are destroyed locally. This has the potential to choose incorrectly and destroy instances unexpectedly. On libvirt-like nodes, this can be triggered by changing the system hostname. On vmware-like nodes, this can be triggered by attempting to manage a single vcenter deployment from two different hosts (with different hostnames). This will be fixed properly in Liberty, but for now deployments that wish to disable this behavior as a preventive measure can set workarounds.destroy_after_evacuate=False. NOTE: This is not a regression and has been a flaw in the design of the evacuate feature since its introduction. There is no easy fix for this, hence this workaround to limit the potential for damage. The proposed fix in liberty is here: https://review.openstack.org/#/c/161444/.

Translation* Evacuate 복구 코드가 (VM 디스크) 데이터를 파괴할 가능성이 있습니다. nova-compute 시작시, 하이퍼바이저로부터 보고된 인스턴스가 중단되어 있는 동안 현 호스트로부터 이동되었는지 (즉, evacuate 되었는지)를 확인합니다. 만약 이동되었다고 판단되는 경우, 해당 VM들은 해당 지역에서 삭제됩니다. 이때 잘못 선택되어 인스턴스들이 예기치않게 파괴할 가능성이 있습니다. libvert 계열 노드들에는 호스트 이름을 변경함으로써 발생합니다. vmware 계열 노드들에서는 두 개의 다른 호스트에서 (다른 호스트 이름을 가진 상태) vcenter 배포를 단일로 관리하려할때 발생합니다. 해당 이슈는 Liberty에서 수정될 예정이지만, 현재는 해당 기능을 배포 환경에서 비활성화하고자 할 경우 예방적인 차원에서 workarounds.destroy_after_evacuate=False로 설정하여 가능합니다. 참고: 이는 회귀가 아닌 초기부터의 evacuate 기능 설계에 대한 결함으로 판명되었습니다. 이에 대한 쉬운 문제 해결이 없기에, 해당 대처법은 손상에 대한 가능성을 제한하는 것입니다. liberty에서 제안된 수정은 여기서 확인 가능합니다: https://review.openstack.org/#/c/161444/.

Evacuate 복구 코드가 (VM 디스크) 데이터를 파괴할 가능성이 있습니다. nova-compute 시작시, 하이퍼바이저로부터 보고된 인스턴스가 중단되어 있는 동안 현 호스트로부터 이동되었는지 (즉, evacuate 되었는지)를 확인합니다. 만약 이동되었다고 판단되는 경우, 해당 VM들은 해당 지역에서 삭제됩니다. 이때 잘못 선택되어 인스턴스들이 예기치않게 파괴할 가능성이 있습니다. libvert 계열 노드들에는 호스트 이름을 변경함으로써 발생합니다. vmware 계열 노드들에서는 두 개의 다른 호스트에서 (다른 호스트 이름을 가진 상태) vcenter 배포를 단일로 관리하려할때 발생합니다. 해당 이슈는 Liberty에서 수정될 예정이지만, 현재는 해당 기능을 배포 환경에서 비활성화하고자 할 경우 예방적인 차원에서 workarounds.destroy_after_evacuate=False로 설정하여 가능합니다. 참고: 이는 회귀가 아닌 초기부터의 evacuate 기능 설계에 대한 결함으로 판명되었습니다. 이에 대한 쉬운 문제 해결이 없기에, 해당 대처법은 손상에 대한 가능성을 제한하는 것입니다. liberty에서 제안된 수정은 여기서 확인 가능합니다: https://review.openstack.org/#/c/161444/.

Revision as of 10:26, 3 May 2015 (view source) Ian Y. Choi (talk \| contribs) (Created page with "* Evacuate 복구 코드가 (VM 디스크) 데이터를 파괴할 가능성이 있습니다. nova-compute 시작시, 하이퍼바이저로부터 보고된 인스턴스가 중...")		Latest revision as of 18:01, 3 May 2015 (view source) Gang Sung Jin (talk \| contribs)
Line 1:		Line 1:
−	* Evacuate 복구 코드가 (VM 디스크) 데이터를 파괴할 가능성이 있습니다. nova-compute 시작시, 하이퍼바이저로부터 보고된 인스턴스가 중단되어 있는 동안 현 호스트로부터 이동되었는지 (즉, evacuate 되었는지)를 확인합니다. 만약 ~~이동되었음이 있다고~~ 판단되는 경우, 해당 VM들은 해당 지역에서 ~~삭데됩니다~~. 이는 잘못 선택되어 ~~인스턴스들을~~ 예기치않게 파괴할 가능성이 있습니다. libvert 계열 ~~노드들에서 이는~~ 호스트 이름을 변경함으로써 발생합니다. vmware 계열 노드들에서는 이는 두 개의 다른 호스트에서 (다른 호스트 이름을 가진 상태) ~~vcenter~~ 배포를 단일로 ~~관리하려고 시도할 때에~~ 발생합니다. 해당 이슈는 Liberty에서 ~~온전하게~~ 수정될 예정이지만, 현재는 해당 기능을 배포 환경에서 비활성화하고자 할 경우 예방적인 차원에서 workarounds.destroy_after_evacuate=False로 설정하여 가능합니다. 참고: 이는 회귀가 아닌 초기부터의 evacuate 기능 설계에 대한 결함으로 판명되었습니다. 이에 대한 쉬운 문제 해결이 없기에, 해당 대처법은 손상에 대한 가능성을 제한하는 것입니다. liberty에서 제안된 수정은 여기서 확인 가능합니다: https://review.openstack.org/#/c/161444/.	+	* Evacuate 복구 코드가 (VM 디스크) 데이터를 파괴할 가능성이 있습니다. nova-compute 시작시, 하이퍼바이저로부터 보고된 인스턴스가 중단되어 있는 동안 현 호스트로부터 이동되었는지 (즉, evacuate 되었는지)를 확인합니다. 만약 이동되었다고 판단되는 경우, 해당 VM들은 해당 지역에서 삭제됩니다. 이때 잘못 선택되어 인스턴스들이 예기치않게 파괴할 가능성이 있습니다. libvert 계열 노드들에는 호스트 이름을 변경함으로써 발생합니다. vmware 계열 노드들에서는 두 개의 다른 호스트에서 (다른 호스트 이름을 가진 상태) vcenter 배포를 단일로 관리하려할때 발생합니다. 해당 이슈는 Liberty에서 수정될 예정이지만, 현재는 해당 기능을 배포 환경에서 비활성화하고자 할 경우 예방적인 차원에서 workarounds.destroy_after_evacuate=False로 설정하여 가능합니다. 참고: 이는 회귀가 아닌 초기부터의 evacuate 기능 설계에 대한 결함으로 판명되었습니다. 이에 대한 쉬운 문제 해결이 없기에, 해당 대처법은 손상에 대한 가능성을 제한하는 것입니다. liberty에서 제안된 수정은 여기서 확인 가능합니다: https://review.openstack.org/#/c/161444/.