기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 기존 S3 File Gateway를 새 인스턴스로 교체
데이터 및 성능 요구 사항이 증가하거나 게이트웨이 마이그레이션 AWS 알림을 받는 경우 기존 S3 File GatewayFSx를 새 인스턴스로 바꿀 수 있습니다. 게이트웨이를 더 나은 호스트 플랫폼이나 최신 Amazon EC2 인스턴스로 이동하거나 기본 서버 하드웨어를 새로 고치려면 이 작업을 수행해야 할 수 있습니다.
기존 S3 File Gateway를 교체하는 방법에는 두 가지가 있습니다. 다음 표에서는 각 방법의 이점과 단점을 설명합니다. 이 정보를 사용하여 게이트웨이 환경에 가장 적합한 방법을 선택한 다음 아래 해당 섹션의 절차 단계를 참조하세요.
**참고**
[새 Storage Gateway 로컬 콘솔에 로그인](LocalConsole-login-fgw.md)하여 두 방법 중 하나를 완료해야 하는 경우 초기 사용자 이름은 *admin*이고 임시 암호는 *password*입니다.
**중요**
이 지침은 버전 1.x를 실행하는 게이트웨이 어플라이언스를 마이그레이션하는 경우에만 사용합니다. 하위 버전을 실행하는 게이트웨이 어플라이언스를 마이그레이션하는 데 사용할 수 없습니다.
| | **방법 1: 캐시 디스크 및 게이트웨이 ID를 대체 인스턴스로 마이그레이션\*** | **방법 2: 빈 캐시 디스크와 새 게이트웨이 ID가 있는 대체 인스턴스** |
| --- | --- | --- |
| **캐시 디스크 데이터** | 캐시 디스크의 데이터는 보존됩니다. 이 방법은 게이트웨이의 캐시 디스크가 크거나 애플리케이션이 out-of-cache 읽기 작업으로 인한 지연에 민감한 경우에 유용합니다. | 캐시의 데이터는 AWS 클라우드에서 다운로드됩니다. 이 방법은 애플리케이션이 out-of-cache 읽기로 인한 지연을 허용할 수 있는 경우 쓰기 작업이 많은 워크로드에 최적화되어 있습니다. |
| **가동 중지 시간** | 마이그레이션 프로세스 중에 게이트웨이가 1\~2시간 동안 오프라인 상태가 됩니다. | 파일 공유는 항상 사용할 수 있지만 클라이언트는 새 인스턴스로 전환하는 동안 한 파일 공유에서 다른 파일 공유로 전환할 때 짧은 전환 가동 중지 시간을 경험합니다. 두 파일 공유에서 한 Amazon S3 버킷에 동시에 쓰는 것은 *지원되지 않으므로* 모든 클라이언트는 점진적으로가 아니라 한 공유에서 다른 공유로 동시에 다시 매핑해야 합니다. |
| **게이트웨이 ID** | 새 게이트웨이는 대체하는 게이트웨이에서 게이트웨이 ID를 상속합니다. | 기존 게이트웨이와 대체 게이트웨이에는 별도의 고유한 게이트웨이 ID가 있습니다. |
| **비용 영향** | 캐시된 데이터 보존을 사용하면 다시 다운로드할 필요가 없으므로 추가 S3 비용이 발생하지 않습니다. | 이 방법은 특히 S3에서 데이터를 검색해야 하는 경우 추가 비용이 발생할 수 있습니다. 이 접근 방식은 SS3 버킷이 지원하는 파일 공유가 S3 Intelligent-Tiering, S3 Standard-IA, S3 One Zone-IA 또는 S3 수명 주기 정책을 통해 GLACIER로 전환된 객체와 같은 스토리지 클래스를 사용하는 경우 상당한 S3 데이터 검색 비용이 발생할 수도 있습니다.
SMB 파일 공유의 경우 루트 ACL이 파일 공유에 구성된 경우 마이그레이션된 게이트웨이에 다시 적용해야 합니다. 이 작업은 파일 공유 내의 모든 객체에 설정을 재귀적으로 적용하여 일부 비용에 영향을 미칩니다. |
**참고**
마이그레이션은 동일한 유형의 게이트웨이 간에만 수행할 수 있습니다. 예를 들어 설정 또는 데이터를 FSx File Gateway에서 S3 File Gateway로 마이그레이션할 수 없습니다.
## 방법 1: 캐시 디스크 및 게이트웨이 ID를 대체 인스턴스로 마이그레이션
**S3 File Gateway의 캐시 디스크 및 게이트웨이 ID를 대체 인스턴스로 마이그레이션하려면:**
1. 기존 S3 File Gateway에 쓰는 모든 애플리케이션을 중지합니다.
1. 다음 단계에 따라 게이트웨이를 최신 버전으로 업데이트합니다.
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. 탐색 창에서 **게이트웨이**를 선택한 다음 마이그레이션하려는 이전 S3 파일 게이트웨이를 선택합니다.
1. 사용 가능한 경우 **지금 업데이트를** 클릭합니다. 그렇지 않으면 게이트웨이가 이미 최신 버전입니다.
1. 기존 S3 File Gateway에 대한 **모니터링** 탭의 `CachePercentDirty` 지표가 `0`인지 확인합니다.
1. 하이퍼바이저 제어를 사용하여 호스트 가상 머신(VM)의 전원을 꺼서 기존 S3 File Gateway를 종료합니다.
Amazon EC2 인스턴스 종료에 대한 자세한 내용은 *Amazon EC2 사용 설명서*에서 [인스턴스 중지 및 시작](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/Stop_Start.html)을 참조하세요.
KVM, VMware 또는 Hyper-V VM 종료에 대한 자세한 내용은 해당 하이퍼바이저 설명서를 참조하세요.
1. 이전 게이트웨이 VM에서 루트 디스크 및 캐시 디스크를 비롯한 모든 디스크를 분리합니다.
**참고**
루트 디스크의 볼륨 ID와 해당 루트 디스크와 연결된 게이트웨이 ID를 기록해 둡니다. 이후 단계에서 새 Storage Gateway 하이퍼바이저에서 이 디스크를 분리해야 합니다.
Amazon EC2 인스턴스를 S3 File Gateway의 VM으로 사용하는 경우, *Amazon EC2 사용 설명서*의 [Windows 인스턴스에서 Amazon EBS 볼륨 분리](https://docs.aws.amazon.com//AWSEC2/latest/WindowsGuide/ebs-detaching-volume.html) 또는 [Linux 인스턴스에서 Amazon EBS 볼륨 분리](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ebs-detaching-volume.html)를 참조하세요.
KVM, VMware 또는 Hyper-V VM에서 디스크를 분리하는 방법에 대한 자세한 내용은 해당 하이퍼바이저 설명서를 참조하세요.
1. 새 AWS Storage Gateway 하이퍼바이저 VM 인스턴스를 생성하되 게이트웨이로 활성화하지 마세요. 이후 단계에서 이 새 게이트웨이는 이전 게이트웨이의 ID를 사용합니다.
새 Storage Gateway 하이퍼바이저 VM을 생성하는 방법에 대한 자세한 내용은 [호스트 플랫폼 선택 및 VM 다운로드](https://docs.aws.amazon.com/filegateway/latest/files3/create-gateway-file.html#hosting-options-file)를 참조하세요.
**참고**
새 VM에 캐시 디스크를 추가하지 마세요. 이 VM은 이전 VM에서 사용하던 것과 동일한 캐시 디스크를 사용합니다.
**참고**
VM을 다운로드한 후 콘솔 마법사를 닫습니다. 이 시점에서는 활성화를 진행하지 마십시오.
1. 이전 VM과 동일한 네트워크 설정을 사용하도록 새 Storage Gateway VM을 구성합니다.
게이트웨이의 기본 네트워크 구성은 DHCP(Dynamic Host Configuration Protocol)입니다. DHCP를 통해 게이트웨이에 IP 주소가 자동으로 지정됩니다.
게이트웨이 VM의 고정 IP 주소를 수동으로 구성해야 하는 경우 [네트워크 파라미터 구성](https://docs.aws.amazon.com//filegateway/latest/files3/appliance-configure-ip.html)을 참조하세요.
게이트웨이 VM이 소켓 보안 버전 5(SOCKS5) 프록시를 사용하여 인터넷에 연결해야 하는 경우 [HTTP 프록시를 통해 EC2에 배포된 게이트웨이 라우팅](https://docs.aws.amazon.com//filegateway/latest/files3/ec2-local-console-fwg.html#EC2_MaintenanceRoutingProxy-fgw)을 참조하세요.
**참고**
NFS 또는 SMB 클라이언트를 재구성하지 않도록 이전 게이트웨이 VM에서 동일한 고정 IP 주소 또는 호스트 이름을 재사용할 수 있습니다.
1. 새 Storage Gateway VM을 시작합니다.
1. 이전의 게이트웨이 VM에서 분리한 디스크를 새로운 게이트웨이 VM에 연결합니다. 새 게이트웨이 VM에서 기존 루트 디스크를 분리하지 마십시오.
**참고**
성공적으로 마이그레이션하려면 모든 디스크가 변경되지 않은 상태로 유지되어야 합니다. 디스크 크기 또는 기타 값을 변경하면 메타데이터에 불일치가 발생하여 마이그레이션이 성공하지 못합니다.
1. 새 게이트웨이 VM의 로컬 콘솔에 연결하거나 새 게이트웨이 VM의 IP 주소(아래 설명 참조)에 웹 요청을 수행하여 게이트웨이 마이그레이션 프로세스를 시작합니다.
1. 로컬 콘솔을 사용하려면 **게이트웨이 마이그레이션** 옵션을 선택하고 메시지가 표시되면 기존 게이트웨이 ID를 제공합니다. 이전 게이트웨이에 이전에 적용된 설정을 새 게이트웨이로 복사하라는 메시지가 표시됩니다. 이를 적용하거나 나중에 수동으로 구성할 수 있습니다. [게이트웨이 로컬 콘솔 액세스를 참조하세요](https://docs.aws.amazon.com/filegateway/latest/files3/accessing-local-console.html).
1. 또는 다음 형식을 사용하는 URL을 사용하여 새 VM에 연결하여 게이트웨이 마이그레이션 프로세스를 시작할 수 있습니다.
```
http://{{your-VM-IP-address}}/migrate?gatewayId={{your-gateway-ID}}
```
이전 게이트웨이 VM에 사용한 것과 동일한 IP 주소를 새 게이트웨이 VM에 다시 사용할 수 있습니다. URL은 다음 예와 비슷해야 합니다.
```
http://198.51.100.123/migrate?gatewayId=sgw-12345678
```
이 URL을 브라우저에서 사용하거나 `curl`을 사용하여 명령줄에서 사용하여 마이그레이션 프로세스를 시작합니다.
게이트웨이 마이그레이션 프로세스가 성공적으로 완료되면 마이그레이션 성공 여부를 확인하는 메시지가 표시됩니다.
1. 게이트웨이 상태가 AWS Storage Gateway 콘솔에서 **실행** 중으로 표시될 때까지 기다립니다. 사용 가능한 대역폭에 따라 최대 10분이 걸릴 수 있습니다.
1. 새 Storage Gateway VM을 중지합니다.
1. 이전에 기록한 볼륨 ID가 있는 이전 게이트웨이의 루트 디스크를 새 게이트웨이에서 분리합니다.
1. 새 Storage Gateway VM을 시작합니다.
1. 게이트웨이가 Active Directory 도메인에 조인된 경우 도메인에 다시 조인합니다. 지침은 [Active Directory를 사용하여 사용자 인증](https://docs.aws.amazon.com//filegateway/latest/files3/enable-ad-settings.html)을 참조하세요.
**참고**
S3 File Gateway의 상태가 **조인됨**으로 표시되는 경우에도 이 단계를 완료해야 합니다.
1. 게이트웨이가 SMB 게스트 액세스 인증 방법을 사용하는 경우 암호를 다시 입력해야 합니다. 지침은 [파일 공유에 대한 게스트 액세스 제공을 참조하세요](https://docs.aws.amazon.com/filegateway/latest/files3/guest-access.html).
1. 새 게이트웨이 VM의 IP 주소에서 공유를 사용할 수 있는지 확인한 다음 이전 게이트웨이 VM을 삭제합니다.
**주의**
게이트웨이를 삭제하면 복구할 수 없습니다.
Amazon EC2 인스턴스 삭제에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 종료](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/terminating-instances.html)를 참조하세요. KVM, VMware 또는 Hyper-V VM 삭제에 대한 자세한 내용은 해당 하이퍼바이저 설명서를 참조하세요.
## 방법 2: 빈 캐시 디스크와 새 게이트웨이 ID가 있는 대체 인스턴스
**빈 캐시 디스크와 새 게이트웨이 ID를 사용하여 대체 S3 File Gateway 인스턴스를 설정하려면:**
1. 기존 S3 File Gateway에 쓰는 모든 애플리케이션을 중지합니다. 새 게이트웨이에서 파일 공유를 설정하기 전에 **모니터링** 탭의 `CachePercentDirty` 지표가 `0`인지 확인합니다.
1. AWS Command Line Interface (AWS CLI)를 사용하여 다음을 수행하여 기존 S3 File GatewayFSx 및 파일 공유에 대한 구성 정보를 수집하고 저장합니다.
1. S3 File Gateway에 대한 게이트웨이 구성 정보를 저장합니다.
```
aws storagegateway describe-gateway-information --gateway-arn "arn:aws:storagegateway:{{us-east-2}}:{{123456789012}}:gateway/sgw-12A3456B"
```
이 명령은 게이트웨이의 이름, 네트워크 인터페이스, 구성된 시간대 및 상태(게이트웨이가 실행 중인지 여부) 등 게이트웨이에 대한 메타데이터를 반환하는 JSON 블록을 출력합니다.
1. S3 File Gateway의 SMB(Server Message Block) 설정을 저장합니다.
```
aws storagegateway describe-smb-settings --gateway-arn "arn:aws:storagegateway:{{us-east-2}}:{{123456789012}}:gateway/{{sgw-12A3456B}}"
```
이 명령은 도메인 이름, Microsoft Active Directory 상태, 게스트 암호 설정 여부, 보안 전략 유형 등 SMB 파일 공유에 대한 메타데이터가 포함된 JSON 블록을 출력합니다.
1. S3 File Gateway의 각 SMB 및 NFS(Network File System) 파일 공유에 대한 파일 공유 정보를 저장합니다.
+ SMB 파일 공유에 다음 명령을 사용합니다.
```
aws storagegateway describe-smb-file-shares --file-share-arn-list "arn:aws:storagegateway:{{us-east-2}}:{{123456789012}}:share/{{share-987A654B}}"
```
이 명령은 이름, 스토리지 클래스, 상태, IAM 역할 Amazon 리소스 이름(ARN), S3 File Gateway에 액세스할 수 있는 클라이언트 목록, SMB 클라이언트가 탑재 지점을 식별하는 데 사용하는 경로 등 SMB 파일 공유에 대한 메타데이터가 포함된 JSON 블록을 출력합니다.
+ NFS 파일 공유에 다음 명령을 사용합니다.
```
aws storagegateway describe-nfs-file-shares --file-share-arn-list "arn:aws:storagegateway:{{us-east-2}}:{{123456789012}}:share/{{share-321A978B}}"
```
이 명령은 이름, 스토리지 클래스, 상태, IAM 역할 ARN, S3 File Gateway에 액세스할 수 있는 클라이언트 목록, NFS 클라이언트가 탑재 지점을 식별하는 데 사용하는 경로 등 NFS 파일 공유에 대한 메타데이터가 포함된 JSON 블록을 출력합니다.
1. 이전 게이트웨이와 동일한 설정 및 구성으로 새 S3 File Gateway를 생성합니다. 필요한 경우 2단계에서 저장한 정보를 참조하세요.
1. 이전 게이트웨이에 구성된 파일 공유와 동일한 설정 및 구성을 사용하여 새 게이트웨이에 대한 새 파일 공유를 생성합니다. 필요한 경우 2단계에서 저장한 정보를 참조하세요.
1. 새 게이트웨이가 올바르게 작동하는지 확인한 다음 환경에 가장 적합한 방식으로 이전 파일 공유에서 새 파일 공유로 클라이언트를 다시 매핑/컷오버합니다.
1. 새 게이트웨이가 올바르게 작동하는지 확인한 다음 Storage Gateway 콘솔에서 이전 게이트웨이를 삭제합니다.
**중요**
S3 File Gateway를 삭제하기 전에 해당 게이트웨이의 캐시에 현재 쓰기 작업 중인 애플리케이션이 없는지 확인해야 합니다. 사용 중인 게이트웨이를 삭제하면 데이터 손실이 발생할 수 있습니다.
**주의**
게이트웨이를 삭제하면 복구할 수 없습니다.
1. 이전 게이트웨이 VM 또는 Amazon EC2 인스턴스를 삭제합니다.