EC2에서 호스팅되는 웹 서비스를 작업 중이며로드에 따라 다양한 수의 인스턴스를 실행해야합니다. 우리는 기본 서비스를 시작하고 실행하고 있지만, 우리가 어려움을 겪고있는 것 중 하나는 Windows 인스턴스를 프로비저닝하고 시작하는 데 걸리는 시간입니다 (Windows에서만 실행되는 세 번째 prty 도구를 사용하고 있음). 나는 이것이 10 분에서 꽤 놀라운 45 분까지 걸리는 것을 보았습니다.
누구든지 EC2 인스턴스 시작 속도를 높이는 방법에 대한 팁이 있습니까? 예를 들어 Windows 서버의 AMI는 Linux AMI에 비해 크기가 크므로 AMI를 포함하는 S3 버킷이 인스턴스가 시작된 동일한 영역에 있는지 확인해야 할 수도 있습니다. 새로운 인스턴스 프로비저닝 속도를 높입니다.
답변:
어제 밤에 바닐라 Windows 2003 서버 3 개를 설치했습니다. 처음 두 시간은 약 45 분이 걸렸고, 세 번째는 약 1 시간 후에 2 시간이 걸렸습니다.
그것들은 S3 사용법없이 전혀 아무것도 없었습니다. 아마존이 시간이 지남에 따라 배포 속도 향상을 기다리는 것을 제외하고는 근본적인 단계를 가속화하는 방법이 의심됩니다. 따라서 일정 지연이 예상되고 Kurt의 조언이 훌륭하다고 결론 내릴 것입니다. 이는 1 또는 2를 예비 준비 상태로 유지하는 것입니다.
또 다른 방법은 AMI 유형의 새 인스턴스를 몇 번 만들고 생성하는 것입니다. 그런 다음 S3 스토리지로 몇 번 시도하여 추가 시간을 확인하십시오. 가용 영역이 이미지와 S3간에 일치해야한다고 가정하지만 시간 차이가 얼마나되는지 모르겠습니다.
프로비저닝 할 최대 시간을 결정한 후에는로드 / 사용을 몇 분 앞당기십시오.
"EC2 Config"windows 서비스의 기본 구성은 호스트 이름을 인스턴스의 내부 DNS 이름으로 바꾸는 것이므로 Amazon Windows 인스턴스는 시작시 재부팅됩니다. 호스트 이름을 바꾸려면 Windows에서 재부팅해야합니다. 인스턴스의 내부 DNS 이름을 사용할 필요가없는 경우 SetComputerName 기능을 비활성화하면 도움이 될 수 있습니다. 또한 Windows 인스턴스는 구성을 다시 번들로 묶어 시작 드라이브를 초기화 할 필요가 없다는 장점이 있습니다. 이 모든 것은 EC2 Windows 구성 서비스를 통해 가능합니다.
Windows 구성 서비스 : http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/appendix-windows-config.html
내 Windows 소형 인스턴스는 일반적으로 부팅하는 데 15-18 분이 걸립니다 (큰 인스턴스가 빠를수록). 요구 사항에 따라 AMI 내에 모든 소프트웨어를 번들로 묶어 해당 기간 내에 모든 소프트웨어를 부팅 및 실행할 수 있습니다. 모든 것을 AMI에 번들로 묶지 않은 예약을 이해하지만 모든 것을 번들로 제공하는 프로덕션 AMI를 갖기위한 시작 시간을 개선 할 가치가 있습니다. 빌드 환경에서 원하는 경우 빌드 스크립트를 별도로 유지하십시오.
또한 Amazon은 인스턴스 스토어 루트 볼륨과 달리 EBS 루트 볼륨을 릴리스했습니다. EBS 볼륨에서 실행되는 Windows 소형 이미지는 거의 20 분이 걸리는 데 비해 거의 5 분 안에 부팅됩니다. 또한 종료 할 필요가 없습니다. 중지 / 시작할 수 있습니다. 설정에 따라 일부 시작 스크립트에서 몇 분 더 단축 될 수 있습니다.
기본적으로 Windows EC2 Config 서비스, AMI 및 EBS 부팅 볼륨을 사용자 지정하면 시작 시간이 거의 5 분으로 단축됩니다. 특히 개발 목적으로 앱에 따라 ec2 인스턴스 시작시 실행되는 sysprep을 피할 수 있습니다. 시작할 때 호스트 이름을 변경하지 않는 비 시스템화 m1.large 이미지는 약 2 분 안에 시작될 수 있으며 이는 나쁘지 않습니다.
현재로서는 내가 이해하는 한 Amazon EC2에서 Windows로 할 수있는 최선이지만 실제로 그렇게 나쁘지는 않습니다. 평균 사용량 패턴을 기반으로 향후 10 분 정도의 시간을 예측할 수 있으면 추가 인스턴스를 가동하고 추가로드를 처리 할 수 있어야합니다.
우리는이 정확한 문제에 부딪 쳤지 만 매우 심각한 방식으로 새로운 시작은 Amazon EC2를 가상 랩 환경 (다중 사용자, 정책, 공유 등)으로 확장하므로 시작 시간을 단축해야했습니다. Windows 머신. 가장 큰 결정은 애플리케이션에서 EBS 기반 볼륨 만 지원하는 것이 었습니다. 5-10 분 안에 시작할 수있는 유일한 볼륨이기 때문입니다. 테스트 결과 인스턴스 스토어 시작 시간이 크게 다르고 때로는 너무 많은 시간이 걸리므로 쓸모가 없었습니다.
EC2의 Simon @ LabSlice 가상 랩 관리