2017-09-18 6 views
0

루트 볼륨이 300GB 인 데이터베이스 서버에서 AMI를 굽습니다. 볼륨의 80 %가 사용 중입니다. AMI를 제빵하는 이유는 매일 똑같은 데이터로 여러 개의 새로운 인스턴스가 필요하다는 것입니다. 복원 프로세스가 매우 느리기 때문에 AMI가 적절한 솔루션입니다. 따라서 인스턴스를 작성한 후에는 데이터 복원 프로세스를 시작할 수 없습니다. 모든 데이터가 포함 된 인스턴스가 7-8 분 내에 준비되기를 바랍니다.큰 EBS 볼륨 최적화 초기화 (예열)

그러나 새 인스턴스의 성능은 매우 좋지 않습니다. 그 이유는 인스턴스가 EBS를 사용하기 때문에이 문서에서 설명한대로 초기화해야합니다.

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-initialize.html

불행하게도, 초기화 과정 5 ~ 6 시간이 소요하고있는 우리에게 해결책이 아니다.

따라서 기본 데이터가 AMI에 있어야 할 때 AMI를 구우는 것이 가장 좋습니다.

+0

이 인스턴스에서 실행중인 데이터베이스 엔진은 무엇입니까? –

+0

@ Michael-sqlbot 데이터베이스 엔진과 관련이 없습니다. 우리는 MySQL이나 PostgreSQL을 사용하지 않습니다. 복원은 맞춤 프로세스입니다. –

+0

나는 이것이 관련이 없다는 것을 이해합니다. 이것은 당신이 구체적으로 무엇을 실행하고 있는지에 관계없이 스냅 샷의 AMI 및 EBS 볼륨의 특성의 일부입니다. 어떤 일을 하느냐에 따라 Aurora copy-on-write 클론 또는 EFS가 실행 가능한 솔루션이 될 수 있지만, 어떤 경우에도 5-6 시간 이내에 300GB 볼륨을 예열 할 수 있어야합니다. –

답변

0

이제 EBS 볼륨을 초기화하는 데 많은 도움이되는 내용이 있습니다.

AWS는 EBS 볼륨 초기화에 dd 또는 fio을 권장합니다. 단일 dd 프로세스를 실행하는 데 너무 많은 시간이 걸립니다. 따라서 주어진 블록에서 작은 덩어리의 데이터를 가져 오는 dd의 여러 프로세스를 사용하면 초기화 프로세스가 정말 빨라집니다.

nohup seq 0 $(($(cat /sys/block/xvda/size)/(1 << 10))) | xargs -n1 -P8 -I {} sudo dd if=/dev/xvda of=/dev/null skip={}k count=1 bs=512 > /dev/null 2>&1 &"

관련 문제