VMware ESXi에 설치된 LSI(Avago/Broadcom) 레이드카드 모니터링하기

 

물리 서버에 설치된 LSI 레이드 카드는 MSM(MegaRAID Storage Manager)를 통해서 모니터링이 가능합니다.

하지만,  OS로 ESXi를 사용한다면 MSM은 기본적으로 레이드 카드를 인식하지 못 합니다. 물론 ESXi도 레이드 카드의 정보를 불러오지 못합니다.
ESXi 호스트에 설치된 LSI 레이드 카드를 모니터링 하려면 먼저 LSI SMIS Provider를 설치해야 합니다.

1) https://www.broadcom.com/support/download-search 에서 적절한 카테고리를 선택한 뒤 키워드로 “SMIS”를 입력하면

Latest SMIS Providers라고 되어 있는 소프트웨어 패키지를 다운로드 할 수 있습니다.

2) ESXi 호스트에 이 vib를 설치합니다.

3) 호스트를 재부팅하고, ESXi 호스트의 방화벽을 비활성화합니다. (주의: 프로덕션 환경에서 방화벽을 비활성화하는 것은 위험할 수 있음)

이것으로 ESXi 호스트의 준비가 끝났습니다.

 

 

다음으로, 적절한 PC에 매니지먼트 프로그램을 설치해야 합니다.

2018년부터 MSM이 Deprecated 되고, 대신 LSI Storage Authority가 MSM을 대체하였습니다.

 

1) Broadcom 다운로드 페이지에서 LSA를 다운로드, 설치하고 localhost:2463으로 접속하면 LSA가 설치된 컴퓨터가 보일 것입니다.

2) 무시하고 Manual Discovery를 선택합니다.

3) 타깃 ESXi 호스트의 IP를 입력 후 Search를 클릭하면 호스트가 보일 것입니다. Add 버튼을 눌러 Remote Server 목록에 추가합니다.

4) Sign In을 눌러, 서버에 로그인합니다. 이 때 사용되는 인증은 ESXi의 인증과 동일합니다.

5) MSM과 비슷하게 LSI 레이드 카드를 원격으로 관리할 수 있습니다.

 

Appendix A. Troubleshooting

Problem) 정상적인 인증을 입력하였음에도 Error Code:65537 : Logon failure: unknown user name or bad password 이라는 메시지가 뜨며, 로그온이 되지 않는다.

Solution) “LSAService” 서비스를 재시작한다.

 

Appendix B. ESXi 방화벽 설정

ESXi의 방화벽은 로드될 때 /etc/vmware/firewall/에 있는 .xml 파일들을 전부 참조한다.

따라서 적당한 이름의 xml파일을 생성하고, 다음과 같이 입력하면 방화벽이 활성화 된 상태에서도 LSA를 사용할 수 있다.

 

ESXi 호스트의 방화벽 설정은 호스트가 재부팅되면 초기화되기 때문에, 이것을 영구적으로 적용하려면 커스텀 vib를 만들 필요가 있다.

이것은 추후 별도의 글을 통해 설명할 것이다.

PowerCLI OSCustomizationNicMapping Default Gateway 문제

VMware의 PowerCLI를 통한 deployment 기능 중 OS Customization이 있습니다.

웹 콘솔에서는 ‘VM 사용자 지정 규격’이라고 불리는 기능인데, VMware Tools가 설치된 VM을 대상으로 (일반적으로) 최초 부팅 때 어느 정도의 기본적인 설정을 적용할 수 있게 해 줍니다. 웹 콘솔에서는 유연성이 부족하여 사용하지 않았지만, PowerCLI를 사용한다면 아주 유연한 배포 스크립트를 작성할 수 있습니다.

그 중 네트워크 설정을 제어하는 OSCustomizationNicMapping에서 IpMode로 UseStaticIP를 사용할 경우, Default Gateway를 입력할 것을 요구하는 문제가 있습니다.

덕분에 기본적으로 제공하는 cmdlet은

1. 모든 NIC에 DHCP를 적용하거나
2. 하나의 NIC를 사용하고 고정 IP를 할당하거나
3. DHCP와 고정 IP를 섞어서 사용하되, 디폴트 게이트웨이는 고정 IP의 것을 사용하거나

라는 세가지 케이스에 한해 사용할 수 있습니다.

대체 왜 이렇게 구현해뒀는지 도무지 이해를 할 수가 없습니다.

저는 고정 IP 하나를 사용하고, DHCP를 통해 디폴트 게이트웨이를 가져와야 했으므로, 하위 클래스를 통해 직접 CustomizationSpec 객체를 생성하였습니다.

기본적인 틀은 VMware Forum의 글에서 확인하실 수 있으며, Windows가 아닌 리눅스 시스템에 적용하기 위한 차이점, DHCP 할당을 위한 설정을 언급하도록 하겠습니다.

1. 리눅스 VM에 적용하기 위한 설정

– $item.Info.Type 을 “Windows”에서 “Linux”로 변경합니다.
– $item.Spec.Identity = New-Object VMware.Vim.CustomizationSysPrep 대신 $item.Spec.Identity = New-Object VMware.Vim.CustomizationLinuxPrep을 사용합니다.
– 리눅스 VM에서는 윈도의 Workgroup, FullName 대신 Domain을 반드시 입력해야 합니다. 따라서 $item.Spec.Identity.domain을 입력해 줍니다.
– $item.Spec.Identity.hostName을 반드시 입력해야 하는데, 요구하는 Type이 String이 아닙니다.
$LinuxPrepName = New-Object VMware.Vim.CustomizationFixedName
$LinuxPrepName.Name = <String>
$item.Spec.Identity.hostName = $LinuxPrepName

으로 입력해 줍니다.

2. DHCP IP 할당

$nic = New-Object VMware.Vim.CustomizationAdapterMapping
$nic.Adapter = New-Object VMware.Vim.CustomizationIPSettings
$nic.Adapter.Ip = New-Object VMware.Vim.CustomizationDhcpIpGenerator
$item.Spec.NicSettingMap += $nic

이제 원하는 OS Customization Spec을 생성할 수 있습니다.

Avago 530-8i를 LSI 9408-8i로 크로스플래싱 하기

Avago 530-8i는 LSI SAS3408 칩을 사용한 컨트롤러로, 12G SAS HBA 모델입니다.

같은 LSI SAS3408 칩을 사용한 LSI 9400-8i는 SFF-8643 케이블을 이용하여 NVMe U.2 SSD를 연결할 수 있습니다.
LSI에서는 이것을 Tri-Mode라 부르는데, 당연히 엔트리 OEM 모델에는 제공되지 않는 기능입니다.

 

지금부터 이 엔트리 HBA 카드를 LSI 9400-8i로 크로스플래싱 하여 Tri-Mode를 지원하도록 만들어 보겠습니다.

 

먼저 다음과 같은 준비물이 필요합니다.

1. UEFI를 지원하는 컴퓨터
2. EFI Shell 부트 USB
3. StorCLI for EFI
4. 카드의 SAS Address
5. LSI 9400-8i 펌웨어
6. 점퍼 케이블

 

3, 5번의 파일은 여기서 다운로드 할 수 있고,

530-8i의 경우 이렇게 포트 위에 스티커로 SAS Address가 적혀 있습니다.

만약 SAS Address가 별도로 표기되어 있지 않다면 storcli /c<x> show sasadd 명령어로 SAS Address를 확인할 수 있습니다.

 

1. 필요한 것들이 모두 준비되었다면 다음과 같이 J4 점퍼를 연결하여 주십시오.

J4 점퍼 핀을 쇼트시키는 것으로 SBR 모드에 진입, 플래시를 강제로 입힐 수 있게 됩니다.

 

2. EFI Shell에서 다음과 같은 명령어를 입력합니다.

 

3. 전원을 끄고 점퍼를 제거합니다. 재부팅 후 EFI Shell에서 다음과 같은 명령어를 차례로 입력합니다.

 

이것으로 크로스 플래싱 작업을 모두 마쳤습니다.

이 가이드는 ServeTheHome 포럼의 한 스레드에서 얻은 정보를 토대로 작성되었습니다.
귀중한 정보를 공유해 준 iblik.94에게 감사의 인사를 보냅니다.

KCSC, Warning.or.kr에 적용된 필터링 방법과 사설

 

본래 방송통신심의위원회는 한국에서 ‘불법’으로 규정하는 사이트에 대한 접근을 차단하기 위하여 DPI 기반의 필터링을 도입합니다.
이 장비는 HTTP Request의 헤더를 분석하여 Host 필드의 값이 특정 도메인이라면 302 Redirect를 전송, warning.or.kr로 보내버립니다.

이 시스템은 2006년부터 동작하기 시작했는데, 이 시점에서 이미 기본권 침해 논란이 불거지기 시작하였습니다.
비록 Host 필드만을 확인하는 것이지만, 마음만 먹으면 특정 IP에서 어떠한 사이트에 들어갔는지 리스트를 작성할 수 있기 때문입니다.

사용자들은 이에 대응하여 DPI 장비가 필터링하지 못하도록 Host 필드의 뒤에 \n을 추가하거나, Host 대신 HoSt를 사용하는 등, HTTP 표준에는 부합하지만 DPI 장비의 필터에는 걸리지 않는 Request를 생성하여 우회하였습니다.

물론 KCSC가 DPI 장비를 개량하면서 다시 막혔습니다.

 

그러다 많은 사이트들이 HTTPS를 기본 지원하게 되면서, 기존의 HTTP 헤더 검사로는 차단이 불가능하게 되었습니다.
HTTPS 헤더를 까 봐야 암호화된 문자열들만이 나타나기 때문입니다.

그러자 KCSC는 DNS Spoofing을 시도합니다. 국내 ISP들의 DNS 서버에 특정 도메인 주소에 대한 응답을 warning.or.kr 서버로 돌리도록 한 것이죠.
물론 사용자들은 8.8.8.8과 1.1.1.1 등의 DNS 서버로 비교적 쉽게 우회할 수 있었고, 이에 한 때 1.1.1.1에 대한 접속을 차단하는 등의 강수를 두다가 철회하였습니다.

이 시점에서 KCSC가 취할 수 있는 대응 수단은 몇 가지가 있습니다.

 

1. DNS Request를 감시, 특정 도메인에 대한 요청을 찾으면 Request의 Source IP와 Response의 IP를 통해 TCP 커넥션을 식별, 차단
2. 특정 도메인에 대한 DNS 쿼리를 통해 IP Pool 확보, 해당 IP에 대한 접속을 차단
3. TLS의 Client Hello 메시지에서 암호화되지 않는 부분을 이용, Host 식별 후 차단
4. TLS의 Server Hello 메시지에서 Certificate를 확인, Server Name 필드를 식별 후 차단

 

1번은 기술적으로 구현이 힘들고 (컴퓨팅 파워 부족), DNS를 암호화하면 무력화됩니다
2번은 CloudFlare같은 접속 서비스를 사용하는 사이트에 대해서는 효과를 보기 힘든 데다(CloudFlare CDN 진입점을 차단할 수는 없으니), Virtual Host등을 이용하여 같은 서버를 사용할 경우 무고한 피해자가 발생할 수 있는 등의 문제가 있으며
3번은 현재 적용된 SNI 필터링입니다. 단, 이 문제점을 이미 인식하고 있기에 TLS 1.3에서 도입된 ESNI가 적용될 경우 무력화됩니다
4번은 ESNI가 보급된 이후에 적용될 것으로 예상되는 방법으로, 아직 대응방안이 마련되지 않았습니다

 

이 모든 것들을 한번에 해결할 수 있는 방법으로 VPN을 사용하는 것이 있으나, VPN 트래픽을 식별해낼 수 있으며, Packet을 Drop하는 방법으로 차단 또한 가능합니다.
이미 중국에서는 황금방패에 적용된 기법이고, VPN 트래픽 식별을 위해 머신러닝을 적용하고 있다는 이야기도 들려오고 있습니다.

결과적으로 창과 방패의 싸움이지만, 사법권력을 쥐고 있는 방패가 결국은 승리할 것으로 보입니다.

Windows 클라이언트에서 DNS Whitelist 적용하기

DNSCrypt를 이용하는 것으로 간단하게 구성할 수 있다.

https://github.com/jedisct1/dnscrypt-proxy/releases/tag/2.0.19

1. 위 주소에서 DNSCrypt for Windows를 다운로드 받은 뒤 적당한 경로에 압축을 푼다.

2. blacklist.txt에 “*.*”을 추가한다.

3. whitelist.txt에 원하는 도메인들을 추가한다.

4. dnscrypt-proxy.toml에서 whitelist_file, blacklist_file의 주석을 해제한다.

5. service-install.bat를 실행한다.

6. DNS 서버를 127.0.0.1로 설정한다.

 

이 구성이 실효성을 가지기 위해서는 제한을 받는 사용자가 서비스, DNS 설정과 dnscrypt 설정을 변경하지 못하도록 권한 제어가 이루어져야 할 것이다.

ElasticStack 사용하기 – (2) Apache Kafka 개요

ElasticSearch, Logstash, Kibana만으로 ElasticStack을 구축할 수는 있지만, 이 구조는 확장성이 부족하다.

ElasticSearch의 부하는 클러스터 구성으로 분산할 수 있지만, Feeder의 역할을 하는 Logstash는 수평적으로 확장하기 힘들다.
또한, 로깅 시스템에는 Fault Tolerant가 필요하다.

Apache Kafka는 이러한 고민거리를  한번에 해결해 준다.

 

ZooKeeper를 기반으로 만들어진 비동기 메시지 프레임워크인 Apache Kafka는 시스템의 가용성과 확장성, 성능을 모두 보장해준다.
그것을 확인하기 위해, Kafka의 아키텍처를 잠시 살펴보자.


Image from http://cloudurable.com/blog/kafka-architecture

Kafka의 아키텍처에서 핵심이 되는 부분은 총 3개이다. Producer, Consumer 그리고 Topic.

Producer는 Record를 생성해 특정 Topic에 발행한다. 이 Record는 Kafka 클러스터 내부에서 자동으로 복제/병렬화되어 저장된다.
Topic을 구독하는 Consumer들은 클러스터에 Record를 요청하여 가져간다. 이 모든 작업이 비동기/분산적으로 이루어진다.

또한 Kafka는 Record를 디스크에 저장하여 영속성을 보장하는데, Disk I/O wait을 줄이기 위하여 적극적으로 페이지 캐시를 사용한다.
이러한 특성 상 Kafka 노드는 쓰기 횟수에 제한이 있는 SSD보다는 RAID 구성의 HDD를 사용하고, 넉넉한 메모리를 확보해야 정상적인 동작을 보장할 수 있다.

Kafka의 분산 처리 매커니즘을 이해하기 위해서는 Partition과 Offset 개념을 알아야 하는데, 이것은 나중에 다시 설명하도록 하겠다.

 

여하튼 Kafka를 브로커로 끼워넣으면, 다음과 같은 시스템이 완성된다.

Telegraf(로그 수집기) -> Kafka(로그 브로커) -> Logstash(로그 가공) -> ElasticSearch(로그 저장/분석) -> Kibana(대시보드)

이 때, Kafka의 입장에서 Telegraf는 Producer, Logstash는 Consumer가 된다.
그리고 Topic에 저장되는 로그의 주인을 식별하기 위해, hostname을 사용할 것이다.

 

이제 데모를 위해 Kafka를 설치하고, 클러스터를 구성한 뒤 Topic을 생성해 볼 것이다.

 

1. Kafka 설치, Zookeeper 설정/실행

Kafka는 구동을 위해 Java를 필요로 한다. Kafka Ver 2.1부터 Java 11을 지원하기 때문에 java11-openjdk를 설치할 것이다.

다음으로 Kafka 다운로드 페이지에서 Kafka의 다운로드 경로를 얻은 뒤 압축을 푼다.

적당한 폴더에 압축을 풀었으면, 먼저 ZooKeeper를 설정한다. Kafka의 실행을 위해서는 ZooKeeper가 실행되어 있어야 하기 때문이다.
여기서는 Kafka에 포함되어 있는 ZooKeeper를 사용한다. 실제 서비스에서는 ZooKeeper를 별도로 유지하는 편이 좋을 것이다.

이제 /bin/zookeeper-server-start.sh <ZooKeeper Config>를 통해 ZooKeeper를 실행할 수 있다.

ZooKeeper의 동작 확인은 다음과 같은 명령어로 가능하다.

서버가 정상적으로 동작한다면, 위와 같은 화면을 볼 수 있을 것이다.

 

2. Kafka 설정/실행

ZooKeeper가 정상 동작하는 것을 확인하였으니, 이제 Kafka를 설정할 차례다.

먼저, Kafka의 config를 수정한다.

Kafka의 설정이 완료되었으면

명령으로 Kafka Server를 실행할 수 있다.

Kafka 클러스터를 실행하였다면 클러스터에 Topic을 추가할 수 있다.
여기서는 ‘test’ 토픽을 추가할 것이다.

이 때, 하나의 노드에서 만들어진 Topic은 전체 클러스터와 동기화되며, 클러스터의 모든 브로커로부터 Pub/Sub가 가능하다.

이와 같이 3번 노드에서 생성한 ‘test’ 토픽을 2번 노드에서 확인할 수 있다.

ElasticStack 사용하기 – (1) CentOS 7에 ElasticSearch 6.5 설치

모니터링/로깅 시스템을 만들기 위해 ElasticStack을 사용하기로 결정하였다. 따라서 가장 먼저 해야 할 일은 ElasticSearch를 설치하는 것이다.

여기서는 Elastic.co의 설치 가이드에 따라 rpm을 이용하여 ElasticSearch를 설정한다.

 

1. yum에 PGP-KEY 등록


2.
ElasticSearch Repo 등록


3.
yum Repo 업데이트


4.
OpenJDK/ElasticSearch 설치


5.
firewalld에 예외 등록 (선택)


6.
ElasticSearch 시작/테스트

 

이렇게 하여 다음과 같은 결과 화면이 나오면 정상적으로 설치가 이루어진 것이다.

 

UPS 도입/사용시 주의해야 할 점

 

1. UPS란 무엇인가?

UPS는 Uninterruptible Power Supply의 약자로, 한국어로는 ‘무정전 전원공급장치’라고 합니다.
즉, 전기가 끊어졌을 때 장비에 대신 전력을 공급해주는 역할을 합니다.

그런데 그게 전부일까요? 당연히 아닙니다.
현재 사용되는 UPS의 토폴로지는 크게 Stand-By(Off-line), Line-Interactive,Online Double Conversion이 있습니다.
각각의 토폴로지는 서로 다른 특징을 가지며, 특성에 맞는 분야에서 활용되고 있습니다.

먼저 Stand-By(Off-Line) 토폴로지를 살펴보겠습니다.

Stand-by 토폴로지 UPS는 공급되는 전원(이하 유틸리티 전원)이 UPS를 거쳐가지 않습니다.
따라서, 전원을 출력하는 것에 충분한 인버터 용량만 보유하면 되고, 단가도 싸집니다.
인버터 회로를 분리하거나 (상대적으로) 소형으로 만들 수 있어서 대용량 UPS나 값 싼 UPS에 주로 사용되는 방식입니다.
다만, 유틸리티 전원이 끊어졌을 때 릴레이가 동작하여 배터리 전원을 공급하므로 절체 시간이 길다는 단점이 있습니다.
그리고 유틸리티 전원이 UPS를 통과하지 않으므로 전원 안정화 기능도 기대할 수 없습니다. 그래서 Stand-By UPS는 보통 AVR과 함께 배치됩니다.

다음으로 Line-Interactive 토폴로지가 있습니다.

라인 인터렉티브 토폴로지 UPS는 유틸리티 전원이 UPS의 전력 인터페이스와 인버터를 통과하기에 제한적인 수준의 전원 안정화(전압/위상 제어)를 수행할 수 있습니다.
또한 Stand-By UPS 대비 배터리 백업으로 전환되는 시간이 짧다는 장점을 가집니다.
인버터가 상시 작동하지 않으므로 전력 효율이 높고, 열이 적게 나고, 회로가 복잡하지 않기에 내구성도 높습니다.

하지만 Stand-By 토폴로지 대비 인버터 용량이 커야 한다는 것(배터리를 충전하면서 동시에 부하에 전원을 공급한다고 할 때 최대 출력의 2배)과, 절체 시간이 0은 아니라는 것, 대용량화에 불리하다는 단점이 있습니다.

1KVA~3KVA에서 많이 사용됩니다.

마지막으로, 일반적으로 UPS라 하면 떠올리게 되는 Online Double Conversion 토폴로지 UPS가 있습니다.

이름으로부터 유추할 수 있듯이, Online Double Conversion 토폴로지는 유틸리티 전원을 정류기에 통과시키고, 다시 배터리에 DC 전원으로 공급한 뒤 인버터로 보내어 AC 전원을 공급합니다.
기본적으로 배터리를 거치기 때문에(물론 정상 상태에서는 방전이 일어나지 않음) 안정화된 DC 전원을 공급할 수 있고, 유틸리티 전원-배터리 전환에 걸리는 절체 시간이 발생하지 않는다는 장점이 있습니다.

Line-Interactive 대비 대용량화에 유리하기에 3KVA~에서 주로 사용됩니다.

하지만 인버터가 늘 동작하기에 전력 효율이 상대적으로 떨어지고, 열이 많이 발생합니다.
그리고 Online Double Conversion 토폴로지는 라인 인터렉티브와 스탠바이 토폴로지와는 다른 절체 현상을 겪을 수 있는데, 인버터 회로가 고장나는 경우와 부하가 급격히 변동하는 경우 순간적인 절체가 발생할 수 있습니다.

때문에 Online Double Conversion UPS를 사용하는 경우 부하 설계에 신경을 써야 하며, 최악의 경우 전원 상실을 막기 위하여 바이패스 라인을 함께 설치합니다.
UPS 동작 불량으로 바이패스 라인이 사용되는 경우, Line-Interactive와 동등한 수준의 절체 시간이 발생할 수 있습니다.

이런 토폴로지별 특성을 잘 고려하여 자신의 환경에 가장 적합한 UPS를 골라야 할 것입니다.

APC의 각 토폴로지별 현행 제품군은 다음과 같습니다.

1) Stand-By 토폴로지

– Back-UPS: 가정용/소형 UPS. 유사 정현파(구형파) 출력.

2) Line Interactive 토폴로지

– SMT 제품군: 현행 Smart-UPS의 표준이 되는 모델.
– SMX 제품군: SMT에서 역률을 개선하고, 배터리 관리 시스템을 강화한 모델.
– SMC 제품군: SMT를 간략화한 모델. Smart-Slot 제거
– SUM 제품군: 모듈 방식의 UPS. 배터리와 파워 모듈의 수평적 확장이 가능.

3) Double Conversion Online 토폴로지

– SURT 제품군: 1세대 온라인 UPS로, 추가 배터리 장착이 가능. (1K~40KVA)
– SRT 제품군: SURT를 개량, LCD를 통해 모든 설정을 제어할 수 있음. (3K~40KVA)

 

2. 사인파와 구형파

UPS의 스펙을 읽어보면 사인파(정현파)와 유사 정현파(구형파)라는 단어를 볼 수 있습니다.
일반적으로, 우리가 사용하는 AC 전원은 정현파의 형태로 공급됩니다. 따라서 UPS의 출력도 정현파로 나오는 것이 이상적입니다.
하지만 정현파를 만들어내는 것에는 돈이 들어가므로, 싼 UPS의 경우 정현파를 출력하지 않는 경우가 많습니다.

가정용 UPS로 많이들 사용하시는 BE700-KR UPS의 배터리 출력 파형입니다.
얼핏 보아도 정현파와는 큰 차이가 나는 것을 알 수 있습니다. 이러한 전원이 공급되면 파워 서플라이에 무리가 가거나, 전원부가 좋지 않을 경우 오작동을 일으킬 수도 있습니다.

전원 품질이 중요한 장비를 사용한다면, 사인파가 출력되는 UPS를 구매해야 합니다.

 

3. UPS와 부하

UPS를 사용할 때 흔히 ‘반드시 벽부 콘센트에 연결해야 한다’는 경고를 보게 됩니다. 즉, 멀티탭에 연결하지 말라는 것인데.. 여기에도 이유가 있습니다.
전기안전법상 멀티탭의 최대 전류는 16A(2800W)로 제한되어 있고, 1500VA의 UPS는 배터리를 충전하면서 부하에 전원을 공급할 경우, 3000VA를 사용합니다.
UPS의 역률은 보통 매우 높기 때문에 3kW를 소모한다고 가정하면, 멀티탭의 허용 전류량을 가볍게 초과하게 됩니다. 즉, 화재로 이어진다는 것이죠.

한편, 이 조건은 벽부 콘센트에도 적용되는데, 일반적인 벽부 콘센트의 허용 전력이 3000~3500VA 수준이기 때문에 1500VA의 용량을 가지는 UPS를 설치했을 경우 간당간당하게 수용하는 전력량이 됩니다. 따라서 일반 가정에서 1500VA를 넘는 UPS를 사용하는 것은 그리 바람직한 일이 아닙니다.

벽부 콘센트의 문제가 아니더라도 대용량 UPS를 사용하게 된다면 차단기 용량도 신경써야 하기 때문에, 대용량 UPS를 구매하기 전에는 반드시 전체 토폴로지를 설계하고 구매, 설치해야 합니다.
금액이 금액인지라 판매처에서 알아서들 하겠지만..

APC UPS / Network Management Card 설치 및 사용기

 

1. 들어가며

대한민국에서 가정용으로 UPS(Uninterruptible Power Supply)를 사용하는 사람들이 그리 많지는 않을 것이다.
이번에 우연찮은 기회로 매우 싸게 APC의 Smart UPS를 구매할 수 있었고, APC UPS를 사용하고자 하는 다른 사람들과 나의 경험을 공유하고자 한다.

먼저, 용도에 적합한 모델을 고르기 위하여 APC UPS의 제품군을 알아보자.

국내에서 유통되는 APC UPS는 크게 가정용과 기업용 모델로 나뉜다.
이 중 가정용 모델이 바로 우리가 흔히 접할 수 있는 Back-UPS 시리즈이다.

Back-UPS는 싸고, 출력 단자가 Outlet 규격과 일치하지만, 정작 컴퓨터와 같은 정밀 전자기기의 전원을 백업하는 용도로는 적합하지 않다.
APC Back-UPS는 Standby 방식으로 동작하는데, 유틸리티 전원으로부터 전기가 들어올 때는 배터리와 인버터를 연결하지 않고, 절체가 감지되는 순간 스위치를 전환하여 배터리 전원으로 백업하는 방식이다.
이 경우, UPS는 유틸리티 전원의 상실이 일어나기 전에 발생하는 전압 불안정으로부터 시스템을 보호할 수 없고, 절체 순간에 발생하는 스위칭 노이즈가 기기에 그대로 전달되는 문제를 가진다.

그리고 Back-UPS의 출력 파형은 Stepped approximation to a sinewave로, 완전한 사인파가 나오지 않는다.
이게 왜 문제인지 이해가 잘 안 될 수 있는데, 다음 사진을 보면 바로 이해가 될 것이다.

한국에서 가장 많이 팔리는 가정용 UPS라고 할 수 있는 BE700-KR 모델의 파형으로, 사인파와 구형파의 중간 쯤 되는 파형을 확인할 수 있다.

당연히 구형파가 공급되면 PSU의 정류부에 부담이 가기 때문에 정밀 전자기기의 전원을 백업하는 용도로는 적합하지 않은 모델이다.

 

다음으로 APC에서 공급하는 기업용 제품군인 Smart-UPS 시리즈가 있다.
Smart-UPS 시리즈는 크게 Line Interactive와 Double Conversion Online 토폴로지로 나뉜다.

주로 750~3KVA 사이의 UPS들은 Line Interactive 토폴로지를 사용하고, 절체시간이 0이어야만 하거나, 대용량 UPS의 경우 Double Conversion Online 토폴로지를 사용한다.

일반적으로 Double Conversion Online 토폴로지가 더 비싸지만, 두 토폴로지 사이에는 장단점이 있기에 용도에 맞는 UPS를 골라야 할 것이다.

Line Interactive의 장점으로는

– 98%에 이르는 높은 전력 효율
– 작은 용량의 경우 소형화 용이
– 상대적으로 저렴한 비용
– 전압, 파형 보상 가능

이 있으나, 배터리 전원으로 전환할 때 수 ms 정도의 절체가 발생한다는 단점이 있다.
이 절체는 SMPS를 사용하는 장비의 경우 무의미하지만, PSU를 사용하지 않는 정밀기기는 영향을 받는다.

그리고, UPS가 보상할 수 없을 수준의 변동이 일어나면 배터리를 사용하기 때문에, 전원이 불안정할 경우 배터리를 자주 사용하게 되어 수명을 크게 단축시킬 우려가 있다.
전원이 불안정한 환경에서는 Double Conversion Online 토폴로지를 사용하는 것이 나을 것이다.

한편, Double Conversion Online 토폴로지는 절체 시간이 0이지만, 평상시에도 늘 인버터가 동작하고 있기에 전원 효율이 상대적으로 떨어진다.
하지만 UPS 내부에서 전원을 다시 생성하여 출력하기 때문에, 전압과 주기가 전혀 다른 파형도 출력할 수 있다는 장점을 가진다.

이에 맞춰 APC의 현행 Smart-UPS 라인업을 적어보았다.

Line Interactive 토폴로지

– SMT 제품군: 현행 Smart-UPS의 표준이 되는 모델.
– SMX 제품군: SMT에서 역률을 개선하고, 배터리 관리 시스템을 강화한 모델.
– SMC 제품군: SMT를 간략화한 모델. Smart-Slot 제거
– SUM 제품군: 모듈 방식의 UPS. 배터리와 파워 모듈의 수평적 확장이 가능.

Double Conversion Online 토폴로지

– SURT 제품군: 1세대 온라인 UPS로, 추가 배터리 장착이 가능. (1K~40KVA)
– SRT 제품군: SURT를 개량, LCD를 통해 모든 설정을 제어할 수 있음. (3K~40KVA)

 

2. 사용기

이번에 구매한 모델은 SMT1000RMi2U로, 1000KVA/700W를 백업할 수 있다.
200W의 부하를 약 20분간 백업할 수 있는 용량으로, 정전시 서버를 안전하게 종료할 시간을 벌어줄 것이다.

여느 UPS가 그렇듯이 출력 단자는 3핀이고, 랙서버용 전원 케이블을 통해 부하와 연결되어야 한다.
그리고 PC에 연결하기 위한 인터페이스와 네트워크 매니지먼트 카드를 장착할 수 있는 Smart-slot이 있는데, 이게 예상 밖이었다.

UPS에 연결된 서버들에게 종료 명령을 전달하려면 SNMP를 통한 Alert 알람이 필요한데, 엔터프라이즈용 모델이면서 네트워크 인터페이스가 기본 제공되지 않는다.
결국, 별도의 네트워크 매니지먼트 카드를 구매해야만 했고, 2세대 제품군에 장착할 수 있는 카드로는 AP9630/9631이 있다.

 

내가 중고로 구매한 AP9631은 이렇게 생겼는데, 전면부의 콘솔 포트가 2.5mm 스테레오 잭이다.
즉, DB9-2.5mm 케이블이 있어야 매니지먼트 카드의 콘솔에 액세스 할 수 있다는 것이다.

왜 이렇게 변태적인 단자를 사용했는지는 몰라도, 덕분에 사용자 계정이 기본값과 다르다면 케이블을 별도로 구해야 할 판이다.

매니지먼트 카드의 계정을 리셋하는 방법도 상당히 독특한데, 이건 구매한 물건이 도착한 뒤 추가로 작성하겠다.

 

해외에서 구매한 AP9631이 도착했다.
이 녀석을 UPS에 장착하면 이렇게 된다.

 

다행히도 패스워드가 기본값으로 설정되어 있었기에 바로 로그인할 수 있었다.
그러므로 초기화 방법은 올리지 않는다. 콘솔 케이블이 없기도 하고..

그런데 펌웨어 버전이 좀 낮아 보인다. 업그레이드를 해주자.

최신 펌웨어로 업그레이드를 마친 모습이다.