이 질문에는 흥미로운 점이 있습니다. 특히 다운 타임 아이디어와 관련이 있습니다. 응용 프로그램이 가동 중지 시간에 민감한 경우 복구 시간도 고려해야한다는 아이디어의 일부가 있습니다. ).
EBS에 대해 조금
EBS 볼륨 및 스냅 샷은 블록 수준에서 작동하므로 EBS 볼륨이 사용 중이라도 인스턴스가 실행되는 동안 스냅 샷을 생성 할 수 있습니다. 그러나 실제로 디스크에있는 (즉, 파일 캐시에없는) 데이터 만 스냅 샷에 포함됩니다. 일관된 스냅 샷에 대한 아이디어를 얻는 것은 후자의 이유입니다.
- 권장되는 방법은 볼륨을 분리하고 스냅 샷을 작성하고 다시 연결하는 것입니다. 일반적으로 실용적이지 않습니다.
- 다음으로 가장 좋은 옵션은 디스크에 쓰기 캐시를 플러시하고 파일 시스템을 정지시키고 스냅 샷을 만드는 것입니다.
여기서 흥미로운 점은 위의 두 경우 모두 스냅 샷이 재 연결 / 고정 해제를 마치고 디스크 쓰기를 다시 시작할 때까지 기다릴 필요가 없다는 것입니다. 일단 스냅 샷이 시작되면 데이터가 특정 시점과 일치합니다. 일반적으로이 작업은 몇 초만 걸리며 디스크가 쓰기 잠금 상태가됩니다. 또한 대부분의 데이터베이스는 파일을 디스크에 적절한 방식으로 구성하므로 삽입이 기존 블록에 미치는 영향을 최소화 할 수 있으므로 스냅 샷에 추가되는 데이터가 최소화됩니다.
백업 시점을 고려하십시오
EBS 볼륨은 이미 가용 영역 내에 복제되어 있으므로 어느 정도의 중복성이 내장되어 있습니다. 인스턴스가 종료되면 EBS 볼륨을 새 인스턴스에 간단히 연결하고 (일관성이 결여 된 후) 재개 할 수 있습니다. 중단했다. 여러 측면에서 이로 인해 EBS 볼륨은 액세스 할 수있는 경우 일관성이없는 스냅 샷과 매우 유사합니다. 즉, 대부분의 EC2 사용자는 2011 년 초부터 EBS 볼륨의 계단식 오류를 기억할 수 있습니다. 볼륨은 며칠 동안 액세스 할 수 없었으며 일부 사용자도 데이터를 잃었습니다.
RAID1
EBS 디스크의 고장을 막으려 고 시도하는 경우 (발생한 경우) RAID1 설정을 고려할 수 있습니다. EBS 볼륨은 블록 장치이므로 mdadm을 사용하여 원하는 구성으로 쉽게 설정할 수 있습니다. EBS 볼륨 중 하나가 사양에 맞지 않는 경우 수동으로 실패하고 나중에 다른 EBS 볼륨으로 교체하기가 쉽습니다. 물론 이것은 단점이 있습니다-모든 쓰기 시간 증가, 가변 성능에 대한 감수성 증가, I / O 비용의 두 배 (모노 타 릴리, 성능 측면이 아님),보다 광범위한 AWS 장애에 대한 실질적인 보호 기능 없음 (작년의 일반적인 문제는 잠금 상태 인 EBS 볼륨을 분리 할 수 없음), 물론 실패시 디스크의 일관성이없는 상태입니다.
S3FS
특정 응용 프로그램 (데이터베이스에는 해당되지 않음)의 옵션은 S3을 로컬 파일 시스템으로 (예 : s3fs를 통해) 마운트하는 것입니다. 속도가 느리고 파일 시스템에서 기대할 수있는 일부 기능이 없으며 예상대로 작동하지 않을 수 있습니다 (최종 일관성). 즉, 업로드 된 파일을 인스턴스 전체에서 사용할 수있게하는 것과 같은 간단한 목적으로 장점이있을 수 있습니다. 분명히 좋은 읽기 / 쓰기 성능이 필요한 것은 아닙니다.
MySQL 바이너리 로그
MySQL과 관련된 또 다른 옵션은 bin-log를 사용하는 것입니다. bin 로그를 저장하고 (추가 된 쓰기가 데이터베이스에 미치는 영향을 최소화하기 위해) 두 번째 EBS 볼륨을 설정하고 데이터베이스 덤프와 함께 사용할 수 있습니다. s3fs를 사용 하여이 작업을 수행 할 수도 있습니다. 실제로 성능을 견딜 수있는 경우 실제로 장점이있을 수 있습니다 (s3fs를 직접 사용하는 것보다 rsync가 더 좋을 수 있으며 가능한 한 압축해야합니다).
다시 한번, 우리는 목적의 개념으로 돌아옵니다. 위의 제안으로 어떤 일이 일어날 지 고려하십시오.
- 액세스 할 수없는 EBS 볼륨 :
- RAID1-당신이 데이터를 얻을 수 없기 때문에 쓸모없는
- bin-log-S3로 내 보낸 경우를 제외하고는 쓸모가 없습니다.
- 인스턴스가 예기치 않게 종료됩니다.
- RAID1-디스크를 사용할 수 있지만 일관성이없는 경우 데이터베이스 자체의 불일치에서 복구 할 수 있습니다
- bin-log-마지막 몇 가지 이벤트를 검토해야 할 수도 있지만 데이터에 액세스 할 수 있어야합니다.
- 누군가 루트로 DROP DATABASE를 실행합니다.
- RAID1-존재하지 않는 데이터베이스의 완벽한 사본 두 개가 있습니다.
- bin-log-명령 직전까지 이벤트를 재생할 수 있어야합니다.
따라서 RAID1은 대부분 쓸모가 없으며 bin-log는 너무 오래 걸립니다. 둘 다 특정 상황에서는 장점이 있지만 아이디어 백업과는 거리가 멀습니다.
스냅 샷
스냅 샷은 차등 적이며 데이터를 포함하고 압축 된 실제 블록 만 저장한다는 점에 유의해야합니다. 볼륨이 20GB이지만 1GB 만 사용하는 EBS 볼륨과 달리 여전히 '프로비저닝 된'스토리지 (20GB)에 대한 요금이 부과됩니다. 스냅 샷을 사용하면 사용한만큼만 요금이 청구됩니다. 스냅 샷간에 데이터가 변경되지 않으면 이론적으로 요금이 부과되지 않습니다. (스냅 샷은 PUTS / GETS 및 사용한 스토리지에 대해 청구됩니다).
또한 응용 프로그램 데이터 (데이터베이스 포함)를 루트 볼륨 (이미 설정했을 수 있음)에 저장하지 않는 것이 좋습니다. 장점 중 하나는 루트 볼륨에 최소한의 변화가 있다는 것입니다. 즉, 스냅 샷의 빈도가 적거나 변경이 적어 비용과 사용 편의성이 줄어든다는 것을 의미합니다.
또한 오래된 스냅 샷은 언제라도 삭제할 수 있다는 점과 관련이 있습니다. 차이는 있지만 다른 스냅 샷에는 영향을 미치지 않습니다. 즉, 스냅 샷에 할당 된 각 블록은 해당 블록을 여전히 참조하는 스냅 샷이 없을 때까지 양도되지 않습니다.
주기적 덤프의 문제점은 먼저 덤프 사이의 시간 (MySQL의 bin-log를 사용하여 해결 될 수 있음)과 복구의 어려움입니다. 큰 덤프를 가져 와서 bin-log에서 모든 이벤트를 재생하는 데 시간이 걸립니다. 또한 덤프 작성이 성능에 영향을 미치지 않습니다. 아마도 그러한 덤프는 스냅 샷보다 훨씬 더 많은 스토리지를 필요로합니다. 대부분의 측면에서 선호되는 데이터베이스 및 스냅 샷 전용으로 만 EBS 볼륨을 설정합니다 (즉, 스냅 샷을 만드는 것은 성능에 약간의 영향을 미칩니다).
스냅 샷 및 EBS 볼륨의 장점은 다른 인스턴스에서 사용할 수 있다는 것입니다. 인스턴스 부팅에 실패한 경우 루트 볼륨을 다른 인스턴스에 연결하여 문제를 진단 및 수정하거나 데이터를 복사 할 수 있으며 몇 분의 다운 타임으로 루트 볼륨을 전환 할 수 있습니다 (인스턴스 중지, 분리) 루트 볼륨, 새 루트 볼륨 연결, 인스턴스 시작). 동일한 아이디어가 두 번째 EBS 볼륨에 데이터를 보유하는 경우에도 적용됩니다. 기본적으로 커스텀 AMI에서 새 인스턴스를 가동하고 현재 EBS 볼륨을 연결하면 다운 타임을 최소화 할 수 있습니다.
(두 개의 EBS 볼륨을 사용하여 동일한 서버 (마스터-슬레이브)에 두 개의 MySQL 사본을 설정 한 다음 슬레이브를 종료하여 스냅 샷을 찍을 수 있다고 주장 할 수 있습니다 (아마도 권하지 않을 것입니다) EBS 볼륨-다운 타임없이 일관 적이지만 성능 비용은 그만한 가치가 없습니다).
AWS에는 자동 확장 기능이 있습니다.이 인스턴스는 일정한 수의 인스턴스를 유지할 수 있습니다 (해당 번호가 1 인 경우에도).하지만 스냅 샷에서 배포 할 수 있습니다. 따라서 스냅 샷이 유용하지 않다면 전제는 많이 사용되지 않습니다 .
또 다른 두 가지 점-주어진 시점에 단일 인스턴스에만 연결할 수있는 EBS 볼륨과 달리 단일 스냅 샷에서 원하는만큼 인스턴스를 배포 할 수 있습니다. 또한 EBS 볼륨은 가용 영역 내에서 사용하도록 제한되어 있으며 스냅 샷은 리전 내에서 사용할 수 있습니다.
스냅 샷을 사용하는 경우 서버가 다운되면 마지막 스냅 샷을 사용하여 새 스냅 샷을 시작할 수 있습니다. 특히 루트 볼륨을 데이터와 분리하면 업데이트가 잘못되면 다운 타임이 최소화됩니다. 데이터가 포함 된 EBS 볼륨을 전송하고 불일치로 인해 손상 될 수있는 모든 것을 보존하기 위해 스냅 샷을 만듭니다.
참고로 Amazon은 마지막 스냅 샷 이후에 변경된 데이터 양에 따라 EBS 볼륨의 실패율이 증가한다고 말합니다.
최종 추천
- 스냅 샷 사용 – 훌륭함-다운 타임을 야기하는 것보다 훨씬 줄임
- 별도의 데이터와 루트 볼륨 (아마도 데이터베이스를 자체 볼륨에 배치하고 필요할 경우 업데이트 전에 스냅 샷)
- bin-log를 사용하여 가능한 한 'hot'상태를 유지하십시오-이것을 (압축 된) S3에 업로드하십시오
- 실제로 데이터가 EBS 볼륨에 그대로 있어도 볼륨 자체에 일시적으로 액세스 할 수없는 경우에도 인스턴스에서 데이터를 가져와야합니다.
추천 자료 :
(나는 너무 많이 썼지 만 충분히 말하지 않았다고 생각하지만 읽을 가치가있는 것을 찾으십시오.)