Azure File Share는 기존 Network File Share (SMB)을 클라우드로 옮기면서 동시에 비용 절감을 할 수 있는 대표적인 Microsoft Azure의 서비스이다.
클라우드의 장점중 하나는 바로 기존 인프라를 사용하지 않고 핵심 서비스만 사용하여서 유지 보수 비용을 줄이는 것이다. 이렇게 핵심 서비스만 사용함으로써 기업은 기존에 지출했던 CapEx을 OpEx로 전환이 가능하다. CapEx와 OpEx의 차이점에 대해서는 이전 글을 참조하기 바란다.
2021.08.02 - [미국 IT 이야기] - OpEx가 대세이고, CapEx는 구세대 모델? (미국 IT 취업11)
OpEx가 대세이고, CapEx는 구세대 모델? (미국 IT 취업11)
우리 앞에 놓여진 치즈는 고갈되는 것은 시간의 문제이다. 또한 내가 좋든 싫든 계속적으로 프로세스 (Process) 를 극대화 시키려는 인간의 노력들은 끊임없이 진행될 것이고, 이에 발맞춰 Technology
washington.doniq.net
기업이 기존 Network File Share를 클라우드 서비스인 Azure File Share로 전환한다는 것은 어떤 의미인가? 이것을 아래의 피자 서비스 테이블을 가지고 이야기 해보자. 기존의 Network File Share는 데이터센터에 Cheese, Toppings, Tomato Sauce, Pizza Dough, Fire, Oven, Electric, Gas, Drink and Dining Table 즉 모든 재료부터 시작해서, 재료를 요리하기 위해 필요한 전기와 가스, 그리고 고객들에게 대접할 드링크와 고객이 앉아서 식사할 수 있는 Dining table까지 모두 제공하는 방식이다. 아래의 테이블에서는 이것을 Made at Home (집에서 만드는 방식 - 일명 Traditional On-Premises) 지칭하고 있다. 즉 모든 과정을 내가 컨트롤해야 한다. 피자 반죽이 떨어지면 내가 사서 보충해야 하며, 오븐이 고장할 경우에도 직접 서비스 센터에 내가 연락을 해서 이를 해결해야 한다.
이것을 File Share 입장에서 이야기해본다면, 데이터를 저장할 하드 디스크의 용량이 부족할때는 내가 직접 하드 디스크를 구매하여 더 채워넣어야 한다는 의미이다. 데이터를 저장하는 장비 (Storage Appliance)가 고장이 나거나, 유지 보수가 필요할 때에도 내가 직접 이 모든 과정에 관여하여야만, 최종 서비스인 피자를 만들수 있다. 이러한 의미에서 왼쪽 파란색으로 되어 있는 "Made at Home - 기업이 모든 것을 다 처리하는 방식"은 클라우드 사용전 우리가 사용하거나 사용했던 방식이다.
반면에 Azure File Share 서비스를 사용할 경우, 이러한 내가 해야할 일이 아주 축소된다. 즉, 내가 직접 토마토 소스와 토핑을 사다 놓지 않아도 된다. 전기와 오븐과 같은 인프라를 가질 필요도 없으며, 고객에게 대접할 음료수와 테이블 자체도 내가 제공하지 않아도 된다. 이것을 위의 테이블에서는 "Dining Out - 밖에서 피자를 사먹는 방법"이라 표현했다. 즉, 하드 디스크 용량이 부족한 것도 내가 해결할 필요없이 클라우드 서비스가 해결해주고, 전기와 오븐과 같은 인프라도 내가 유지보수 관리를 하지 않아도 되어서 단지 피자 서비스만 앉아서 즐기면 되는 것이다. 이것이 바로 클라우드 서비스의 한가지 큰 장점이다. 이러한 과정에서 필요했던 인력 (피자 재료 배달, 오븐에서 피자 굽는 것)도 더이상 필요없게 되는 것이다.
Azure File Share와 같은 서비스를 SaaS (Software as a service)라 부르는데, 그 이유는 파일 쉐어링 서비스만 이용하고 따로 내가 플랫폼이나 인프라를 관리하지 않고 Azure에서 직접 관리해주기 때문이다. 또한 기존 데이터센터의 모든 파일 쉐어를 클라우드로 옮기지 않고 Hybrid (클라우드와 데이터센터의 혼합) 형태로도 Azure File을 사용할 수 있다. 이와 함께 Azure Active Direcoty와도 연동하여서 파일 퍼미션을 설정할 수 있기 때문에 기존의 NAS (Network Access Storage) 을 교체할 막강한 클라우드 서비스이다. 그러한 이유로 lift and shift (들어서 옮기기) 방식으로 쉽게 클라우드 서비스 파일 쉐어링을 사용할 수 있다.
먼저 Azure File Share에 사용되는 개념들에 대한 정리를 시작해보자
목차
- SMB(Server Message Block)와 Network File Share란 무엇인가?
- Azure Storage Replication Type이란 무엇인가?
- Storage Access Tier란 무엇인가?
- Azure File을 구현하기 위해 필요한 Azure Networking 셋업
- Azure Private Link & Private Endpoint for Azure File
- Azure File을 연결하기 위해 필요한 Active Directory Domain Services Authentication over SMB
- Azure File Share Backup
SMB(Server Message Block)와 Network File Share란 무엇인가?
SMB는 윈도우, 리눅스, 그리고 Mac OS에서 Network File Sharing을 위해 사용되는 프로토콜이다. Azure File은 SMB 2.1, SMB 3.0 그리고 SMB 3.1.1을 지원한다. 숫자가 높을수록 더 보안이 강화가 된 프로토콜 버전이다. 또한 SMB 3.0버전부터는 active active, transparent failover, multi-channel 등을 지원하고 있다. 아래 스크린샷 가장 마지막에는 SMB 2.1은 "Secure Transfer Required" 옵션을 선택했을 때 사용할 수 없다고 강조되어 있다. Network File Share은 보통 이 SMB protocol을 의미한다.
Azure File의 디폴트 프로토콜은 모든 SMB 버전을 지원한다.
하지만, Secure Transfer Required을 Storage Account에서 체크해주면, SMB 2.0는 자동으로 비활성화된다.
또한 Security가 아주 엄격한 환경에서는 SMB 3.1 버전만 아래의 스크립을 통해서 활성화 시킬 수 있다.
SMB 3.1과 같은 새로운 버전만을 사용한다고 설정할 경우, 오래된 클라이언트 머신에서 연결에 문제가 있을 수 있다. 예를들면 AES-256-GCM과 같은 cipher는 Windows Server 2022과 Windows 11에서부터 소개되었기 때문에 이 cipher를 지원하지 않는 경우는 (예를 들면 Windows 8) 네트워크 파일 쉐어링이 불가능할 수 있다는 것도 기억해야한다. SMB 프로토콜을 이해했으니 이제 Azure Storage Replication Type에 대해서 이야기해보자.
Azure Storage Replication Type이란 무엇인가?
클라우드의 장점 중 하나는 비지니스가 계속 진행될 수 있도록 장애에 대해서 미리 대비해 놓을 수 있다는 것이다. 데이터를 보관하는 Storage을 구성할 때, 이러한 장애를 대비해서 여러가지 옵션을 Azure에서는 제공하고 있다.
- LRS (Locally Redundat Storage)
- GRS (Geo Redundant Storage)
- ZRS (Zone Redundant Storage)
- GZRS (Geo Zone Redundant Storage)
아래의 그림을 사용하여 4가지 Storage Replication Type에 대해서 설명해보자. 우선 내가 속해 있는 지역 (Region)을 US East라고 가정한다. US East라는 Azure 데이터센터에는 몇개의 빌딩이 있다. 이 빌딩들을 Zone 이라고 부르자. 내가 사용하는 데이터를 아래의 푸른색 점이라고 가정해보면, LRS는 US East Azure 데이터센터의 첫번째 빌딩 (AZ1)안에 3개의 다른 서버안에 저장되어 있다고 생각하면 된다. ZRS는 US East Azure 데이터센터의 3개의 빌딩마다 하나의 데이터가 각각 저장되어 있다고 생각하면 된다. 예를들어 Azure US East Azure AZ1 빌딩에 화재가 발생했을 경우, LRS Storage는 더이상 서비스를 제공하지 못하지만, ZRS Storage는 AZ2 혹은 AZ3를 통해서 서비스를 계속 고객들에게 제공할 수 있다.
GRS의 경우에는 LRS가 다른 지역 (예를들어 US West)에 또 하나 pairing 되어 있다고 생각하면 된다. RA-GRS의 경우는 메인 Region (예를들어 US East)로만 데이터 wirte 권한이 있고, US West 에는 Read-only 권한이 있는 상황에 사용된다.
참고로 RA-GZRS는 Azure File에 사용되지 않는다. RA-GRS와 비교했을 때 데이터가 한 지역 안에서 여러개의 AZ1-3에 나눠져 있는 경우가 RA-GZRS storage repliation type이다.
이러한 Storage Replication 옵션은 Region (지역)에 따라 다르다. 즉, US East의 Azure Data Center와 US West에 위치한 Azure Data Center는 위치적으로 다른 것뿐 만 아니라, 건물과 네트워크 여건이 다르다. 즉 모든 지역이 위의 4가지 옵션을 제공하는 것이 아니라는 것을 기억하자.
사실 이것보다 더 중요한 것은 Azure cloud와 어떻게 현재 연결이 되어있는지를 고려해서 Store replicataion type을 설정하는 것이다. 예를들어, 현재 환경에서 Azure로 Express Route US East로만 연결이 되어 있다고 가정해보자. 이런 경우 GRS (다른 지역에 또 다른 데이터를 복사해 놓는 방법) 설정은 별 의미가 없다. 왜냐하면 US East 지역에 장애가 생겼을 때 네트워크를 통해서만 Azure File은 접속이 가능한데, 데이터는 다른 지역에 있다 한들 네트워크 연결이 안되기 때문이다. 이런 경우 쓸데없는 비용만 더 사용하게 되기 때문에 자신이 속한 환경을 바르게 이해하고 Storage Repliation Type을 선택해야 한다.
Storage Replication type을 한번 선택했지만, 다른 옵션으로도 변경이 가능하다. 아래의 스크린 샷은 LRS에서 GRS 혹은 RA-GRS로 업데이트가 가능하다고 알려주고 있다.
지금까지 보여준 옵션은 Standard Performance HDD 옵션이고, 이제는 Premium Performance SDD 옵션에 대해서 이야기해보자. Low latency (최고 빠른 속도를 원할 경우) Premium Performance 타입의 Azure Storage Account을 선택할 경우에는 LRS와 ZRS만 선택이 가능하다. 즉, US East 지역에서 Premium 타입을 선택할 경우, US West로 데이터를 옮기면서 동시에 최고의 속도를 지원하지 못한다는 것이다. 바꿔 말하자면, 장애에 대비해서 다른 지역으로 데이터를 옮겨 놓을수는 있지만, 동시에 아주 빠른 속도로 데이터를 접속하지는 못한다는 의미이다.
다음은 Storage Account Access Tier에 대해서 알아보자.
Storage Access Tier란 무엇인가?
Azure Storage Account는 Blob, File, Table, Queue등의 다른 종류의 데이터 저장방식을 지원한다. 이 포스팅은 File에만 집중하고 있지만, 예를들어 Blob의 경우에는 파일 형태가 아래와 같이 Hot, Cool, Archive 세가지 종류로 나뉘어진다. Hot은 데이터의 접근 (Write/Read) 횟수가 많을 경우에 사용된다. Hot Access Tier의 경우 저장 공간 자체 비용은 Cool과 Archive에 비해서 비싸다. 하지만, 데이터를 접근할 때의 비용은 Cool과 Archive에 비해서 저렴하다. Cool Access Tier의 경우에는 저장 공간 비용은 Hot에 비해서 저렴하나, 데이터를 접근 (Write/Read) 할 때의 비용은 Hot Access Tier에 비해 비싸다. Archive의 경우는 온라인으로 바로 데이터가 접근 불가하며, Hot혹은 Cool로 변경한 후에 몇시간이 지난후에야 데이터에 접근이 가능하다. 즉 테이프 드라이브와 같은 저렴한 저장 매체로 옮겨진 상태가 바로 Archive Tier이다.
Azure File의 경우 위에서 설명한 Blob과는 달리 Premium, Transaction Optimized, Hot and Cool로 나눠진다. Premium은 SSD를 사용하며, 최고 빠른 Network File Sharing 원할 때 사용되어진다. Premium과 나머지 세가지 Access Tier의 다른점은 Premiun은 데이터를 사용 유무에 관계없이 가격이 책정된다. 반면 Transaction Optimized, Hot, and Cool Access Tier는 Stnadard HDD로 가격은 Premium보다 저렴하다. Premium Performance를 사용하기 위해서는 Azure Storage Account을 만들때 SSD (Premium level)을 선택해야한다.
Transaction Optimized Access Tier을 사용하는 경우는 어플리케이션이 Network File Sharing에 많은 영향을 미칠 경우에 사용한다. 예를들면 Azure Web App을 Front End (웹서버) 로 사용하고 있고, Azure File을 Backend (데이터베이스)로 사용하여서 어플리케이션을 구성할 경우 Transaction Optimized Access Tier가 적합할 것이다. 반면 기존에 사용하고 있던 Network File Share을 단순히 Azure File로 교체할 경우에는 Hot Access Tier가 가장 바람직이다. Cool Access Tier는 자주 데이터에 접근하지 않지만 언제나 접근이 용이해야할 경우에 사용한다. 사실 이런 경우에는 Azure File Cool Access Tier보다는 Azure Blob Archive Tier을 사용하는 것이 더 경제적이다. 물론 Azure Blob Archive Tier는 바로 접근할 수 없다는 단점을 가지고 있기는 하다.
아래의 스크린샷은 Standard Performance 어카운트에서 선택할 수 있는 옵션을 보여주고 있다. 그림에서 알 수 있듯이 Premium 옵션은 storage account 자체가 HDD이기에 비활성화되어 있다
4가지 종류의 Azure File Access Tier 중 어떤 것을 선택하느냐에 따라서 가격이 천차만별이다. 한가지 기억해야 할 사실은 Standard Performance Account의 Transaction Optimized, Hot, and Cool Access Tier는 모두 동일한 성능을 가지고 있다.
- Maximum IO/s 1000
- Egress Rate 60 MB/s
- Ingress Rate 60 MB/s
- Maximum Capacity: 5TB
Azure File의 세가지 Access Tier의 성능이 같다는 것은 무엇을 의미하는가? Hot Tier가 Cool Tier보다 많은 IOPS을 가지거나 Egress rate이 높은 것이 아니기 때문에, 상황에 따라서 알맞는 Tier를 고객들이 선택해서 사용하라는 의미이다. 하지만, 많은 고객들은 자신들이 어떤 Tier를 선택해야 하는지 헷갈리게 마련이다. 이때 바로 사용하는 툴이 바로 Azure Price Calculator이다.
Azure Files Pricing 알아보기
Azure File과 같은 데이터 저장 서비스의 가격을 살펴볼때 크게 2가지를 염두해두어 한다. 첫째는 Data Storage, 즉 저장공간에 대한 가격이다. Data at rest 라는 의미는 데이터가 움직이지 않고 저장만 되어 있는 상태를 말한다. 이렇게 저장된 상태만 비교해본다면 Transaction Optimized Tier ($0.06 per GB)가 Hot Tier ($0.0255)와 Cool Tier ($0.015)보다 비싼 편이다. 또한 Snapshot의 경우에도 Transaction Optimized Tier가 Hot Tier와 Cool Tier보다 비싸다. 하지만 Metadata at rest (파일 디렉토리와 액세스에 관한 메타 데이타)의 경우 Transaction Optimized Tier는 Hot Tier와 Cool Tier와는 다르게 무료이다. 이렇게 저장되는 공간을 기준으로 각 Tier를 비교했다면 다음에는 Transaction and Transfer 가격을 비교해야 한다. 참고로 Azure File 이외의 Azure Blob도 아래와 같은 방식으로 가격대를 알 수 있다.
어느 정도 예상했겠지만, 저장 공간이 비싼 Tier는 Transactions and data transfer 가격은 다른 Tier에 비해 저렴하다. 예를 들어 Write Transaction (데이터를 수정하거나 만드는 경우)의 경우 Cool Tier ($0.13)는 Hot Tier ($0.065)와 Transaction Optimized ($0.015)에 비해서 비싸다. 다시 풀어말하자면 저장하는 그 순간에는 Cool Tier가 다른 Tier보다 저렴하지만, 저장된 데이터를 사용할 때에는 Cool Tier가 다른 Tier보다 비싸다는 의미이다. 한가지 더 눈여겨 볼 항목은 Premium SSD이다. Premium Tier의 경우 Transactions and Data Transfer가 무료이다. 즉 마음대로 써도 저장 공간만 지불하면 되는 것이 Azure File Premium Tier의 장점이기도 하다.
그렇기 때문에 앞서 설명한 것처럼 어플리케이션에 따라 어떤 Tier를 선택하느냐가 가장 큰 포인트이다. 이 포스팅은 기존 Network File Share을 Azure File로 바꾸는 것을 기본으로 작성하고 있기에 이 경우에는 Hot Tier가 가장 보편적이다. 즉 SMB File Sharing을 위해서는 Azure File Hot Tier가 가장 적합하다는 의미이다.
Azure File Premium Tier의 경우 아래와 같이 Provision된 Share Size에 따라 요금이 청구된다고 써있는 반면, Standard Tiers인 Transaction Optimized, Hot, and Cool Tier는 사용한 만큼만 요금이 청구된다는 것을 기억하자.
또한 Premium Tier의 경우 얼마만큼의 SSD를 Provision하느냐에 따라서 Performance가 달라진다. 위의 스크린 샷의 경우처럼 1024GB의 Premium Tier의 Share를 만들 경우, Maximum IO/s인 1424 그리고 Egress Rate이 121.4MB/s의 속도를 지원한다.
반면 아래와 같이 4096GB을 Premium Tier에서 Share로 만들 경우에는 Maximum IO/s이 4496 그리고 Egress Rate이 305.8MB/s으로 늘어난다. 그러므로 Premium Tier에서 Share를 만들 경우에는 꼭 정확한 저장 용량을 명시하는 것이 Azure File Sharing의 포인트라고 할 수 있다. 반면 Standard Tier는 Quota가 있지만, 사용만 만큼만 지불하기에 디스크 사이즈는 큰 의미가 없다
Azure File을 구현하기 위해 필요한 Azure Firewall and Networking 셋업
Azure File의 Tier 선택을 마쳤다면, 다음에 해야할 일은 Azure File을 네트워크에 연결하는 일이다. Network File Sharing 프로토콜인 SMB 기반인 Azure File은 Public IP를 통해서도 연결이 가능하다. 하지만 많은 경우 Network File Share는 기업내 네트워크에 접속되었을 때에만 연결이 가능하도록 설정을 한다. 기업내 네트워크 연결이란 직접 회사 네트워크에 Wired 혹은 Wireless로 연결되거나 VPN을 통해서 연결되는 것을 의미한다.
이렇게 사내 네트워크에 접속을 해야만 Network File Sharing을 할 수 있게 하는 이유는 보안과 속도 때문이다. Azure File과 같은 Network File Sharing은 협업을 위해서 사용되어진다. 그러므로 허락된 클라이언트들만 접속을 하기 위해서 보안 설정이 필요하며, Public IP를 통해서 연결되는 Network File Share는 느리다는 단점이 있다. 그러한 이유로 Azure File의 보안과 속도를 개선하기 위해서 Azure Site to Site VPN 혹은 Azure Express Route (직접 연결)을 Azure File을 사용하기 위해서 사용한다.
Azure File은 클라이언트 뿐만 아니라, Azure 자체의 Virtual Network와도 연결을 해야할 경우가 있다. 예를 들어 Virtual Machine이 Native Azure vNET에 위치해 있고 Azure File을 연동해야 할 경우가 바로 이런 경우이다. 이렇게 특정한 Virtual Network를 File Share와 연결하기 위해서는 아래와 같이 Firewall and Virtual Network 섹션에도 해당 Virtual Network를 추가해야 한다. 이때 한가지 기억해야 하는 사실은 Firewall and Virtual Network의 설정은 File Share 뿐만 아니라 Storage Account 전체에 영향을 미친다는 사실이다. 즉, Storage Account 아래에 몇개의 File Share가 있을 경우, 이 설정이 모든 File Share에 영향을 준다는 것을 기억해야 한다.
Azure Private Link & Private Endpoint for Azure File
Azure File을 사내망에서만 접근하는 이유를 보안과 속도라고 위에서 다루었다. Azure File을 실제적으로 내부망에서만 접근하기 위해서 필요한 서비스가 바로 Azure Private Link와 Azure Private Endpoint이다. Private Link는 Azure vNet에 속한 IP를 이용해서 서비스의 endpoint를 만든다. 즉, Storage Account가 private IP로 접근할 수 있도록 하는 작업을 하는 것이다. 그러한 이유로 Private Link와 Private Endpoint의 DNS 설정을 꼭 해야지만 내부로 연결이 가능하다. 실제로 Storage Account의 경우 아무런 셋업없이 Firewall만 허락한다면 Public IP로 연결이 가능하다. 즉 DNS 설정도 없이 연결이 가능하다는 의미이다. 예를들면 Azure File 이름을 washington이라고 했다면, Azure File을 접근하기 위해서 사용되는 URL은 washington.file.core.windows.net이 자동적으로 되며, 이에 따른 Public IP도 부여가 자동으로 된다. 즉 내부 DNS server 에서 washington.file.core.windows.net의 Private IP를 설정하지 않을 경우 Private IP가 아닌 Public IP로 연결이 되는 것이다.
Private Link를 설정 한 후에는 Azure File은 두가지 방법으로 연결이 가능하다. 예를들어 Storage account의 이름이 washington이라고 가정하면, 두가지 연결 방법은 아래와 같다.
- washington.file.core.windows.net
- washington.privatelink.file.core.windows.net
이렇게 Private Link와 Private Endpoint을 사용하면 Azure File을 내부 네트워크에서만 연결할 수 있게 만들어서 보안 및 파일 쉐어링 속도를 개선할 수 있다.
마지막으로 SMB 프로토콜은 TCP/445 을 이용해서 통신을 한다. 그러므로 내부 네트워크에서 Azure File endpoint까지 TCP/445가 열려있는지 확인이 필요하다.
Azure File을 연결하기 위해 필요한 Active Directory Domain Services Authentication over SMB
Azure File은 Identity-based authentication이 가능하다. 이를 위해 Azure Active Directory Domain Service (Azure AD DS) 혹은 Active Directory Domain Service (AD DS)가 필요하며, 특별히 AD DS를 사용하기 위해서는 Azure AD Connector 싱크 서비스를 이용해서 클라우드로 AD object sync가 되어야한다.
많은 경우 AD DS가 Aure AD DS보다 Azure File Sharing을 위해서 사용되어진다. 즉, 기존의 AD 환경이 있을 경우에는 Aure AD DS을 통해서 유익을 볼 수 있는 부분이 적을 뿐만 아니라, 추가적으로 셋업을 해주어야 되는 반면, AD DS의 경우는 아주 간단한 스크립을 통해서 Azure File과 연계가 가능하다는 장점이 있다.
Azure AD DS를 사용하기 위해서는 추가로 아래의 셋업이 필요하기 때문에 현재 Windows AD를 사용하고 있다면 AD DS를 사용하는 것이 Azure File을 구성하기에 더 편리하다.
AD DS와 연계하여 Azure File을 사용할 경우 Kerberos authentication 을 이용한 인증방식이다. 이때 사용하는 것이 Computer Type Object 혹은 Service Login Account 이며, 이 어카운트가 Azure Storage 어카운트와 맵핑이 되는 방식을 Azure File에서는 사용한다. 보통의 경우 Computer Type Object가 default로 되어 있으며, 이것이 문제가 될 경우에는 Service Login Account을 사용하면 된다.
Storage Account와 AD DS을 연계하기 위해서 사용하는 스크립은 아래와 같다. 이 스크립은 AD에 조인된 컴퓨터에서 꼭 실행을 해야 한다. 자세한 script은 여기를 참조하기 바란다. 링크
# Change the execution policy to unblock importing AzFilesHybrid.psm1 module
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
# Navigate to where AzFilesHybrid is unzipped and stored and run to copy the files into your path
.\CopyToPSPath.ps1
# Import AzFilesHybrid module
Import-Module -Name AzFilesHybrid
# Login with an Azure AD credential that has either storage account owner or contributor Azure role assignment
# If you are logging into an Azure environment other than Public (ex. AzureUSGovernment) you will need to specify that.
# See https://docs.microsoft.com/azure/azure-government/documentation-government-get-started-connect-with-ps
# for more information.
Connect-AzAccount
# Define parameters
# $StorageAccountName is the name of an existing storage account that you want to join to AD
# $SamAccountName is an AD object, see https://docs.microsoft.com/en-us/windows/win32/adschema/a-samaccountname
# for more information.
$SubscriptionId = "<your-subscription-id-here>"
$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
$SamAccountName = "<sam-account-name-here>"
$DomainAccountType = "<ComputerAccount|ServiceLogonAccount>" # Default is set as ComputerAccount
# If you don't provide the OU name as an input parameter, the AD identity that represents the storage account is created under the root directory.
$OuDistinguishedName = "<ou-distinguishedname-here>"
# Specify the encryption algorithm used for Kerberos authentication. Using AES256 is recommended.
$EncryptionType = "<AES256|RC4|AES256,RC4>"
# Select the target subscription for the current session
Select-AzSubscription -SubscriptionId $SubscriptionId
# Register the target storage account with your active directory environment under the target OU (for example: specify the OU with Name as "UserAccounts" or DistinguishedName as "OU=UserAccounts,DC=CONTOSO,DC=COM").
# You can use to this PowerShell cmdlet: Get-ADOrganizationalUnit to find the Name and DistinguishedName of your target OU. If you are using the OU Name, specify it with -OrganizationalUnitName as shown below. If you are using the OU DistinguishedName, you can set it with -OrganizationalUnitDistinguishedName. You can choose to provide one of the two names to specify the target OU.
# You can choose to create the identity that represents the storage account as either a Service Logon Account or Computer Account (default parameter value), depends on the AD permission you have and preference.
# Run Get-Help Join-AzStorageAccountForAuth for more details on this cmdlet.
Join-AzStorageAccount `
-ResourceGroupName $ResourceGroupName `
-StorageAccountName $StorageAccountName `
-SamAccountName $SamAccountName `
-DomainAccountType $DomainAccountType `
-OrganizationalUnitDistinguishedName $OuDistinguishedName `
-EncryptionType $EncryptionType
#Run the command below to enable AES256 encryption. If you plan to use RC4, you can skip this step.
Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName
#You can run the Debug-AzStorageAccountAuth cmdlet to conduct a set of basic checks on your AD configuration with the logged on AD user. This cmdlet is supported on AzFilesHybrid v0.1.2+ version. For more details on the checks performed in this cmdlet, see Azure Files Windows troubleshooting guide.
Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose
AD DS와 Azure Storage Account가 연계가 된 후에는 아래와 같이 Active Directory: Configured 라는 표시를 볼 수 있고, 이제부터는 AD에 있는 User들과 Group을 사용하여서 Azure File Access 을 쉽게 조정할 수 있게된다. 이렇게 AD DS을 사용하여 Authentication을 할 경우의 장점중 하나는 Storage Account와 AD가 직접적으로 커뮤니케이션 하지 않아도 된다는 것이다. 즉, Kerberos Ticket를 이용하여서 인증이 되는 방식인데, 정확히 표현하면 클라이언트가 AD와 연결이 된 상태에서, AD에 있는 Computer Type Object을 통해서 Azure Storage와 연결이 되는 것이다.
AD DS와 Storage Account의 연동이 된 후에는 Access Control을 시작할 수 있다. 이때 두가지의 Access Control이 있는데, Share Level Access Control과 File Level Access Control이 있다. 우선 Share Level Access Control에 대해서 살펴보자. Azure RBAC에는 다음과 같이 3가지 Built-in Role이 존재한다.
- Storage File Data SMB Share Reader (읽기 권한)
- Storage File Data SMB Share Contributor (읽고, 쓰고, 지울 수 있는 권한)
- Storage File Data SMB Share Elevated Contributor (읽고, 쓰고, 지우고, 다른 유저을 컨트롤할 수 있는 권한)
이렇게 세가지의 Share Level을 AD user와 연계하여서 권한 설정이 가능하다. 아래는 Storage File Date SMB Share Elevated Contributor 권한을 Bruce와 Clark 라는 유저에게 정한 후의 Storage Account의 스크린 샷이다. 여기서 많은 사람들이 헷갈리는 것이 Share Level Access Control과 File Level Access Control의 차이점이다. 아래의 Bruce는 Share에 대해서는 모든 권한을 가지고 있지만, Share 안에 폴더와 파일에 관해서는 아직까지 아무런 권한이 없는 상태이다. 즉, Share Level은 단순히 Share을 마운팅할 수 있는 정도라고 생각하면 되고, File Level Access Control이 파일과 폴더의 Access 권한이다.
Bruce의 경우 Azure RBAC에서 Storage File Data SMB Share Elevated Contrubutor의 가장 높은 SMB 권한이 있지만 NTFS File Share Access Control에서 단순히 Read의 권한을 부여받을 경우, 결국 Bruce는 해당 쉐어의 폴더와 파일을 읽을 수있는 제한된 권한을 가지게 되는 것이다. 아래의 테이블은 Azure RBAC built-in role과 NTFS permission의 관계를 잘 보여주고 있는 테이블이다.
Azure File Share을 처음 만든 후에 Security Tab을 확인해보면 아래와 같은 유저와 그룹, 그리고 시스템이 자동으로 생성된다. 이렇게 built-in 되어 있는 유저들과 그룹, 그리고 시스템은 삭제하고, 필요한 유저 혹은 그룹만 Share에 접속할 수 있도록 File/Folder permission (NTFS)을 지정해주면 된다.
아래의 화면은 Azure File Share을 T: 드라이브에 마운팅하고 난후에, 그룹을 추가하면서 NTFS Permission을 조정한 후의 스크린 샷이다. 새롭게 구성한 그룹은 Azure File Share에 관해서 Full Control을 할 수 있도록 조정하였다.
Azure File Share Backup
Azure File Snapshot은 Delta Snapshot을 사용한다. 첫번째 Snapshot은 Basedline Snapshot이라 보통 부르는데, 이것은 복사 정도라고 생각하면 된다. 두번째부터 생성되는 Snapshot이 바로 Delta Snapshot인데, 이 Snapshot은 Baseline Snapshot과는 달리 이전 Snapshot에서 달라진 부분만을 포함한다. 예를들어 Snapshot이 총 10개가 있다면 1개의 Baseline Snapshot과 9개의 Delta Snapshot으로 이루어지는 것이다. 이렇게 Delta Snapshot을 사용하면 총 저장되는 공간을 효율적으로 사용할 수 있다.
Azure File은 Azure Backup Center의 Policy를 이용해서 자동으로 백업이 되게 할 수 있다. 이때 사용하는 것이 Service Vault라는 서비스인데, 이 서비스를 통해서 백업 Orchestration이 가능하게 된다. 이때 백업은 Service Vault에 저장되지 않고, Storage Account에 저장된다. 즉 Service Vault는 직접적인 백업에 관여는 하지만, 백업 파일 자체는 보관하지 않는다는 것이 특이사항이다.
위에서 Azure File Price Calculator 사용하는 법을 이미 다루었다. 그런데 자세히 보면 Snapshot (GiB/month) 라는 가격표를 Data Storage 섹션 밑에서 찾아볼 수 있다. 즉, Snapshot도 Azure File Price을 계산할때 꼭 염두해 두어야 한다. 현재 데이터센터의 Retension Policy (얼마 동안 보관하고 지우는지)를 보고, 이에 따라서 Azure Backup Policy을 조정하면 된다.
한가지 기억해야 할 것은 File Share를 지울 경우 모든 Snapshot도 다 지워진다는 것을 기억하자. 이러한 이유로 File Share가 실수로 지워졌을 때, email notificaiton을 설정하는 것을 추천한다. 물론 Soft Delete 옵션을 설정해 놓지 않으면 Share를 복구할 수 없다는 것도 기억하자. 아래의 Azure File Backup Policy는 30일동안 daily backup을 하고, weekly backup 으로는 매주 일요일마다 12번을 하도록 설정한 Azure File Backup Policy의 스크린 샷이다. 이외에도 Monthly 그리고 Yearly backup policy도 만들 수 있다.
백업을 하고 난후, 파일 및 폴더의 복구는 클라이언트가 직접 가능하다. 아래와 같이 Windows Explorer에서 해당 파일 혹은 폴더의 Previous Versions을 누르면 해당 파일 혹은 폴더만 복구가 가능하다. 간단하게 몇개의 폴더 혹은 파일만 복구할 경우는 아래와 같이 하면 되지만, 폴더의 갯수가 많을 경우에는 Azure Portal에 접속해서 직접 복구를 하는 것을 추천한다.
위에서도 언급했지만, Azure File Share 서비스로 인프라가 바뀌어도 Network File Sharing을 직접 사용하는 유저들은 아무런 변화를 찾아볼 수 없다. 한가지 기억해야 할 것은 File Share가 cloud로 옮겨졌기 때문에 Share을 접속할 때 속도가 느려질 수도 있다. 이러한 경우에는 Azure File Sync 라는 서버를 사용해서, 자주 접속하는 파일들은 데이터센터에 두고, 데이터를 cloud로 sync하는 방법으로 해결할 수 있다.
결론
Azure File Share는 비교적 쉽게 구현 가능한 서비스이며 기존의 데이터센터 안에 있던 Storage 솔루션들을 클라우드로 쉽게 이동할 수 있게 한다. 이때 데이터를 잘 구별하여 적절한 Access Tier로 설정하면 확실한 비용 절감이 가능하다. 얼마만큼의 비용 절감이 가능한지 예측하기 위해서 Azure Price Calculator를 사용할 수 있으며, End user들은 기존의 Network File Sharing 서비스와 Azure File의 다른 점을 실감하지 못할 정도로 기능면에서는 On-premises의 storage을 교체할 수 있는 클라우드 서비스이다. 또한, 저장 용량이 부족할때에도 바로 용량을 늘릴 수 있는 장점도 있다. ZRS, GRS와 같은 미러링 기능을 추가로 이용하면 장애가 생겨도, 비지니스는 계속 돌아갈 수 있다. 이러한 이유로 클라우드의 서비스가 점점 늘어가고 있는 추세이다. 이제부터는 Azure File을 만드는 과정을 살펴보자
How to Create Azure File Step by Step (Azure file 만들어보기)
1. Storage Account 만들기 - Storage Account을 만들기 위해서 Subscription과 Resource Group을 선택해주어야 한다. 만약 Resource Gruop을 이전에 만들지 않았다면 "Create New"를 클릭한 후에 새로운 그룹을 만들어준다. 나는 AzureFile-rg 라고 리소스 그룹을 만들었고, 그 그룹안에 Storage Account을 만들려고 한다.
Storage Account Name은 유닉한 이름으로 지어주어야 한다. 즉, User ID처럼 다른 사용자가 이미 만들어 놓은 account name은 사용할 수 없다. 나중에 다루겠지만, 우리가 만들 Azure File은 인터넷으로도 접속이 가능하기 때문이다. 예를들어 filestorage 라고 이름을 지을 경우, Azure File의 URL은 filestorage.file.core.windows.net 이 된다. 즉 앞부분이 다른 storage account와 구별지을 수 있는 유일한 단어이기 때문에 storage account name이 중복될 수 없는 것이다. 이를 위해 Microsoft에서는 Resource naming restriction rule을 만들었다. 즉, 각 Resource에 이름 짓는 방법에 관하여 룰이 있다. Storage Account는 아래에 같이 Global scope 즉, 세상에 하나만 존재하는 이름을 지어야 하며, 길이는 3-24 이어야 하고, 알파벳 소문자와 숫자로만 이루어져야 한다. 특수문자는 Azure Storage Account을 만들때 넣을 수 없다.
Resource naming restrictions - Azure Resource Manager
Shows the rules and restrictions for naming Azure resources.
docs.microsoft.com
Storage Account 이름을 지정했다면, 이제 지역을 선택해야 한다. 나의 경우에는 회사의 데이터센터가 존재하는 US East 를 선택했다. 이 지역 선택은 신중히 해야 하는데, 다른 리소스가 이미 Azure 에 존재한다면 가능한 같은 지역을 선택하는 것이 좋다. 그 이유는 리소스간에 서로 커뮤니케이션을 할때 한 리스소가 다른 지역에 있다면 추가로 이용료를 지불해야 하며, 리소스가 같은 지역에 존재하지 않기 때문에 속도 역시 느려질 수 있다.
Performance는 Premium와 Standard 두 종류가 있다. 이미 Storage Access Tier란 무엇인가에서 두 가지의 차이점을 설명했으니 이 부분은 Standard를 선택하기로 한다. 하지만, 이 부분에 대해서 확실한 이해를 못했을 경우에는 위의 Storage Access Tier를 다시 한번 정독하길 바란다. 어떤 선택을 하느냐에 따라서 가격의 차이가 엄청나게 벌어질 수 있는 부분이 바로 Performance 선택이기 때문이다.
마지막으로 선택할 것은 Redundancy, 즉 해당 지역 (US East)에 문제가 발생했을 때, 다른 지역 (예를들며 US West)에 동일한 데이터를 백업해 놓아서 장애를 최대한 줄이는 방법에 대한 선택이다. 이 부분도 위에서 이미 다루었기에 자세한 설명은 생략하려고 한다. 간단히 LRS와 ZRS만 아래의 그림을 통해서 비교해보면 AZ1 이라는 데이터센터에 불이 났을 경우 Storage Account의 Redundancy LRS를 선택했을 때에는 장애를 피해갈 방법이 없다. 하지만 ZRS을 선택했을 경우에는 동일한 데이터가 AZ2 와 AZ3에 존재하기 때문에 데이터센터의 장애를 피할 수 있다. 하지만 이러한 선택은 당연히 더 많은 데이터 저장 용량이 필요하기에 클라우드 사용 가격이 올라가게 마련이다.
2. 두번째 Advanced 탭에서 특별히 주의해야 할 부분은 "Enable storage account key access" 부분과 "Minimum TLS version 1.2"이다. Storage account key는 후에 Windows NTFS permission을 조정해야 하기 때문에 지금은 선택을 한다. 하지만 모든 셋업을 마친 후에는 storage account key로 액세스할 수 있는 권한을 없애는 것을 추천한다. TLS 1.0 혹은 1.1의 cipher의 경우는 이미 보안에 취약하기 때문에 최소한의 TLS version은 1.2를 사용해야 한다.
우리가 만들 Storage account는 Azure File만을 사용할 계획이기 때문에 blob, data lake, table, queue와 같은 설정은 default로 놔두어도 문제가 되지 않는다. 즉 어떤 선택을 해도 Azure File과 관련이 없을 경우에는 아무런 의미가 없다는 것이다.
3. Advanced 탭에서 설정해주어야 할 부분은 Azure Files 밑에 있는 "Enable large file shares" 라는 옵션이다. 위에서 설명했지만, 이 옵션을 선택해주는 자체로 File에 접근할 수 있는 속도를 높여주기 때문이다. 하지만, 이 옵션은 모든 Storage에 해당되지는 않는다. 이 옵션은 위에 설명한 Storage Redundancy와 밀접한 관계가 있다. 즉 Large file share는 GRS와 같은 다른 지역으로 데이터를 Sync할 경우에는 사용할 수가 없다. 또한 LRS로 Storage account을 처음 셋업한 후에 후에 GRS와 같은 다른 옵션의 Redundancy로 바꿀수는 있다. 하지만 이 옵션을 체크해서 Storage account을 만들었다면 redundancy를 다른 옵션으로 바꿀 수 없다고 아래의 스크린 샷에도 설명하고 있다. 그렇기 때문에 처음 storage account을 설정할 때 신중을 기해서 선택을 해야 한다.
4. Networking 탭에서는 Network Access 를 "Enable public access from all networks"로 설정한다. 이 설정 또한 모든 Azure File이 완성된 후에 다시 "Disable public access and use private access"로 바꿀 것이다. Network Share의 대부분의 경우는 회사의 사설망과 연결이 된 후에만 접근이 가능하도록 설정한다. Remove VPN이 여기에 해당되는데, VPN으로 사설망에 접속하기 전까지는 File Share에 접근하지 못하도록 설정하는 것이다. 이러한 이유로 Azure File을 Public에서 액세스하지 못하게 하는 것이다. Networking routing은 default 셋업인 "Microsoft network routing"을 선택한다. Private Endpoint는 여기에서 설정하지 않고, Storage Account을 생성한 후 만들기 때문에 여기에서는 스킵해준다.
5. Data Protection 탭에서는 "Enable soft delete for file share"가 체크 되어 있을 것이다. 누군가 실수로 File Share을 지웠을 경우 며칠 안에 다시 복구를 할 수 있는 기능이다. 이것은 뒤에 다룰 backup 과는 다른 개념이다. Tracking과 같은 기능은 File Share에 해당이 되지 않기에 default 셋팅 그대로 놔둔다.
6. Encryption Type은 기본 설정인 Microsoft-managed key (MMK)을 사용한다. 즉, Encryption 한 후에 Key를 Microsoft 에서 관리할 것인지 아니면 Customer가 관리할지를 결정해주는 것이다. Private Key를 따로 회사에서 관리할 경우에는 CMK를 설정하면 된다. "Enable infrastructure encryption" 기능은 최근에 새로 추가된 기능으로 Infrastructure 자체를 한번 더 Encryption해준다. 이를 double encryption 이라고도 부른다. 즉, 하나의 Key를 누군가가 알게되어도, 또 다른 Key가 필요하기 때문에 데이터를 보호해주는 이중 장치를 만드는 것이다.
하지만, Infrastructure encryption은 Storage account가 만들어진 후에는 변경이 불가능하다는 것도 기억하자.
7. 마지막 Tags 탭에서는 필요한 Tag을 지정해주면 된다. 보통의 경우 각 부서별로 혹은 프로젝트별로 Tag을 설정하여서 리소스들을 구별한다. 개인적으로는 Project별로 Tag을 설정하는데, 그 이유는 Project가 끝난후에 필요없는 리소스들을 한꺼번에 지울 수 있어서 편리하기 때문이다. 또한 Project별로 Tag을 부쳐놓으면 각 프로젝트마다 사용한 Azure Cost를 확인할 때 편리하다. 이렇게 Basic Storage Account을 생성하는 과정을 마쳤다. 이제 Azure File에 필요한 세부 사항을 셋업해보자.
8. Azure File의 RBAC 설정을 위해서 Active Directory에서 Security Group을 만들어준다. 이 그룹 안에 필요한 유저들을 추가하면, 이 유저들이 결국 Azure File 접속이 가능하게 된다. Azure Active Directory를 사용하는 경우라면 On-prem Active Directory가 클라우드로 Sync가 되어 있을 것이다. 이렇게 그룹안에 유저들을 추가시키고 이 그룹이 Azure File을 접속할 수 있게 만든다. Group이 아닌, 유저들만 추가해도 문제는 되지 않지만, 관리면에서 그룹별로 하는 것이 효율적이다.
9. AD DS Integration with Azure File: Storage Account - File shares을 선택한다. 생성된 Azure Storage는 아직까지 Active Directory와 연동이 되어 있지 않다. 즉, Step 8에서 설정한 그룹을 Azure File에 연동하기 위해서는 AD DS Integration script을 실행해야 한다. 이 Script은 포스팅 윗 부분에 있으니 참고하기 바란다. 중요한 것은 이 스크립을 실행하기 위해서는 해당 도메인에 조인된 컴퓨터에서 실행을 해야 한다는 것이다. 이렇게 script을 실행 한후에는 아래와 같이 "Active Directory Configured" 라는 메세지를 확인할 수 있다. 그 설정 옆으로는 Soft Detele이 설정되어 있는 것이 보이며 (7days), Maximum Capacity가 100TB라는 것도 확인할 수 있다.
Script을 실행 한후에 Active Directory에는 Computer object가 자동으로 생성된다. 이 Computer object가 AD와 Azure File을 연결해주는 역할을 한다. 자동으로 생성된 Computer object의 Description에는 "Computer account object for Azure Storage account"라고 쓰여있다. "Protect object from accidental deletion"을 체크해주면 누군가가 실수로 object을 지우는 것을 방지할 수 있다.
10. AD와 Azure File이 연동이 끝났으니, 이제부터 File Share을 만들어보자. "File Share" 추가버턴을 누르면 File share name과 Tier를 선택할 수 있다. File Share Name은 Storage Account Name과 달리 유닉하지 않아도 괜찮다. 즉 동일한 이름의 File Share를 다른 Storage account마다 사용할 수 있다.
Tier 역시 포스팅의 윗부분에서 자세히 다루었기 때문에 여기서는 Hot을 선택해주기고 File Share을 생성을 마친다.
11. 생성된 File Share의 액세스를 위해 Access Control (IAM) 을 선택한 후 "Add role assignment"을 선택한다.
12. Role 탭 밑에 "SMB"라고 검색을 한 후 "Storage File Data SMB Share Contributor" 을 선택한다. 나머지 SMB 유저들은 위의 포스팅에서 설명했기 때문에 여기에서는 설명을 생략하기로 한다.
13. Active Direcoty와 연동이 되어 있기 때문에 Member에서 기존에 생성한 Group을 설정해줄 수 있을 것이다. 이로써 File Share을 어떤 유저가 mounting 할 수 있는지에 대한 설정이 끝났다. (Windows NTFS Permission은 후에 설정을 할 예정이다)
14. Azure File Share를 Private IP로 접속하기 위해서는 Private Endpoint connection을 만들어주어야 한다. Storage Account - Networking - Private Endpoint Connection에서 이를 생성해준다.
15. Storage Account와 동일한 Subscription / Resource Group을 선택해주고, Private Endpoint 이름과 Network Interface Name을 설정해준다. 보통의 경우 Private Endpoint 이름은 Share name - PE 이렇게 해준다. (abcdef-PE). Region은 Storage account가 위치한 지역과 동일하게 설정해준다.
16. Resource 탭에서는 Target sub-resource 에서 "File"을 선택한다.
17. 이제 생성할 Private Endpoint을 어떤 네트워크에 연결하는지 설정을 해준다. Virtual Network와 Subnet은 생성될 xxxxx-PE와 연결된다. 이때 Dynamically allocate IP address를 선택하면 해당 네트워크 (서브넷)에서 Private IP를 할당 받을 수 있다.
18. Private DNS integration은 옵션으로 Azure DNS Private Zone integration을 설정하지 않았다면, No을 설정해주고 다음으로 넘어간다.
19. 설정한 Private Endpoint의 DNS Configuration에서 Private IP address와 FQDN을 확인할 수 있다. 이 FQDN을 이용하여 User들은 Azure File을 mounting할 수 있다.
20. 스텝 18에서 Azure DNS zone을 따로 설정하지 않았다면 DNS zone을 따로 설정해주어야 한다. Forwarding Lookup Zone에 "file.core.windows.net"이라는 Primary Zone을 만들어주고, 여기에 해당 DNS을 수동으로 넣어준다. 예를들면 abcde.file.core.windows.net 192.168.1.9 이런식으로 A 레코드를 넣어주면 된다. 이 정보는 스텝 19에서 얻을 수 있다.
21. 이제 File Share 중 NTFS Permission을 설정해보자. 스텝 11에서 설정한 RBAC은 Share 자체에 대한 것이다. 즉 어떤 유저가 Share를 mounting할 수 있는가의 설정이다. 이번 스텝 21은 Share가 이미 마운팅 된 상태에서 어떤 유저가 파일 및 폴더를 어디까지 설정할 수 있는지 (read/write/delete)를 설정하는 과정이다. 이러한 NTFS permission을 설정하기 위해서 필요한 것이 바로 도메인에 조인할 컴퓨터와 Storage Access Key이다. 이를 위해 Share을 선택하고 이 중 "'Connect" 옵션을 선택한다.
22. 윈도우에서 Azure File을 연결하기 위해 Windows 탭을 선택한 후, Drive Letter 및 Storage account key를 선택한다. 선택이 끝나면 PowerShell Script이 보이는데, 이것을 윈도우에서 실행해주면 Azure File에 연결 가능하다.
Script을 실행한 후에는 "Credential added successfully"라는 메세지와 함께 새로운 네트워크 드라이브가 보일 것이다.
간혹 Script을 실행할때 이슈가 발생하기도 한다. 이럴때는 윈도우 자체에서 수동적으로 Network Drive을 Mapping 해준다. 이때 Folder는 \\AzureFileName.file.core.windows.net\ShareName 을 사용하면 된다. "Connecting using different credentials"을 선택하여야지만 Access Key 을 사용하여서 Azure File에 접속할 수 있다. Access Key를 이용해서 인증을 할 경우에는 Username은 아래와 같이 사용해야 한다.
Username: \localhost.storagename
Password: Access Key
23. Storage Access Key를 이용하여서 Azure File을 Mounting 한다음에는 Windows NTFS Permission을 조정한다. 이를 위해 Share를 선택하고 Property - Security Tab으로 이동한다. Share가 생성되고 자동으로 생성된 Group과 Username이 보일 것이다. 이 모든 그룹과 유저들을 지워주고, 우리가 만든 Security Group만을 추가한 후에 Full Control을 제외한 모든 권한을 이 그룹에게 부여한다.
24. Security group에 속해있는 User는 이제 자신의 PC에서 Azure File share를 자신의 AD account로 mounting 할 수 있을 것이다. 지금까지의 과정은 Azure File Share를 위한 Configuration이었다. 이제 Share를 백업하고, 백업 리포트를 만드는 과정을 살펴보자.
Azure File Share 백업하기
Azure File Share를 만드는 방법은 위의 단계에서 마쳤다. 하지만, File Share에 백업 기능이 없다면, 사용자가 임의로 지웠던 파일등은 복구가 불가능하다. 이제 Recovery Services Vaults의 백업 기능을 이용해서 Azure File Share을 백업해보자.
1. Azure File Share 백업을 위해서는 Recovery Services Vaults 라는 리소스가 필요하다. 실제적으로 백업을 저장하는 장소는 Storage account이지만, 백업을 위해서는 Recovery Services Vaults가 필요하다. Recovery Services Vaults로 이동한 후에 Recovery Service Vault를 생성한다.
Subsriptions, Resource Group, Vault Name, 그리고 Region을 선택하고 필요한 Tag를 넣음으로 Recovery Services Vaults 가 생성된다. Region은 Storage Account와 같은 지역을 선택하여 불필요한 추가 사용료를 지불하지 않는다.
2. Recovery Services Vault가 만들어진 후에는 Backup Instance을 만들어준다. 이를 위해서 "Backup center"로 이동후 "Backup Instances"를 선택한다. 아래의 그림에서 Datasource Type을 Azure File을 선택한 후 "Backup"을 누른다. 정리해보면 Recovery Services Vaults는 하나의 중간 매개체이고, Backup Center에서 백업 작업을 만들어주고, 이것이 Recovery Services Vaults와 연결이 된다. 그리고 실제적인 백업 위치는 Storage Account에 되는 것이다.
3. Backup 작업을 실행하기 위한 창이 뜨면서 Datasource type을 선택하라고 나온다. 이미 스텝 2에서 Azure File을 선택했기에 아래와 같이 Datasource type이 미리 정해져있을 것이다. Select vault를 눌러서, 우리가 만든 Recovery Services Vault을 선택해준다.
4. 백업을 위해 사용한 Storage Account을 선택한 후, File Share to Backup에서 해당 Share를 선택한다. "Enable lock on the storage account"는 자동으로 선택이 되며, 이것은 백업 작업을 만든 후 Storage account을 쉽게 지울수 없도록 Lock을 하는 기능이다.
이제 Backup Policy를 만들 차례이다. 나는 기본적으로 30일 동안 daily 백업을 하고, 12 weekly 백업을 설정할 계획이다.
Eanble backup을 하면 백업이 시작된다. 이제 다시 Recovery Services Vaults로 가서 Backup Policies를 선택하면, 우리가 만든 백업 policy (30day+3month)가 보일 것이다. 이제 하루가 지난 후 Backup items로 가보면 Azure File Share가 백업된 것을 확인할 수 있다. 아래의 그림에서는 Azure Storage (Azure Files) 1 이라고 확인이 가능하다.
이것으로 Azure File Backup은 마쳤다. Backup을 매일 자동으로 이루어지겠지만, 백업이 제대로 되었는지 확인할 방법은 매번 Portal에 접속을 해야한다. 이것을 단순화 하기 위해서 Backup Report 기능을 사용해보자. Backup Report 중 email notification 기능은 백업이 제대로 되었는지 확인할 수 있는 가장 간단한 방법 중에 하나이다.
Azure Backup Report 을 이메일로 받기 위한 환경 먼저 구축하기
Backup Report을 이메일로 받기 전에 생각해볼 문제가 Log이다. Azure Backup Report는 하나의 기능이 아니고, Log Analytics Workspace와 Azure Monitor Log의 기능을 합쳐서 만들어진다. 그렇기 때문에 우선 Backup report을 살펴보기 전에 Azure Storage Log와 Azure Recovery Services Vaults을 Log Analytics Workspace로 보내는 작업이 우선시되어야 한다.
쉽게 설명하자면, Storage Account와 Recovery Services Vaults의 모든 로그를 Log Analytics Workspace로 보내고 이곳에서 Log를 통합 정리를 하는 것이다. 이 로그 중 Azure File 백업이 일어날때, Log Analytics Workspace에서 필터링해 이메일로 보내주는 방법이다. Automation을 통해서 Azure backup만이 아닌, 원하는 로그를 이메일과 연동시킬수도 있다. 예를들면, Azure File Share을 누군가가 실수나 고의로 지웠을 경우, Log Analytics Workspace에서 이것을 저장해놓았다가 이메일로 연동할수도 있다.
1. Storage Account와 연동할 Log Analytics Workspace을 만들어준다. Subscription, Resrouce Group, 그리고 Region은 Storage 어카운트와 동일하게 만들어준다.
2. Storage account - Diagnostic settings - Disabled을 Enable로 바꿔준다. 이를 위해서 File 옆에 Disabled을 선택해준다.
3. 모든 Log와 Metrics을 선택하고, "Send to Log Analytics Workspace"를 선택하고 우리가 만든 ws를 선택해준다. 이렇게 함으로써 storage account의 File에 대한 모든 로그가 (Read/Write/Delete/Transaction) log analytics workspace로 전달되게 된다.
Log Analytics Workspace로 모든 로그가 전송되었다고 확인하는 방법은 아래 그림과 같이 File - Enabled 라고 되어 있나 확인하면 된다. Storage Account의 모든 로그를 Log Analytics Workspace로 보냈고, 이제 Recovery Services Vaults에 있는 모든 로그를 Log Analytics Workspace로 보낼 차례이다.
4. Recovery Services Vaults - Diagnostics Setting - Add Log Analytics Workspace 에서 우리가 만든 ws을 선택해준다.
5. Recovery Services Vaults의 모든 로그를 우리가 만든 Log Analystics Workspace로 보낸다. 이렇게 함으로써 모든 storage와 recovery services valuts의 로그가 Log Analystics Workspace에서 분석을 할 수 있게 되는 환경이 구축된 것이다.
6. 48시간이 지난 후에 Recovery Services Vaults의 Summary에서 백업이 되었다는 것을 확인할 수 있다. 이제 백업이 되는 것을 확인하였으니, 백업 리포트를 이메일로 전송하는 마지막 작업을 해보자.
Azure Backup Report 을 이메일로 받아보기
1. Backup Center로 이동 후, Backup reports를 선택한다. Overview를 선택하고 해당 Log Analytics Workspace을 선택한 후, Email Report를 클릭한다. 이때 Workspaces 선택을 하지 않으면 Email report 탭을 눌러도 아무런 화면이 보이지 않으니, 먼저 해당 Log Analytics Workspace를 선택해야 한다.
2. 이제 Logic App 이름을 넣어주고, 필요한 Subscription / Resource Group / Location을 선택한다. Email option으로는 Daily 그리고 이메일을 받을 주소와 제목을 적으면 된다.
3. Backup Report는 Azure Monitor Log와 Office 365을 연동해서 사용한다. 그렇기 때문에 API Authorize Connection을 셋업해주어야 한다. 이 셋업은 한번만 하면 되고, 그 이후로는 백업 리포트를 새로 만들때마다 다시 셋업을 해주지 않아도 된다.
4. Azure Logic App으로 이동한 후에 새로 Logic Apps을 만들어준다. 이때 Logic Apps 이름은 Azure File Share와 이름이 매칭되도록 한다. 예를들어 Azure File Share 이름이 ABCShare라면 Logic Apps은 ABCShare_LogicApp 이런 식으로 이름하여 나중에 구별하기 쉽도록 한다.
5. Logic Apps이 만들어 졌다면 API connections 탭으로 이동 Azure Monitor Log와 Office 365를 Authorize 해준다.
Authorizie 버턴을 누르면 이제 Logic App을 사용하여서 Backup Report Email을 받을 수 있는 환경이 만들어졌다.
Backup Email Template은 아래와 같다.
이제 이 모든 과정이 마쳤다면, 보안을 위해서 Public Access을 모든 Storage Account에서 차단한다. 이로써 File Share는 내부 사설망 혹은 VPN으로 연결이 되지 않을 경우, 어느 누구도 접속을 할 수 없게 된다.
이로써 Azure File Share에 대한 포스팅을 마치려고 한다.
'미국 IT 이야기' 카테고리의 다른 글
| Cisco AnyConnect 와 Azure AD를 SAML로 연동하기 (0) | 2022.07.05 |
|---|---|
| Microsoft 자격증 무료로 취득하기 (미국 IT이야기 17) (0) | 2022.06.14 |
| AWS Summit Washington D.C. 2022 후기 (미국 IT이야기 16) (0) | 2022.05.24 |
| 미국의 직장 문화 이해하기 (미국 IT이야기 15) (0) | 2022.05.22 |
| Azure 클라우드 서비스를 사용하는 이유 (미국 IT이야기 14) (1) | 2022.05.08 |
