처음 윈도우 서버를 구축하면서 겪은 시행착오

최근 회사에서 Windows Server를 새롭게 구축하고 있습니다.

회사에서는 Windows 기반 서버를 거의 사용하지 않았고, 저 역시 Windows Server 구축 업무를 직접 수행해본 경험이 없었습니다. 그래서 여러 선배와 구축 전문가의 도움을 받아 하나씩 배워가며 환경을 구성하고 있습니다.

구축의 시작, 서버 설치

우선 구축에 사용할 물리 서버를 배정받았습니다.

처음에는 USB에 Windows Server ISO 파일을 담고, 서버의 Boot Order만 변경해서 설치하면 별문제 없이 끝날 것이라고 생각했습니다.

그런데 설치를 마치고 보니 뭔가 이상했습니다.

Hyper-V에서 가상 스위치를 구성하려고 했지만 NIC가 제대로 보이지 않았고, iLO에서 확인해보니 일부 장치가 정상적으로 인식되지 않은 것처럼 보였습니다.

뒤늦게 이상함을 감지하고 구축 경험이 많은 선배 매니저님께 물어봤습니다.

“Intelligent Provisioning을 안 썼어?”

— 구축 업무 선배

공급사에도 문의해보니, Intelligent Provisioning을 사용하지 않고 운영체제를 직접 설치하면 장비에 필요한 드라이버를 별도로 적용해야 할 수 있다고 했습니다.

결국 HPE Service Pack for ProLiant, 즉 SPP를 이용해 장비에 필요한 펌웨어와 드라이버를 적용한 후에야 NIC와 스토리지 장치를 정상적으로 사용할 수 있었습니다.

그래서 Intelligent Provisioning이 뭔가요?

Intelligent Provisioning은 HPE ProLiant 서버에 제공되는 초기 구축 및 유지보수 도구입니다.

Intelligent Provisioning을 이용하면 다음과 같은 작업을 조금 더 편리하게 진행할 수 있습니다.

Windows 및 Linux 운영체제 설치 보조
HPE 드라이버와 시스템 소프트웨어 적용
RAID 및 Smart Array 구성
펌웨어 업데이트
하드웨어 진단과 유지보수

HPE에서도 Intelligent Provisioning을 운영체제 설치와 RAID 구성, 유지보수 작업을 지원하는 단일 서버 배포 도구로 설명하고 있습니다.

제 경우에는 Intelligent Provisioning을 거치지 않고 USB에 담긴 Windows Server 이미지로 바로 설치했습니다. 그 결과 NIC가 인식되지 않거나 RAID로 구성한 디스크가 보이지 않는 문제를 겪었습니다.

물론 Windows Server ISO로 직접 설치하는 것 자체가 잘못된 방법은 아닙니다. 다만 이 방법을 선택한다면 해당 서버의 스토리지 컨트롤러와 NIC 드라이버를 미리 준비하는 것이 좋습니다.

호스트명 지정

서버를 구성하고 VM을 생성한 뒤 호스트명을 지정하려는데 다음과 같은 메시지가 나타났습니다.

이미 사용되고 있는 PC 이름입니다.

예를 들어 다음과 같이 이름을 정했다고 가정해보겠습니다.

WIN-WINDOWS-SRV-01
123456789012345678

이 이름은 총 18자입니다.

Windows의 NetBIOS 컴퓨터 이름은 최대 15바이트까지만 사용할 수 있습니다. 따라서 긴 DNS 호스트명을 사용하면 NetBIOS 이름은 앞부분을 기준으로 잘릴 수 있습니다.

위 예시에서는 다음 부분이 15자에 해당합니다.

WIN-WINDOWS-S
123456789012345

서로 다른 서버라도 앞 15자가 같다면 NetBIOS 이름이 동일하게 잘리면서 이름 충돌이 발생할 수 있습니다.

현재 서버에 등록된 로컬 NetBIOS 이름은 다음 명령어로 확인할 수 있습니다.

nbtstat -n

특정 원격 서버의 NetBIOS 이름 테이블을 조회하려면 다음과 같이 입력합니다.

nbtstat -a <원격 서버 이름>

IP 주소를 기준으로 조회하려면 대문자 -A 옵션을 사용합니다.

nbtstat -A <IP 주소>

Hostname? NetBIOS? 그게 뭔데요?

공부하면서 정리한 내용을 간단히 풀어보겠습니다.

호스트명은 네트워크에서 컴퓨터를 식별하기 위한 이름입니다.

예를 들어 서버의 호스트명이 다음과 같다고 가정해보겠습니다.

service1

DNS 도메인으로 다음 주소를 사용한다면:

service.example.com

서버의 FQDN은 다음과 같습니다.

service1.service.example.com

FQDN은 Fully Qualified Domain Name의 약자로, 호스트명과 DNS 도메인을 모두 포함한 전체 이름입니다.

현대 Windows 환경에서는 대부분 DNS를 이용해 시스템의 이름을 확인합니다. 다만 Active Directory와 일부 레거시 프로토콜 및 관리 도구에서는 여전히 NetBIOS 이름이 영향을 줄 수 있습니다.

NetBIOS 컴퓨터 이름은 최대 15바이트로 제한됩니다. 16번째 바이트는 파일 서비스, 워크스테이션, 도메인 컨트롤러 등의 서비스 유형을 구분하는 용도로 사용됩니다.

따라서 Windows Server의 호스트명은 가능하면 처음부터 15자 이하로 설계하는 것이 안전합니다.

특히 서버 이름의 앞부분에 긴 지역명이나 운영체제명, 역할명을 반복해서 넣으면 여러 서버의 NetBIOS 이름이 동일하게 잘릴 수 있습니다.

예를 들면 다음과 같습니다.

WIN-HV-01
WIN-DC-01
WIN-WSUS-01

처음부터 짧고 일관된 명명 규칙을 정하는 편이 좋습니다.

원격 데스크톱 연결

Windows Server 설치 문제로 한동안 고생했습니다.

베어메탈 서버 여러 대에 Windows Server를 설치한 뒤 드라이버가 제대로 잡히지 않아 다시 사무실로 돌아가 자료를 찾아야 했습니다.

보안 정책상 외부 저장장치를 통해 파일을 옮기는 과정에도 제약이 있었고, 필요한 드라이버와 SPP를 준비해 다시 서버실로 이동해야 했습니다.

드디어 네트워크를 연결했지만, 이번에는 원격 데스크톱을 활성화하지 않은 채 서버실에서 나오는 실수를 했습니다. 결국 다시 서버실로 올라가야 했습니다.

서버실을 떠나기 전에는 적어도 다음 사항을 실제로 확인하는 것이 좋습니다.

호스트명과 IP 주소
기본 게이트웨이와 DNS 설정
원격 데스크톱 활성화 여부
Windows 방화벽의 원격 데스크톱 규칙
관리망에서의 RDP 접속 가능 여부
원격 로그인에 사용할 관리자 계정
재부팅 후에도 다시 접속할 수 있는지 여부

원격 데스크톱은 단순히 켜는 것에서 끝나지 않습니다. 전체 네트워크에 무작정 개방하기보다는 관리망과 허용된 관리자 단말에서만 접근할 수 있도록 제한하는 것이 좋습니다.

그룹 정책과 원격 데스크톱 관련 세부 설정은 별도의 글에서 정리해보려고 합니다.

Hyper-V 활용하기

Windows Server를 구축하면서 실제 서비스를 물리 서버에 바로 설치할지, Hyper-V VM에 설치할지를 고민했습니다.

처음에는 다음과 같이 생각했습니다.

“이 서버의 역할이 이미 정해져 있다면 굳이 가상화를 해야 할까?”

단일 역할만 수행하는 서버라면 물리 서버에 서비스를 직접 설치하는 방법도 충분히 가능합니다.

그런데 Windows Server를 처음 구축하면서 여러 시행착오를 겪고 나니, 이번 환경에서는 Hyper-V를 이용해 역할을 VM으로 분리하는 편이 더 적합하다고 판단했습니다.

첫 번째, 재부팅의 영향 범위

Windows Server는 호스트명 변경, 역할 설치, 드라이버 적용, Windows Update 등의 과정에서 재부팅이 필요한 경우가 제법 많았습니다.

베어메탈 서버 자체를 재부팅하면 하드웨어 초기화와 펌웨어 검사를 거쳐야 하므로 재부팅에 상당한 시간이 걸릴 수 있습니다.

반면 실제 서비스 역할을 VM으로 분리하면 작업이 필요한 VM만 재부팅할 수 있습니다. 물론 Hyper-V 호스트 자체를 재부팅하면 해당 호스트의 VM도 영향을 받지만, 평상시 운영 작업의 영향 범위를 VM 단위로 줄일 수 있다는 장점이 있습니다.

두 번째, 역할의 격리와 복구 편의성

물리 호스트에는 Hyper-V 역할과 관리에 필요한 최소한의 구성만 두고, 실제 서버 역할은 VM으로 분리하기로 했습니다.

역할을 VM으로 분리하면 다음과 같은 운영상 장점이 있습니다.

서비스별 장애 영향 범위 분리
VM 단위의 백업과 복구
테스트 환경과 운영 환경 분리
다른 호스트로 이전할 수 있는 구조 설계
운영체제와 역할별 자원 할당
문제 발생 시 VM 단위의 네트워크 격리

다만 Hyper-V를 사용한다고 해서 자동으로 고가용성이나 보안성이 확보되는 것은 아닙니다.

하나의 호스트에 여러 VM을 구성하면 호스트나 스토리지에 장애가 발생했을 때 여러 VM이 동시에 영향을 받을 수 있습니다. 따라서 호스트 장애, 백업, 복구 절차, 스토리지 구성과 가상 스위치 설계도 함께 고려해야 합니다.

가상화는 장애를 없애는 기술이라기보다, 장애와 운영 작업의 단위를 더 작게 나누고 관리할 수 있게 해주는 도구에 가깝다고 느꼈습니다.

정리하며

이 글은 아직 미완성이고, Windows Server 구축 업무도 절반 이상 남아 있습니다.

그럼에도 저와 비슷한 시행착오를 겪는 분들이 제법 있을 것 같아 퇴근 후 빠르게 경험을 정리해봤습니다.

앞으로 구축을 계속하면서 이 글에도 내용을 추가할 예정입니다.

Windows Admin Center가 시작 화면에서 넘어가지 않았던 문제, 호스트명 변경 후 인증서와 바인딩이 꼬였던 문제, iLO 웹 인터페이스와 펌웨어 업데이트 과정에서 겪은 시행착오도 차례로 정리해보려고 합니다.

아직 배우고 있는 단계에서 작성한 글이기 때문에 일부 설명이 부족하거나 정확하지 않을 수도 있습니다. 잘못된 부분을 발견하신다면 댓글로 알려주시면 감사하겠습니다.

미약하게나마 처음 Windows Server를 구축하는 분들에게 도움이 되었으면 합니다.