1. Azure Virtual Machines 소개

Azure 가상 머신을 만들기 위한 검사 목록 컴파일

온프레미스 - Azure 마이그레이션 시,

• 한번에 모두 전송
• 조금씩 전송 두 가지 방법이 있음. 일단 마이그레이션 하려면 VM을 만들어야 하잖아? 그 전에, 현재 온프레미스 인프라가 어떻게 생겼는지 파악하며 지도를 그리고 이 지도를 바탕으로 클라우드에 옮기는 방법을 생각해봐야 함.

Azure 리소스란?

“리소스는 Azure에서 관리할 수 있는 항목임” … 이라고 설명하는데. 걍 Azure에서 제공하는 서비스의 최소 단위라고 봐도 됨.

온프레미스의 물리적인 ‘컴퓨터’를 사용하려면 전기, 본체, (키보드, 모니터 등의)입출력장치가 필요한 것 처럼 VM을 사용할 때도 몇 가지 필요한 것들이 있음.

• VM
• 스토리지 디스크
• VNet
• Network Interface
• NSG
• IP Addr(Public, Private 모두)

사용자의 필요에 따라 Azure에서 위 모두를 만들 수도 있고, 사용자가 쓰던걸 써도 됨. 선택적으로 Azure에서 쓰면 된다는 뜻.

위와 같은 VM을 비롯한 모든 Azure 리소스는 이름이 필요함. Azure에서 VM을 만들면 VM의 이름으로 리소스 이름을 만들어버림. 따라서 VM의 이름과 리소스의 이름은 같아야 함!

IaaS Virtual Machines에 필요한 리소스

VM을 만들 때 고려해야 할 것들에 대해 자세히 살펴보자.

네트워크

VM 보다 네트워크를 가장 먼저 고려해야 함. 왜냐? 일단 온프레미스 서버를 보자.

• 서버가 무엇과 통신하냐?
• 어떤 포트가 열리냐?

VNet은 Azure에서 VM과 다른 서비스 사이에 Private 연결을 제공하기 위해 사용됨.

같은 VNet에 속한 VM과 서비스들은 서로 접근 가능함. VNet의 외부에서는 내부로 접근이 불가능함. 하지만 우리는 (온프레미스 서버 등의)외부 서비스가 접근할 수 있었으면 좋겠음. 이게 우리가 네트워크를 우선으로 고려해야 하는 이유임.

IP Addr, Subnet은 설정 후에 변경이 어려움. 온프레미스 Private network를 Azure 서비스에 연결하려면 VM 배치 전에 토폴로지를 고려해야 함.

VNet 설정할 때 먼저 ‘사용 가능한 주소 공간’, subnet, ‘보안’을 지정함. VNet이 다른 VNet과 연결되는 경우에는 주소 범위가 겹치면 안됨. 여기서 말하는 범위란?

• 네트워크 안에 있는 VM의 범위
• 서비스에서 사용할 수 있는 Private Addr의 범위

이것임. 가상머신 끼리 범위가 겹쳐져서도 안되고, 가상 네트워크의 서비스끼리도 겹치면 안됨. 아무튼 겹치면 안됨. 그야 겹쳐버리면 잘못된 주소로 잘못된 접근이 생기니 사고가 발생하니까. 주소 범위를 겹치지 않기 위해 할 수 있는 것들은 다음과 같음.

• 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 등의 ‘라우팅 불가능한 IP주소’ 사용
• 고유한 범위 정의

Azure는 VNet 내부,
서로 연결된 VNet 내부 , 온프레미스 에서만 연결 가능한 경우… 등의 모든 주소 범위를 Private VNet IP Addr 공간의 일부로 처리해버림. 만약 다른 사람과 함께 작업한다면? 주소 공간의 범위를 지정하기 전에 그 사람과 합의보고 안겹치게 해야겠지 ㅇㅇ.

네트워크 분리

VNet 주소 공간이 결정되면 subnet을 하나 이상 만들 수 있음. 예를 들자면, 10.1.0.0에 VM을 할당하고, 10.2.0.0에 백엔드를, 10.3.0.0에 SQL Server VM에 할당할 수 있음.

참고로 첫 4개의 IP주소와 마지막 IP주소는 Azure에서 사용해버리니까 주의하자. 아래는 참고만 할 것.

• 첫 번째 IP 주소: 네트워크 식별 주소
  • 서브넷 식별에 사용됨.
  • 예: 10.0.0.0 (서브넷이 10.0.0.0/24일 경우)
• 두 번째 IP 주소: Azure의 기본 게이트웨이 주소
  • 아웃바운드 네트워크의 경로를 제공하는 게이트웨이 IP.
  • 예: 10.0.0.1
• 세 번째 IP 주소: Azure 내부에서 예약
  • Microsoft 내부에서 네트워크 관리에 사용됨. 사용자는 접근할 수 없음.
  • 예: 10.0.0.2
• 네 번째 IP 주소: Azure 내부에서 예약
  • Microsoft 내부에서 네트워크 관리에 사용. 사용자는 접근할 수 없음.
  • 예: 10.0.0.3
• 마지막 IP 주소: 브로드캐스트 주소
  • 서브넷 내 모든 디바이스로의 메세징 용도로 사용됨. 표준 네트워크 프로토콜에서 이를 예약함.
  • 예: 10.0.0.255 (서브넷이 10.0.0.0/24일 경우)

네트워크 보안

기본적으로 서브넷 사이에서는 보안 경계가 없음. → 통신이 가능하다 근데 보안때문에 subnet 쓰는건데 통신 맘대로 되는게 맞냐? → NSG(Network Security Group) 설정

개별 VM 배포 계획

VM 이름 = PC 이름 이름은 나중에 변경이 어려웅니 신중하게 지어야 함. VM의 역할을 잘 파악할 수 있도록 의미있고 일관성있으면 좋겠지 ㅇㅇ. 아래는 이름에 포함되면 좋을 것들임.

요소	예제	참고
환경	dev, prod, QA	리소스 환경 식별
위치	eus(미 동부), jw(일본 서부) 등	리소스 배포 지역 식별
인스턴스	01, 02	인스턴스가 둘 이상 있는 리소스의 경우
제품 또는 서비스	service	지원하는 제품, 애플리케이션, 서비스 식별
역할	sql, web, messaging	리소스 역할 식별

예를 들어.. 미국 동부에서 호스트되는 첫 번째 개발 웹 서버? ⇒ deveus-webvm01 로 이름 지을 수 있음.

VM 위치 결정

여기서 위치는 말 그대로 위치임 ㅇㅇ 가상머신의 실제 물리적인 위치가 어디있느냐를 말함. 성능, 법률, 규정 준수, 세금 등을 고려하여 사용자에게 최대한 가깝게 배치할 수도 있음.

그럼 위치를 결정하는데 뭘 고려해야하냐?

• 위치에 따라 옵션 제한 가능성
  • 지역마다 사용 가능한 하드웨어가 있음
  • 마찬가지로 지역마다 사용 불가능한 구성이 있음
• 위치 간 가격 차이
  • 하려는 작업이 특정 위치에 있어야하는게 아니면 가장 싼 지역 찾아서 쓰면 개꿀

VM 크기 결정

VM의 이름도 정하고, 위치도 정했으면 이제는 크기를 정해야 할 차례임. Azure에서 VM의 처리 능력, 메모리, 스토리지 용량은 각자 독립적임. 대신 다양한 크기를 제공함. 원하는 작업에 따라 적절한 컴퓨팅, 메모리, 스토리지 정하면 됨.

이거 정하는 가장 좋은 방법이 있음. VM에서 실행될 프로그램(워크로드)의 유형을 생각해보자. Azure에서는 여러 워크로드 옵션이 있음. 아래에서 골라라.

옵션	설명
범용	균형잡힌 CPU-MEM 비율. 테스트, 개발, 중소형 DB, 중소규모 트래픽 웹 서버에 적합
컴퓨팅 최적화	높은 CPU-MEM 비율. 중간 규모 트래픽 웹 서버, 네트워크 어플라이언스, 일괄 처리 프로세스, 애플리케이션 서버에 적합
메모리 최적화	높은 CPU-MEM 비율. RDB 서버, 중대형 캐시, 메모리 내 분석에 적합
스토리지 최적화	높은 디스크 처리량, IO. DB 실행에 적합.
GPU	고급 그래픽 렌더링, 비디오 편집 전문. 딥러닝을 통한 모델 학습, 추론에 적합.
고성능 컴퓨팅	선택적으로 빠른 처리 가능한 네트워크 인터페이스 가짐. 가장 빠르고 강력한 CPU VM.

VM 만들 때 워크로드 유형을 필터링 할 수 있음. 여기서 본인이 선택하는 VM 크기는 서비스 비용에 직접적인 영향을 줌. 당연히 성능이 높아질 수록 가격도 높아지니 잘 생각하자.

크기를 변경해야 하는 경우 해결 방법

생각보다 더 많은 성능이 필요할 수 있잖아? 그럼 VM의 크기를 바꿔야지 ㅇㅇ. 현재 VM의 하드웨어 구성이 변경될 크기에서 별 문제가 없다면 조절 가능함. 업그레이드 뿐 아니라 다운그레이드도 가능. VM 크기 변경하는 기능 << VM 관리에 대한 민첩하고 확장성 있는 방식 제공.

Azure Portal에서는 (크기 변경이)가능한 선택지만 보여주기 때문에 더 명확하게 알 수 있음. CLI에서 안되는 크기로 변경하려고 하면 오류뜸. 변경 완료하면 VM이 자동으로 재부팅됨.

VM을 할당 취소하게 되면 실행중인 클러스터에서 제거됨. 따라서 VM을 중지하고 할당 취소한 후에 크기 변경해야 함.

만약 배포중인 VM의 크기를 바꾸면 자동으로 재부팅돼서 서비스 중지됨!!!! IP 주소 등의 설정이 변경될 수 있으니 주의할 것!!!!!

VM의 일부 및 요금 청구 방법

VM을 만들게 되면 이를 지원하는 리소스도 같이 만들게 됨. 자연스럽게 비용 또한 함께 늘거임. 자세한 사항은 여기의 표를 참고하면 됨. 근데 시험에는 크게 중요하지 않을 것 같음..

가격 책정 모델 이해

VM은 사실 비용이 두 가지 있음. 컴퓨팅 비용, 스토리지 비용임. 이 둘을 각자 독립적으로 확장하고 필요한 부분의 요금만 지불할 수 있음.

• 컴퓨팅 비용
  • 시간 당 가격으로 책정되지만 실제로는 분당 요금으로 청구됨.
    • VM 55분 배포 시 1시간이 아닌 55분에 대한 요금만 부과
    • 이 ‘시간 당 가격’은 VM 크기와 OS에 따라 다름.
      • Linux 기반은 무료, Windows VM은 유료
  • VM 중단하고 할당 취소 → 하드웨어 해제 → 컴퓨팅 요금 X
  • 두 가지 옵션 중 선택 가능
    • 종량제
      • 약정, 선불 없이 초단위 종량제 지불
      • 언제든지 시작/중지 가능, 용량 변경 가능
      • 단기 or 예측 불가능한 워크로드 실행 시 사용
        • ex) 빠른 테스트 수행, VM에서 앱 개발 등
    • 예약된 가상 머신 인스턴스 (RI, Reserved Virtual Machine Instance)
      • 지정한 지역에서 (최소)1년 or 3년간 VM 사전 구매
      • 선불 조건인 대신 종량제에 비해 최대 72% 저렴
      • 유연함: 조기 해지 수수료로 쉽게 교환하거나 반환 가능
      • 지속적인 실행이나 예산 예측이 필요한 경우 사용
• 스토리지 비용
  • 스토리지 요금은 별도임
  • VM의 상태와 무관함
    • VM 중지, 할당 취소 + 요금 청구 X ⇒ 그래도 스토리지 요금은 청구됨

VM에 대한 스토리지

모든 VM에는 둘 이상의 VHD(Virtual Hard Disk)가 있음. 하나는 OS 저장, 나머지는 임시 스토리지임. 앱 데이터 저장하려면 더 추가해야 함. 데이터를 다른 디스크로 분리하면 각자 독립적으로 관리 가능. VM에 연결할 수 있는 VHD의 최대 갯수는 VM 크기에 따라 결정됨. 일반적으로 vCPU 당 2개씩이라 보면 됨.

이 디스크에도 여러 유형이 있는데..

• Ultra Disk
  • IO 집약적 워크로드 (SAP)
  • 최상위 계층 DB (SQL, ORACLE 등)
  • 이외 다른 트랜잭션 집약적 워크로드
• Premium SSD v2 (preview)
  • 짧은 대기시간, 높은 IOPS 및 처리량이 지속적으로 요구되는 프로덕션
  • 성능에 민감한 워크로드
• Premium SSD (반도체 드라이브)
  • 프로덕션
  • 성능이 중요한 워크로드
• Standard SSD
  • 웹 서버
  • 적은 용량을 사용하는 엔터르파이즈 애플리케이션, 개발, 테스트
• Standard HDD
  • 백업, 중요하지 않거나 가끔 사용하는 것들

이 중에서 뭐 쓸지는 아래 표를 보면 됨. 각자 어떤 역할을 하는지만 보면 될 듯.

운영 체제 선택

Linux, Windows 등의 다양한 OS의 이미지를 제공함. OS 비용은 가격과 번들로 함께 제공되기 때문에.. 어떤 OS 쓰는지가 시간 당 컴퓨터 가격에 영향을 줄 수 있음.

기본 이미지 쓰기 싫으면 Azure Marketplace에서 찾아 쓸 수 있음. 예시를 들자면,, WordPress 사이트가 필요하다면 Linux 서버, Apache 웹 서버, MySQL DB, PHP로 구성되는데. 이거 하나하나 설치하고 구성하는 대신 Marketplace 이미지 써서 한번에 설치 가능.

만약 그래도 적절한 OS를 못찾으면 스스로 이미지를 만들고 VM 개발에 쓸 수 있음. 개발, 테스트에 사용할 개별적인 이미지를 만들 수도 있음. Azure Compute Gallery를 만들어서 여러 이미지를 관리하고 필요한 지역에 복제할 수도 있음.

Azure VM을 만들고 관리하는데 사용할 수 있는 옵션

Azure Portal로 VM같은 리소스 가장 쉽게 만들 수 있음. 근데 가장 효율적이고 빠른건 아님. 여러 리소스를 만들어야 하는 경우에는 언제 하나하나 다 입력할거임? 서로 다른 작업을 처리하는 수십개의 VM을 만들어보자.

일단 리소스 만드는 방법은 여러 가지가 있음.

• Azure 리소스 관리자 템플릿
• Azure PowerShell
• Azure CLI
• Azure REST API
• Azure Client SDK
• Azure VM 확장
• Azure Automation Service

리소스 관리자 템플릿

만약 똑같은 설정을 가진 VM을 만들고 싶다면? 그냥 VM 만드는건 참 비효율적이고 시간도 오래 걸림. 그래서 정확히 똑같은 VM 복사본을 만드는데 쓰기 위해 템플릿을 제공함.

Resource Manager 템플릿임. 배포해야 할 리소스를 정의하는 JSON 파일임. VM에 대한 리소스 템플릿을 만들 수 있음. VM 메뉴의 자동화 - 템플릿 내보내기 선택 ㄱㄱ

원하는 대로 작업 ㄱㄱ 이후 템플릿을 가져와 복제하면 인프라 복제가 쉬움. VM이름, 네트워크 이름, 스토리지 계정 이름 등등을 매개변수로 쓰자. 리소스 마다 각자 다른 매개변수를 써서 복제 ㄱㄱ

Azure CLI

스크립팅, CLI 상호작용을 위해 Azure CLI도 쓸 수 있음. Azure 리소스 관리를 위한 CLI임. Cloud Shell을 통해 Linux, macOS, Windows, 심지어 브라우저에서도 사용 가능.

az vm create \
	--resource-group TestResourceGroup \
	--name test-wp1-eus-vm \
	--image Ubuntu2204 \
	--admin-username azureuser \
	--generate-ssh-keys

Ruby, Python 등과 같은 다른 스크립팅 언어와 함께 사용 가능함. CLI로 VM 만드는 방법은 여기를 참고.

Azure PowerShell

일회성 대화형 작업 or 반복 작업 자동화에 적합함. New-AzVM cmdlet으로 Debian 기반 Azure VM 생성 가능함.

New-AzVM `
	-ResourceGroupName "TestResourceGroup" `
	-Name "test-wp1-eus-vm" `
	-Image Debian11 `
	-VirtualNetworkName "test-wp1-eus-network" `
	-SubnetName "default" `
	-SecurityGroupName "test-wp1-eus-nsg" `
	-PublicIpAddressName "test-wp1-eus-pubip" `
	-GenerateSshKey `
	-SshKeyName myPSKey
	-OpenPorts 22

위 처럼 다양한 매개변수 써서 최대한 많은 VM 구성 설정 가능. 대부분 매개변수는 기본값이 있으니까 필요한 매개변수만 쓰면 됨.

PowerShell에서 VM 만드는 자세한 내용은 여기를 참조.

Terraform

Azure에는 Terraform 공급자가 있음. Terraform으로 VM 만들고 관리 가능함. 클라우드 인프라 정의, 미리보기, 배포도 됨.

Terraform 쓰는 경우에는 HCL 구문으로 구성 파일 만듦. HCL 구문으로 클라우드 공급자(우리는 Azure임), 클라우드 인프라 구성 요소 지정 할 수 있음. 구성 파일을 만들고, 배포하기 전에 실행 계획을 생성해야 함. 이 실행 계획을 검토하고 이를 적용해서 인프라를 배포할 수 있음.

그냥 이런게 있는갑다 하면 될 것 같음. 자세한건 매나 여기를 참고할 것. (교재에서도 이렇게 링크 던져주고 끝남)

프로그래밍 방식 (API)

CLI로 간단한 스크립트 쓰려면 Azure PowerShell, Azure CLI가 맞음. 하지만 복잡한 로직에 큰 앱이 돌아가는 VM 만드는데는 다른 방법이 더 적합함.

Azure REST API

HTTP 메서드(GET, PUT, POST, DELETE, PATCH 등)로 VM 만들고 관리할 수 있음. ⇒ 개발자가 프로그래밍 방식으로 접근할 수 있음.

이제 링크는 생략할게요..

Azure Client SDK

REST API는 플랫폼과 언어에 구속되지 않음. 하지만 개발자들은 더 높은 추상화를 원함. 그래서 Azure Client SDK 있음. Azure REST API를 캡슐화 한 것임. 당연히 여러 언어와 프레임워크에서 작동함.

예를 들어… NuGet 패키지 Microsoft.Azure.Management.Fluent 를 사용하여 Azure VM을 만드는 C# 코드임.

var azure = Azure
    .Configure()
    .WithLogLevel(HttpLoggingDelegatingHandler.Level.Basic)
    .Authenticate(credentials)
    .WithDefaultSubscription();
// ...
var vmName = "test-wp1-eus-vm";
 
azure.VirtualMachines.Define(vmName)
    .WithRegion(Region.USEast)
    .WithExistingResourceGroup("TestResourceGroup")
    .WithExistingPrimaryNetworkInterface(networkInterface)
    .WithLatestWindowsImage("MicrosoftWindowsServer", "WindowsServer", "2012-R2-Datacenter")
    .WithAdminUsername("jonc")
    .WithAdminPassword("aReallyGoodPasswordHere")
    .WithComputerName(vmName)
    .WithSize(VirtualMachineSizeTypes.StandardDS1)
    .Create();

Azure Java SDK도 가능.

String vmName = "test-wp1-eus-vm";
// ...
VirtualMachine virtualMachine = azure.virtualMachines()
    .define(vmName)
    .withRegion(Region.US_EAST)
    .withExistingResourceGroup("TestResourceGroup")
    .withExistingPrimaryNetworkInterface(networkInterface)
    .withLatestWindowsImage("MicrosoftWindowsServer", "WindowsServer", "2012-R2-Datacenter")
    .withAdminUsername("jonc")
    .withAdminPassword("aReallyGoodPasswordHere")
    .withComputerName(vmName)
    .withSize("Standard_DS1")
    .create();

Azure VM 확장

VM 만들고 배포했는데 추가적인 설치가 필요할 수 있음. 자동으로 모니터링, 실행되는 특정 구성을 사용해보자. Azure VM 확장은 배포 후의 작업 구성과 자동화를 위한 애플리케이션임. 참고 링크는 생략함.

Azure Automation 서비스

원격 인프라 관리에 가장 중요한 것은 시간 절약, 적은 오류, 효율성 증가임. 인프라 서비스가 많다면 더 상위 수준에서 운영할 수 있는 Azure 고급 서비스 쓰는게 좋음.

Azure Automation으로 빈번하고, 시간 소모적이고, 오류가 발생하기 쉬운… 한마디로 노가다적인 작업을 쉽게 자동화할 수 있음. 프로세스 자동화, 구성 관리, 업데이트 관리가 여기에 포함됨.

• 프로세스 자동화
  • 데이터센터에서 발생 가능한 이벤트에 응답 가능한 감시자 작업 설정 가능
• 구성 관리
  • VM의 업데이트를 추적하고 필요에 따라 작업 수행 가능
  • Microsoft Endpoint Configuration Manager로 회사의 PC, 서버, 모바일 장치 관리 가능
    • 위 지원을 Azure VM으로 확장 가능.
• 업데이트 관리
  • VM에 대한 업데이트, 패치 관리
  • 업데이트 상태 평가, 설치 예약, 배포 결과 검토 → 업데이트 성공적인지 확인
  • 프로세스, 구성 관리 서비스 통합
  • Azure Automation 계정에서 VM 업데이트 직접 관리 설정 가능
  • Portal의 VM 창에서 단일 VM의 업데이트 관리 허용 가능

자동 종료

일정에 따라 VM 자동으로 종료 가능. VM이 필요없을 때 실행 안되도록 비용 절약 가능. 매일, 매주, 시간대 지정 등등… Azure Portal에서 작업 - 자동 종료 들어가봐라 설정 가능함.

Azure VM의 가용성 관리

가용성 = 얼마나 많이 쓸 수 있느냐 = 서비스가 중단되지 않고 얼마나 유지되냐 → SLA에서 명시해놓음.

VM을 관리: OS, 소프트웨어. + 가용성 관리 까지 포함임. 이 가용성을 위해 Azure에서 여러 서비스를 제공함. 이제 자세히 알아보자.

가용성이란?

가용성 = 서비스 사용 가능한 시간의 백분율. 몇% 쓸 수 있느냐임. 보통 웹 사이트 배포하면 100% 가용성을 생각하겠지?

Azure 사용 시 가용성 고려해야 하는 이유

Azure VM도 결국은 데이터센터 내부 물리적 서버에서 실행되는 것임. 우리 컴퓨터 가끔 오류나듯이 VM도 오류날 수 있음 (무적이 아님). 물리적 서버에서 오류나면 당연히 서버 VM도 오류나겠지. 이 경우에는 Azure가 VM을 정상적인 서버로 자동으로 이동시킴. 단, 몇 분 정도 걸릴 수 있으며 그동안 VM 못씀 ㅜ

Azure 자체의 정기 업데이트도 VM에 영향 줄 수 있음. 소프트웨어 업데이트도 있을 수 있고 하드웨어(데이터센터의 공사 등) 업그레이드가 있을 수 있음. 안정성과 성능 향상을 위해 업데이트는 필수적임 ㅇㅇ. 웬만하면 VM에 영향을 주지 않고 실행되지만.. 업데이트를 적용하기 위해 VM이 재부팅 될 수도 있음.

가용성 영역

AZ-900과 상당히 중복되는 내용임. 물리적으로 떨어진 다른 데이터센터라 보면 됨. Azure 지역 당 3개의 가용성 영역이 있음.

각 가용성 영역은 물리적인 서버, 네트워크, 소스, 냉각 장치가 있겠지. 이 가용성 영역들에 VM을 복제해서 쓰는 솔루션을 설계해놓음. 그래서 가용성 영역 하나가 망가져도 나머지 두 개의 가용성 영역에서 즉시 데이터를 그대로 쓸 수 있음.

VM 확장 집합

Azure VM 확장 집합

• VM 그룹 생성, 관리
• VM 인스턴스의 수 << 일정에 따라 자동으로 조정 가능
• 이점
  • 고가용성 제공
  • 다수의 VM을 중앙에서 관리 가능
• 비용 없음. 각 VM 인스턴스에 대해서만 비용 지불
• 여러 방식으로 배포
  • 여러 가용성 영역
  • 단일 가용성 영역
  • 단일 지역 등…
  • 오케스트레이션 모드에 따라 다름

Azure Load Balancer

Azure Load Balancer + (가용성 영역 or 가용성 집합) → 애플리케이션 복원력 극대화

Azure Load Balancer: 트래픽을 여러 VM에 분산. 표준 계층(??) VM의 경우 이미 포함되어 있음. → 모든 VM에 포함된 것은 아님.

Azure Storage 중복성

사고를 대비해서 Azure Storage는 항상 복사본을 여러개 생성함. 사고나 오류 생겨도 복구 가능한지 보는거임 ㅇㅇ.

사용할 때는 비용과 가용성 사이 균형이 중요함. 이 균형 이루는데 도움 되는 요소들은…

• 기본 지역에서 데이터 복제하는 법
• 지리적으로 멀리 떨어진 지역으로 데이터가 복제되는지(지진 등의 지역적 재해 예방)
• 복제된 데이터에 대한 읽기 권한 갖는 프로그램이 필요한지

위치 간 장애 조치 (failover)

인프라 복제로 failover 처리 가능함.

Azure Site Recovery

• 기본 사이트에서 보조 사이트로 워크로드 복제
• 기본 사이트에서 장애 생기면 보조 위치에서 장애에 대한 조치 함 → 중단 없는 접근 가능
• 복구 후에는 원래 위치로 돌아옴
• VM or 물리적 기기의 복제. 가동이 중단돼도 워크로드 계속 사용 가능

많은 이점이 있지만 제일 중요한 두개

• Azure를 복구 대상으로 사용함
  • 보조적인 물리적 데이터 센터 유지비용, 복잡성 없앨 수 있음
• 프로덕션 환경에 영향 없는 복구를 위한 failover를 아주 쉽게 테스트
  • 장애 조치 테스트 쉬움
  • failover 시도한 적 없음 = 재해 복구 계획이 없음

복구에는 PowerShell 스크립트, Azure Automation Runbook, or 수동 개입 단계 필요할 수 있음.

VM 백업

버그로 회사 데이터가 날라가든 뭐든 원인이 어떻든 간에 삭제된 것을 복구할 수 있어야 함. Azure Backup은 VM을 보호하는 서비스 기반 백업 제품임. 클라우드와 온프레미스 상관없이 보호함. 그래서 뭘 백업하냐?

• Windows OS 기기의 파일, 폴더
• 애플리케이션 인식 스냅샷 (볼륨 섀도우 복사본 서비스?)
• Microsoft 인기 워크로드 (SQL Server, SharePoint, Exchange 등)
• Azure VM에 대한 기본 지원
• Linux, Windows 10 Client machine

Azure Backup 사용의 장점

기존의 백업 솔루션이 Azure 플랫폼을 최대로 활용하는 것은 아니었음. → 비싸거나 비효율적이었음. 근데 Azure Backup은 훨 좋음. 다른 Azure 서비스랑 같이 쓰게 설계됐음. 뭐가 좋은지 보자.

• 자동 스토리지 관리
  • 백업 스토리지 자동 할당, 관리
  • 종량제 지불
• 무제한 크기 조정
  • 고가용성 제공: Azure의 성능, 확장성 사용
• 여러 스토리지 옵션
  • 지역 중복 스토리지 제공: 데이터 복사본을 로컬 중복 스토리지, 보조 지역에 복제
• 무제한 데이터 전송
  • 인바운드, 아웃바운드 데이터 무제한 전송
  • 전송되는 데이터에 요금 청구 X
• 데이터 암호화
• 애플리케이션 일치 백업
  • 복구 지점에 복원에 필요한 모든 데이터가 있음
• 장기 보존
  • 백업 데이터 보존 시간에 제한 없음

Azure Backup 사용

백업하려는 컴퓨터 각각에 다운로드하여 배포하는 여러 구성 요소 사용함. 배포 구성 요소는 보호 대상에 따라 달라짐.

• Azure Backup Agent
• System Center Data Protection Manager
• Azure Backup Server
• Azure Backup VM 확장

Recovery Services 자격 증명 모음 사용해 백업 데이터 저장. Azure Storage Blob가 백업 → 자격 증명 모음: 효율적, 경제적인 장기 스토리지 매체 백업 머신 선택, 백업 정책(스냅샷 수행 여부, 저장 기간 등) 정의 가능.