달력

8

« 2025/8 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

Windows Server 2012 이상에서 클러스터를 구성하는 경우, 나름(?) 고급 설정에 포함될 수 있는 부분이 CSV 캐시동적 쿼럼 정도가 됩니다.


그런데 말입니다(음성 지원 되지요?).. Windows Server 2012 R2가 되면서 동적 쿼럼은 기본적으로 Enable로 설정되었기 때문에 별도로 설정을 하시지 않으셔도 됩니다.


궁금하시다면, 클러스터 구성 후 PowerShell에서 다음과 같이 클러스터 속성 값을 나열해 보시면 DynamicQuorum 값이 1(Enable)로 설정되어 있는 것을 확인할 수 있습니다. 사실 Disable 하는 메뉴는 GUI 상에서 찾을 수가 없더군요.



두 번째 항목으로 CSV 캐시가 있는데 기능도 마찬가지로 기본 값이 Enable되어 있으며, BlockCacheSize 값이 저의 경우 2,048(2GB)로 설정되어 있습니다. Microsoft에서 권장하는 구성으로는 Hyper-V 클러스터의 경우 512MB, 스케일 아웃 파일 서버 클러스터의 경우 R2 기준으로 물리 메모리 대비 최대 80%까지 설정 가능하며 '크면 클 수록 좋음' 입니다.


현재 CSV 볼륨들에 대한 CSV 캐시 설정 확인 (값이 1이면 Enable 상태입니다.)

Get-ClusterSharedVolume | Get-ClusterParameter | where {$_.Name -eq "EnableBlockCache"}



서론이 길었습니다. 말씀 드린 것처럼 Windows Server 2012 R2에서는 동적 쿼럼이 기본 값이기 때문에 별도로 설정하실 필요는 없으며, CSV 캐시의 경우 PowerShell에서 다음 명령으로 캐시 크기를 설정합니다.

(Get-Cluster).BlockCacheSize = <크기, 단위는 MB>


예들 들어, 메모리가 32GB인 스케일 아웃 파일 서버 클러스터 노드의 CSV 캐시 크기를 10GB로 설정하는 경우에는 다음과 같이 입력합니다.

(Get-Cluster).BlockCacheSize = 10240


잘 입력되었는지는 PowerShell에서 다음과 같이 입력해 확인합니다.

(Get-Cluster).BlockCacheSize



참고로, CSV 캐시는 CSV 볼륨마다 할당됩니다. 즉, CSV 캐시를 10GB로 설정했는데 CSV 볼륨이 두 개인 경우 10GB x 2 해서 클러스터 노드마다 20GB의 캐시가 할당되게 됩니다.



아래는, CSV 캐시의 Hit 상황을 모니터링할 수 있는 성능 카운터 정보입니다.



CSV 캐시(메모리)에서 가져오는 I/O

- Cache IO Read-Bytes

- Cache IO Read-Bytes/Sec

- Cache Read

- Cache Read/Sec


캐시에 없어 스토리지에서 가져오는 I/O

- Disk IO Read-Bytes

- Disk IO Read-Bytes/Sec

- Disk Read

- Disk Read/Sec


전체 I/O

- IO Read-Bytes

- IO Read-Bytes/Sec

- IO Read

- IO Read/Sec




:
Posted by 커널64
2016. 4. 2. 22:47

System Center 2012 R2 요구 사항 설치 Cloud2016. 4. 2. 22:47

System Center를 설치하다 보면 운영 체제 상의 요구 사항을 자동으로 설치해 주는 경우도 있지만 수동으로 설치해 주어야 하는 항목들도 있습니다. 아래는 Windows Server 2012 R2를 기준으로 일반적인 구성인 단일 서버에 모든 구성 요소를 설치하는 경우의 요구 사항을 설치하기 위해 필요한 PowerShell 명령어입니다.


PoC 또는 소규모 시스템에 대한 관리 인프라 구성 시 사용하시기 바랍니다.




공통 항목

.NET Framework 3.5 (Windows Server 2012 R2 설치 미디어가 D 드라이브에 있는 경우)

dism.exe /enable-feature /all /featurename:NetFX3 /online /Source:d:\sources\sxs /LimitAccess


NET Framework 4.6.1 (http://go.microsoft.com/fwlink/?LinkId=671744)



SCCM (Configuration Manager)

- 역할 및 기능

Install-WindowsFeature Web-Windows-Auth, Web-ISAPI-Ext, Web-Metabase, Web-WMI, BITS, RDC, NET-Framework-Features, Web-Asp-Net, Web-Asp-Net45, NET-HTTP-Activation, NET-Non-HTTP-Activ


- Windows 8.1 Update 용 Windows 평가 및 배포 키트(http://go.microsoft.com/fwlink/p/?LinkID=302319)

> 배포 도구, Windows 사전 설치 환경(Windows PE), 사용자 상태 마이그레이션 도구(USMT)



SCOM (Operations Manager)

- 역할 및 기능

Add-WindowsFeature Web-Server,Web-Request-Monitor,Web-Windows-Auth,Web-Asp-Net,Web-CGI,Web-Mgmt-Tools,NET-WCF-HTTP-Activation45,Web-Metabase


- Microsoft Report Viewer 2012 (http://go.microsoft.com/fwlink/?LinkId=327917)



SCAC (App Controller)

- 역할 및 기능

Add-WindowsFeature NET-Framework-Features,NET-Framework-Core,Web-Mgmt-Console,Web-Static-Content,Web-Default-Doc,Web-Http-Errors,Web-Http-Logging,Web-Request-Monitor,Web-Http-Tracing,Web-Stat-Compression,Web-Filtering,Web-Basic-Auth,Web-Windows-Auth,Web-ISAPI-Filter,Web-ISAPI-Ext,Web-Net-Ext,Web-Asp-Net45



SCO (Orchestrator)

- 역할 및 기능

Add-WindowsFeature Web-Server,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Digest-Auth,Web-Windows-Auth,Web-Net-Ext,Web-Asp-Net,Web-CGI,Web-Mgmt-Tools,NET-WCF-HTTP-Activation45,NET-WCF-MSMQ-Activation45,NET-WCF-Pipe-Activation45,NET-WCF-TCP-Activation45,MSMQ,RDC,WAS



SCVMM (Virtual Machine Manager)

- Windows 8.1 Update 용 Windows 평가 및 배포 키트 (http://go.microsoft.com/fwlink/p/?LinkID=302319)

> 배포 도구, Windows PE(Windows 사전 설치 환경)





:
Posted by 커널64

기존 물리적인 서버를 가상화 환경으로 변환하는 P2V 작업은 서버 가상화 프로젝트를 하시면서 늘 있는 일입니다.


그런데, 몇몇 서버들의 경우 기본 설정이 BIOS가 아닌 UEFI로 설정되어 있어 담당자도 모르게 Windows 서버가 UEFI 모드에서 실행되고 있는 경우, MS에서 제공하는 MVMC는 P2V 작업 자체가 진행되지 않으며, disk2vhdVMware Converter를 통해 이미징을 해서 Hyper-V 환경으로 가져오더라도 부팅이 되지 않는 상황이 발생합니다.


참고: 노트북 BIOS 메뉴에서의 UEFI 설정 화면(서버의 경우에도 비슷한 메뉴가 있습니다.)



이러한 경우 다음과 같은 절차를 통해 UEFI 서버를 가상 환경으로 변환/마이그레이션 하실 수 있습니다.


1. 먼저 disk2vhd를 이용해 로컬 볼륨에 대한 이미징 작업을 진행합니다.

https://technet.microsoft.com/en-us/sysinternals/ee656415.aspx


2. 생성된 가상 디스크 파일(VHDX)을 마운트합니다.


3. AOMEI Partition Assistant 등의 파티션 도구를 이용해서 이미징 작업을 수행한 부트 볼륨에 대해

   - MBR 디스크로 변환하고,

   - EFI 파티션과 시스템 예약 파티션을 삭제한 후

   - 부트 파티션을 활성(Active)으로 설정합니다.


4. 일반적으로 위와 같은 작업을 진행한 후 1세대 VM으로 생성해 디스크를 연결하면 부팅이 됩니다.

만약, 위와 같이 진행 후 커서만 깜빡 거리고 부팅이 되지 않는다면 BCD를 재생성해야 합니다.


5. BCD 재생성은 Windows PE로 부팅하거나, Windows 설치 미디어로 부팅 후 복구 모드에서 명령 프롬프트를 실행한 후 다음 명령을 통해 진행합니다.

bootrec /fixmbr 

bootrec /fixboot 

bootrec /rebuildbcd







:
Posted by 커널64
2016. 4. 1. 12:13

AWS 서울 리전 신규 서비스 출시 소식 Cloud2016. 4. 1. 12:13

아마존 웹 서비스(AWS)에서 생각보다 빠르게 서울 리전에 대한 서비스를 추가해 나가고 있습니다.


AWS에서 발생하는 모든 변경 사항을 추적하고 로깅하는 서비스인 AWS Config를 이제 서울 리전에서도 사용할 수 있으며,

아직 도쿄 리전에서도 제공되지 않는 MS SQL의 RDS 서비스에 대한 Multi-AZ(이중화)를 지원합니다. (와우~!) 


그리고, AWS의 말을 빌리면 'MySQL과 완벽한 호환성을 제공하면서 5배의 성능을 제공한다'고 하는 Aurora RDS 서비스도 서울 리전에서 사용할 수 있게 되었습니다.



위에 언급한 서비스들은 지금 바로 사용이 가능합니다.




자세한 내용은 아래 링크를 참고하세요.



AWS Config, 서울 리전 출시!

https://aws.amazon.com/ko/blogs/korea/aws-config-launches-in-asia-pacific-seoul/


Amazon RDS for SQL Server, 다중-AZ 미러링 기능 서울 리전 지원!

https://aws.amazon.com/ko/blogs/korea/amazon-rds-for-sql-server-add-mirroring-support-seoul-region/


Amazon Aurora, 서울 리전 출시!

https://aws.amazon.com/ko/blogs/korea/amazon-aurora-now-available-in-seoul-region/



:
Posted by 커널64

HAProxy는 L4/L7 로드 밸런서 역할을 해주는 오픈 소스 소프트웨어입니다.

성능 또한 나쁘지 않기 때문에 물리적으로 로드 밸런서를 둘 수 없는 상황이라면 좋은 대안이 될 수 있을 것 같습니다.


저는 개인적으로 Linux 환경에 익숙하지 않은데, 저와 같은 분들을 위해 설치 절차를 정리해 공유합니다.


먼저, 테스트 시스템 환경은 다음과 같습니다.


- HAProxy VIP: 192.168.0.150

- HAProxy #1: 192.168.0.151

- HAProxy #2: 192.168.0.152


- Web Server #1: 192.168.0.153

- Web Server #2: 192.168.0.154



1. CentOS 7을 설치합니다. 저의 경우 최소 설치 모드로 설치한 후 SELINUX를 Disable 하였습니다.

vi /etc/sysconfig/selinux

SELINUX=disabled


2. 두 HAProxy 서버에 HAProxy와 keepalived 패키지를 설치합니다.

yum install -y haproxy keepalived


3. 먼저, keepalived를 설정하겠습니다. 원본 설정 파일을 복사해 새 설정 파일을 만듭니다.

cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.origin


4. 텍스트 편집기로 /etc/keepalived/keepalived.conf 설정 파일을 엽니다.

vi /etc/keepalived/keepalived.conf


5. 메일 알림 관련 설정은 삭제합니다.

global_defs {

   notification_email {

   }

}


6. virtual_ipaddress 항목을 VIP로 설정하고, 아래의 나머지 설정들은 삭제합니다. MASTER 서버는 state MASTER, priority 200, BACKUP 서버는 state BACKUP, priority 100으로 설정합니다.

vrrp_instance VI_1 {

    state MASTER

    interface eth0

    virtual_router_id 51

    priority 200

    advert_int 1

    authentication {

        auth_type PASS

        auth_pass 1111

    }

    virtual_ipaddress {

        192.168.0.150

    }

}


7. 두 HAProxy 서버에서 keepalived를 실행합니다.

service keepalived start


8. 간단히 테스트를 위해 VIP로 ping으로 테스트해 본 결과 MASTER에서 BACKUP으로의 Failover 시에는 ping이 적게는 1개, 많게는 3개가 빠지는 것으로 확인되었으며, BACKUP에서 다시 MASTER로의 Failback 시에는 ping loss 없이 되는 것을 확인할 수 있었습니다.




여기까지는 HAProxy 서버에 대한 이중화를 위한 구성이었으며, 이제부터의 작업은 실제 로드 밸런싱을 처리하는 패키지인 HAProxy에 대한 설정을 설명합니다.


HTTP 및 TCP에 대한 로드 밸런싱이 가능하기 때문에 필요에 따라 여러 서비스(DB, Redis 등)에 대한 부하 분산 용도로 사용이 가능합니다만, 여기서는 일반적으로 웹 서버에 대한 부하 분산 설정으로 구성합니다.


또한, 단순히 HTTP 요청(TCP 80)을 Backend 서버로 전송하도록 설정하는 경우에는 웹 서비스마다 HAProxy를 두어야 하는 상황이 될 수 있기 때문에 요청 주소에 따라 분기하도록 하고, 쿠키를 사용한 Sticky Session 설정을 한 구성입니다.



9. 원본 파일은 복사해 둔 후 HAProxy 설정 파일을 텍스트 편집기로 엽니다.

cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.origin

vi /etc/haproxy/haproxy.cfg


10. 아래는 호출한 도메인에 따라 두 대의 Backend 서버로 각각 분기하는 예제입니다. 

global

    log           127.0.0.1 local2

    chroot      /var/lib/haproxy

    pidfile       /var/run/haproxy.pid

    maxconn 100000

    user        haproxy

    group      haproxy

    daemon

    stats socket /var/lib/haproxy/stats


defaults

    mode                    http

    log                     global

    option                  httplog

    option                  dontlognull

    option http-server-close

    option forwardfor       except 127.0.0.0/8

    option                  redispatch

    retries                 3

    timeout http-request    10s

    timeout queue           1m

    timeout connect         10s

    timeout client          1m

    timeout server          1m

    timeout http-keep-alive 10s

    timeout check           10s

    maxconn                 3000


#-------- Custom Error Page

#    errorfile 400 /etc/haproxy/errors/400.html

#    errorfile 403 /etc/haproxy/errors/403.html

#    errorfile 408 /etc/haproxy/errors/408.html

#    errorfile 500 /etc/haproxy/errors/500.html

#    errorfile 502 /etc/haproxy/errors/502.html

#    errorfile 503 /etc/haproxy/errors/503.html

#    errorfile 504 /etc/haproxy/errors/504.html



#------- Main Frontend

frontend   http *:80

#-- redirect http to https     

#   redirect scheme https if !{ ssl_fc }

    acl host_name1 hdr(host) -i naver.com www.naver.com

    acl host_name2 hdr(host) -i daum.net www.daum.net


    use_backend webfarm1 if host_name1

    use_backend webfarm2 if host_name2


#------- Web Farm #1

backend webfarm1

    mode http

    balance roundrobin

    option httpchk GET / HTTP/1.0

    option log-health-checks

    option forwardfor

    option httpclose

    cookie SERVERID insert indirect nocache

    stats enable

    stats uri /haproxy

    server node1 192.168.0.153:8081 cookie node1 check inter 1000 rise 3 fall 3

    server node2 192.168.0.154:8081 cookie node2 check inter 1000 rise 3 fall 3


#------- Web Farm #2

backend webfarm2

    mode http

    balance roundrobin

    option httpchk GET / HTTP/1.0

    option log-health-checks

    option forwardfor

    option httpclose

    cookie SERVERID insert indirect nocache

    stats enable

    stats uri /haproxy

    server node1 192.168.0.153:8082 cookie node1 check inter 1000 rise 3 fall 3

    server node2 192.168.0.154:8082 cookie node2 check inter 1000 rise 3 fall 3


11. 구성 파일을 저장한후 각각의 HAProxy 서버에서 서비스를 시작 후 정상적으로 시작되었는지 확인합니다.

service haproxy start

systemctl status -l haproxy.service

12. 부팅 시 각각의 서비스가 시작되도록 설정합니다.

systemctl enable keepalived

systemctl enable haproxy


13. 이제 테스트를 위해 Windows 클라이언트에서 HOSTS 파일에 daum.net과 naver.com에 대한 IP 주소를 HAProxy의 VIP로 설정한 후 테스트해 정상적으로 부하분산이 되는 것을 확인하였습니다. Fiddler로 요청을 확인해 보면 아래와 같이 Cookie 정보를 받아오는 것을 확인할 수 있습니다.



14. 설정에 따라 /haproxy 페이지로 이동하면 전체적인 노드 응답 상태, 요청 수 등의 상황을 확인할 수 있습니다.




전체 설정 옵션은 아래 링크를 참고하세요.

http://cbonte.github.io/haproxy-dconv/configuration-1.5.html




HAProxy_cfg_L4_PortOnly.txt


HAProxy_cfg_L7_Hostname.txt








:
Posted by 커널64
2016. 3. 29. 20:24

AWS Auto Scaling의 기본 Termination 정책 Cloud2016. 3. 29. 20:24

AWS의 서비스 중 부하에 따라 L4 하단 노드(서버)를 자동으로 증가(Scale out) 또는 축소(Scale in) 시키는 Auto Scaling이라는 좋은 기능이 있습니다. 그런데, Scale in 발생 시 어느 노드를 선택해 중지(Termination) 시킬까요?




기본적으로, 가용성을 최우선 순위로 하며, 순서적으로 정리하면 다음과 같습니다.

Scale-in 이 발생할 때의 순서이며, 해당하는 EC2 인스턴스가 하나이면 종료됩니다.


1) 다중 가용존(Muliple AZ) 구성의 경우, EC2 인스턴스가 가장 많은 AZ 선택

2) 가장 오래된 Launch Configuration으로 구동된 EC2 인스턴스(들) 선택

3) 구동 시간 기준으로 다음 과금 시간에 가장 가까운 EC2 인스턴스(들) 선택

4) 위 과정을 거쳤으나 선택된, 해당되는 EC2 인스턴스가 여러 개일 경우 무작위 선택




:
Posted by 커널64

On-premise의 AD를 원본으로 두고 Azure AD Connect(구. DirSync)를 통해 Office 365를 사용하고 있는 경우, Office 365 상의 계정 정보는 Read-Only가 되므로, 계정 설정에 대한 변경 작업의 상당수는 동작하지 않습니다.


예를 들어, 다음과 같이 특정 계정 또는 그룹 계정을 '주소 목록에서 숨김' 기능을 사용하려고 하면 오류가 발생합니다.


한글

'OOOO' 개체는 온-프레미스에서 동기화되고 있으므로 작업 'Set-DistributionGroup', 'HiddenFromAddressListsEnabled'은(는) 해당 개체에서 수행할 수 없습니다. 이 작업은 온-프레미스 조직의 개체에 대해 수행해서는 안 됩니다.


영문

The action 'Set-DistributionGroup', 'HiddenFromAddressListsEnabled', can't be performed on the object 'OOOO' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.



이러한 경우, On-Premise AD에 대한 속성 MsExchHideFromAddressLists 값을 TRUE로 설정한 후 동기화되도록 해야 합니다.


그런데, 현재 On-premise 환경에는 Exchange 인프라가 없는 상태입니다.

그렇기 때문에 MsExchHideFromAddressLists 속성 자체가 없는 상태입니다.


이와 같이 현재 On-premise에 Exchange 인프라가 없는 경우 다음 절차를 참고해 진행합니다.



1. Exchange Server의 설치 미디어를 준비합니다. 체험판도 상관없습니다.

http://www.microsoft.com/download/en/details.aspx?id=21570


2. 압축을 해제하고 Enterprise Admins 및 Schema Admins 구성원 계정으로 다음 명령을 실행하고 기다립니다.

Setup /PrepareSchema


3. 명령이 정상적으로 수행된 것을 확인한 후 ADSI 편집기 또는 ADUC의 View -> Advanced Features 체크 후 계정의 속성 창을 열어 속성 편집기 탭에서 필요한 속성을 수정하실 수 있습니다.




:
Posted by 커널64
2016. 3. 22. 12:48

AWS Storage Gateway 서울 리전 서비스 개시 Cloud2016. 3. 22. 12:48

AWS Storage Gateway 서비스를 이제 서울 리전에서도 사용하실 수 있습니다.

Storage Gateway 서비스는 데이터센터 내에서 VM의 형태로 운영되며, iSCSI 스토리지로 보여지게 되며, 이에 대한 데이터는 AWS의 S3 및 Glacier에 저장되어, 사실상 무제한 용량의 스토리지를 제공하는 구성입니다.


아래는 원문입니다.



AWS Storage Gateway는 기존 데이터 센터의 소프트웨어 저장 장치를 클라우드 기반 스토리지에 연결하는 서비스로서,  기존 IT 환경과 AWS 스토리지 인프라를 원활하고 안전하게 통합할 수 있게 해줍니다.


오늘 부터 Asia-Pacific (Seoul) 리전에서 사용할 수 있게 되었습니다.


스토리지 게이트웨이 서비스를 통해 확장 가능하고 비용 효율적인 스토리지인 AWS 클라우드에 데이터를 안전하게 저장할 수 있습니다. 기존 애플리케이션과 연동되는 업계 표준 스토리지 프로토콜을 지원하며, 자주 사용하는 데이터를 온프레미스로 유지함과 동시에 모든 데이터를 암호화하여 Amazon Simple Storage Service(S3) 또는 Amazon Glacier에 안전하게 저장합니다.


AWS Storage Gateway는 다음 세 가지 구성을 지원합니다.


게이트웨이 캐싱 볼륨: 기본 데이터는 Amazon S3에 저장하고 자주 사용하는 데이터는 로컬에 보관할 수 있습니다. 게이트웨이 캐싱 볼륨은 기본 스토리지에서 상당한 비용 절감을 제공하며, 온프레미스로 스토리지를 확장할 필요성을 최소화하고 자주 사용하는 데이터에 대해 지연 시간을 짧게 유지합니다.


게이트웨이 저장 볼륨: 전체 데이터 세트에 접근 시 지연 시간이 짧아야 하는 경우 기본 데이터를 로컬에 저장하도록 온프레미스 데이터 게이트웨이를 구성하고 이 데이터의 특정 시점 스냅샷을 비동기적으로 Amazon S3에 백업할 수 있습니다. 게이트웨이 저장 볼륨은 예를 들어 재해 복구를 위한 교체 용량이 필요한 경우 로컬이나 Amazon EC2에서 복구할 수 있는 안정적이고 저렴한 오프사이트 백업을 제공합니다.



게이트웨이 가상 테이프 라이브러리(VTL): 게이트웨이 VTL을 사용하면 가상 테이프 컬렉션을 무제한으로 보유할 수 있습니다. 각 가상 테이프는 Amazon S3에서 지원하는 가상 테이프 라이브러리나 Amazon Glacier에서 지원하는 가상 테이프 쉘프(VTS)에 저장할 수 있습니다.

가상 테이프 라이브러리는 백업 애플리케이션이 가상 테이프에 온라인으로 액세스할 수 있도록 업계 표준 iSCSI 인터페이스를 제공합니다. 가상 테이프에 포함된 데이터에 더 이상 즉시 또는 빈번하게 액세스할 필요가 없는 경우 스토리지 비용을 더 줄일 수 있도록 백업 애플리케이션을 사용하여 데이터를 가상 테이프 라이브러리에서 가상 테이프 쉘프로 이동할 수 있습니다.


좀 더 자세한 것은 AWS Storage Gateway를 통한 기존 IT 환경의 스토리지와 통합 사례 및 기술 문서를 참고 하시기 바랍니다.




출처: https://aws.amazon.com/ko/blogs/korea/aws-storage-gateway-available-in-seoul-region





:
Posted by 알 수 없는 사용자
2016. 3. 11. 13:26

AWS 인증서 서비스 출시 소식 Cloud2016. 3. 11. 13:26

일반적으로, 웹 서비스에 대한 암호화를 위해 즉, HTTPS로 통신하기 위해 SSL/TLS 인증서를 베리사인, 코모도 등의 공인 인증서를 1년마다 발급(돈내고 사는 거죠.)받아 운영해 오셨을 겁니다.

 

인증서를 발급 받으면 웹 서버에 적용하는 작업과 1년마다 이 작업을 반복해야 하는 번거로움이 있으셨을 겁니다.


때로는, 인증서 갱신 시점을 놓쳐 장애(?)까지는 아니더라도 상사의 꾸사리를 들으시는 경우도 있으시지요.

 

이젠 이런 번거로움과 비용을 들이지 않고도, Amazon의 인증 기관을 이용해 손쉽게 서비스를 암호화하고 자동으로 갱신되도록 할 수 있는 서비스가 AWS에서 출시되었습니다.

 

 

개념은 이렇습니다.


아마존의 인증 기관인 Amazon Trust Services (ATS)에서 인증서를 발급한 후 인증서를 AWS의 로드 밸런서인 ELB 및 CDN 서비스인 CloudFront에 지정할 수 있습니다. SSL Offload 기능을 통해 뒷 쪽은 HTTP 통신을 하도록 합니다.


이렇게 할당된 인증서는 자동으로 관리, 갱신되어, 운영자 입장에서는 인증서 관련해서는 잊으셔도 되는 것이지요.

 

현재는 아쉽게도 US East (Northern Virginia) 리전에서만 지원됩니다.

한국 리전에서도 빨리 사용할 수 있길 바랍니다.


자세한 내용은 아래의 링크를 참고하세요.

https://aws.amazon.com/ko/blogs/korea/new-aws-certificate-manager-deploy-ssltls-based-apps-on-aws/

 

 

:
Posted by 알 수 없는 사용자