끄적이는 보송

[AWS] Amazon FSx Shadow Copy 구현 해보기 본문

STUDY/AWS

[AWS] Amazon FSx Shadow Copy 구현 해보기

끄적이는 보송 2022. 10. 10. 20:55
반응형

Shadow Copy란?

오늘은 Amazon FSx for Windows Server의 Shadow Copy라는 기능을 해보려고 한다. 정확히 말하자면 AWS의 서비스가 아니라 Microsoft Windows의 컴퓨터 파일 또는 볼륨의 백업 복사본이나 스냅샷을 생성할 수 있는 기술이다. 간단히 설명하자면 윈도우 파일의 버저닝 같이며 Amazon은 Microsoft사의 기술을 가져온 것이다. 이것을 활용해 잘못 수정된 파일을 이전으로 돌릴 수 있으며, 삭제된 파일을 다시 불러올 수도 있다.

FSx를 구현해보면 알겠지만 파일을 삭제하면 휴지통으로 갈 것도 없이 그냥 바로 삭제되어 사라져 버린다. 이를 우려하는 사용자가 있어 그 해결책을 찾다 보니 Shadow Copy 기능을 사용하게 되었다.

[+] https://docs.aws.amazon.com/fsx/latest/WindowsGuide/shadow-copies-fsxW.html

 

Working with shadow copies - Amazon FSx for Windows File Server

Working with shadow copies A Microsoft Windows shadow copy is a snapshot of a Windows file system at a point in time. With shadow copies enabled, your users can easily view and restore individual files or folders from an earlier snapshot in Windows File Ex

docs.aws.amazon.com

 

 

Shadow Copy 기본 동작 및 고려 사항

- Shadow Copy도 스토리지를 차지한다.
Shadow Copy도 결국 원본의 복제본이다 보니 스토리지를 잡아먹는다. 기본 구성으로는 전체 볼륨의 10%만 사용하도록 설정되는데 이는 수동으로 바꿔줄 수 있다. (무제한도 가능)

- Shadow Copy의 최대 할당량(MaxSpace) 외에도 추가 스토리지가 필요하다.
최대 할당량 이외에도 적어도 320MB가 필요하다고 한다. 이유는 찾으면 다시 업데이트하겠다.

- Shadow Copy는 증분 백업이다.
Shadow Copy는 Block-Level로 증분 백업한다고 한다. 즉, 매번 Job이 수행될 때마다 전체 파일이 아닌 수정된 것만 백업한다는 것이다.

- 오래된 데이터는 덮어써진다.
파일 시스템 당 500개의 Shadow Copy를 가질 수 있고, 이를 넘기게 된다면 가장 오래된 된 복제본을 덮어 씌게 된다.  Shadow Copy의 최대 할당 스토리지를 초과하게 된다면 이 또한 오래된 데이터를 덮어 씌운다. 그러므로 자주 수정되는 파일 시스템이라면 최대 할당량 퍼센티지를 늘릴 필요가 있다.

- Shadow Copy 작업은 FSx의 리소스를 잡아먹는다.
copy-on-write 방식으로 작업이 수행되며, 파일 쓰기 작업에 파일 당 최대 3 I/O operations까지 올라갈 수 있다고 한다. 만약 FSx가 이를 버틸 수 없다면  copy-on-write 방식 백업 작업을 유지할 수 없다 판단하여 모든 Shadow Copies를 지운다고 한다. (솔직히 이지경까지 되는 걸 구현은 안 해봐서 생각만 해도 아찔하다) 그렇다면 충분히 커버가 가능한 성능으로 올려야 한다.

- FSx의 성능은 Throughput Capacity와 Storage Capacity 둘 다에 영향을 받는다.
단순히 MB/s 수치로 성능 조정이 가능한 Throughput Capacity를 늘리면 FSx의 성능이 올라갈 거라 생각하지만 이는 반만 맞는 말이다. FSx의 성능에는 Throughput Capacity의 영향을 받는 'file server I/O performance'Storage Capacity의 영향을 받는 'storage I/O performance'가 있다. 스토리지는 당연히 크기를 늘릴수록 성능에 좋다. 예산에 문제가 없다면 웬만하면 AWS는 HDD가 아닌 SSD를 권장하고 있다.

- FSx가 유휴 상태일 때만 Shadow Copy 작업을 수행하자.
데이터 마이그레이션이나 데이터 중복 제거 작업 중엔 Shadow Copy 작업이 수행되지 않도록 구성하라는 AWS Document의 주의 문구가 있었다. 구체적인 이유는 기재되어 있지 않지만 아무래도 성능이 딸리면 Shadow Copy가 미쳐 날뛰는 현상을 예방하기 위해서인 것으로 추측된다. 굳이 AWS가 이런 경고를 안 해도 작업으로 인한 FSx의 성능 저하를 최대한 예방하기 위해서는 각 Job이 겹치지 않도록 스케줄링해줄 필요가 있어 보인다.

 

 

Shadow Copy  기본 구성

이전에 데이터 중복제거를 다뤘었는데 그와 비슷하게 Amazon FSx에서 정의한 Windows PowerShell 명령을 사용해 파일 시스템에 주기적인 Shadow Copy 잡을 설정/활성화해주면 된다. 별다른 생각 없이 Default 설정으로 Shadow Copy를 활성화해주고 싶다면 아래 명령어에 Powershell Endpoint 부분만 각자에 맞게끔 수정하고 입력해주면 된다.

Default 설정대로라면 매주 월요일, 화요일, 수요일, 목요일, 금요일 오전 7:00 및 오후 12:00 UTC에 자동으로 Shadow Copy가 생성되며 FSx 전체 스토리지의 10%를 할당한다.

- Shadow Copy 기본 수준으로 세팅하기

Invoke-Command -ComputerName FSxFileSystem-Remote-PowerShell-Endpoint -ConfigurationName FSxRemoteAdmin -scriptblock {Set-FsxShadowStorage -Default}

- Shadow Copy 작업 스케줄 기본으로 세팅하기

Invoke-Command -ComputerName FSxFileSystem-Remote-PowerShell-Endpoint -ConfigurationName FSxRemoteAdmin -scriptblock {Set-FsxShadowCopySchedule -Default}

- Shadow Copy 작업 현황 보기

Invoke-Command -ComputerName FSxFileSystem-Remote-PowerShell-Endpoint -ConfigurationName FSxRemoteAdmin -scriptblock {Get-FsxShadowStorage}

- Shadow Copy 작업 제거

Invoke-Command -ComputerName FSxFileSystem-Remote-PowerShell-Endpoint -ConfigurationName FSxRemoteAdmin -scriptblock {Remove-FsxShadowStorage}

만약 아래와 같은 화면으로 에러가 출력되었다면 여러 가지를 의심해봐야 한다.

"AD 서버와 통신이 가능한 상태인가?"...
"방화벽으로 막히거나 한 것은 없는가?"...
"할당받은 AD 계정이 적절한 권한을 갖고 있는가?"...
"애당초 FSx의 PowerShell Endpoint를 불러올 수 있는가?"...
"AD 쪽에 레코드 값이 잘못 업데이트되어있지 않은가?"...
"AD계정의 암호가 올바른가?"...
"혹시 접속할 때 AD domain 값을 계정 앞에 붙여 접속 시도는 해보았는가?"...

다양한 경우의 수가 있는데 그중 은근히 실수하는 부분이 PowerShell을 AD계정으로 시작해보지 않았다는 것이다. '시작 > Windows PowerShell > 마우스 우클릭 > Run as different user > AD 계정 정보 입력'을 해보자. 

 

 

나만의 Shadow Copy  스케줄 구성해보기 (1시간마다 작업 돌리기)

한번 1시간마다 Shadow Copy 작업을 수행하는 스케줄을 생성해보려 한다. 아래처럼 직관적이지만 단순 무식한 방법으로 수행할 수도 있지만...

#시간 셋팅
$trigger1 = new-scheduledTaskTrigger -weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -at 00:00
$trigger2 = new-scheduledTaskTrigger -weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -at 01:00 
...
$trigger24 = new-scheduledTaskTrigger -weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -at 23:00

#작업 수행
invoke-command -ComputerName FSxFileSystem-Remote-PowerShell-Endpoint -ConfigurationName FSxRemoteAdmin -scriptblock {set-fsxshadowcopyschedule -scheduledtasktriggers $Using:trigger1,$Using:trigger2,...,$Using:trigger24 -Confirm:$false }

이런 방법도 있으니 참고해보자

#시간 셋팅(최초 작업 수행할 시간 기입)
#예를 들어 08:30으로 설정하면 최초롤 UTC 08:30에 작업이 실행되고, 다음 작업은 09:30 ... 10:30 ... 11:30 ... 식으로 매일 한시간씩 돌고 돌도록 설정됨
$trigger1 = New-ScheduledTaskTrigger -Daily -At 08:30
$trigger2 = New-ScheduledTaskTrigger -Once -At 08:30 -RepetitionInterval (New-TimeSpan -Minutes 60) -RepetitionDuration (New-TimeSpan -Hours 24)
$trigger1.Repetition = $trigger2.Repetition

#작업 수행
invoke-command -ComputerName FSxFileSystem-Remote-PowerShell-Endpoint -ConfigurationName FSxRemoteAdmin -scriptblock {set-fsxshadowcopyschedule -scheduledtasktriggers $Using:trigger1 }

최초 작업 시간 설정
매일 매 60분 마다 작업을 수행하도록 설정
두번째 트리거의 Repetition 값을 첫번째 트리거가 갖도록 설정
작업 명령어 수행. 만약 위와 같은 에러메시지가 출력된다. '-Confirm:$false' 부분을 없애준다. 단순 검토 관련 옵션이니 작업 수행에 큰 차이는 없다.
Shadow Copy 작업 시작 및 스케줄 확인
Shadow Copy 스토리지 상태 확인

결과적으로 위의 모든 게 정상적으로 수행되었다면 아래와 같은 화면을 볼 수 있을 것이다. 파일에 마우스 우클릭하여 속성에 접근해 버전을 확인하면 된다. 원하는 시간대의 버전을 클릭하면 새 창이 생성된다. 만약 삭제된 파일을 불러오고 싶다면 그 상위 폴더로 이동하여 똑같이 버전을 확인하면 된다.

[+] https://docs.aws.amazon.com/fsx/latest/WindowsGuide/manage-shadow-cpy.html#shadow-schedules

 

Shadow copies - Amazon FSx for Windows File Server

When shadow copies are automatically or manually created, they use as a storage limit the amount of shadow copy storage that you configured. Shadow copies don't use the available storage space shown by the CloudWatch FreeStorageCapacity metric as a storage

docs.aws.amazon.com

 

반응형
Comments