세상의 모든 잡학 지식

'2시간 35분'만에 끝난 윤석열 정권의 비상계엄령

OSMU-PIPELINE — Wed, 4 Dec 2024 05:55:21 +0900

< 계엄령 >

비상계엄령 선포

2024년 12월 3일 22시 27분경, 윤석열 정부는 기습적으로 비상계엄령을 선포하였습니다.

계엄령 이란 단어는 근대사 교육을 받으면서 박정희, 전두환의 군사 독재정부 시절에만 존재하던 단어라고 생각했는데 , 2024년에 웬 계엄령? 이라고 의아해 하시는 분들도 있었을 것이고, 이미 계엄령이 가지는 의미에 대해서 자세하게 알고 계셨던 분들은 가슴이 철렁 내려 앉아 밤잠을 못 이루셨을 것입니다.

계엄령이란 무엇인지 어떤 이유에 선포하는지 한번 알아보겠습니다.

<비상계엄 선포 장면>

계엄령이란?

계엄령에는 비상계엄과 경비계엄으로 구분되는데 이번 사태와 관련해서 비상계엄에 대해 중점적으로 정리해보겠습니다.(경비계엄은 더보기에서..)

비상계엄

비상계엄(非常戒嚴)이란 대통령이 전시, 사변 또는 이에 준하는 국가비상사태로 사회질서가 극도로 혼란된 지역에 군사상의 필요에 의하거나 공공의 안정질서를 유지하기 위하여 선포하는 계엄을 말한다(헌법 제77조, 계엄법 제2조·제10조).

경비계엄은 대통령이 전시·사변 또는 이에 준하는 국가비상사태 시 사회질서가 교란되어 일반 행정기관만으로는 치안을 확보할 수 없는 경우에 공공의 안녕질서를 유지하기 위하여 선포한다.

(대한민국 헌법 제77조)
① 대통령은 전시·사변 또는 이에 준하는 국가비상사태에 있어서 병력으로써 군사상의 필요에 응하거나 공공의 안녕질서를 유지할 필요가 있을 때에는 법률이 정하는 바에 의하여 계엄을 선포할 수 있다.
② 계엄은 비상계엄과 경비계엄으로 한다.
③ 비상계엄이 선포된 때에는 법률이 정하는 바에 의하여 영장제도, 언론·출판·집회·결사의 자유, 정부나 법원의 권한에 관하여 특별한 조치를 할 수 있다.
④ 계엄을 선포한 때에는 대통령은 지체없이 국회에 통고하여야 한다.
⑤ 국회가 재적의원 과반수의 찬성으로 계엄의 해제를 요구한 때에는 대통령은 이를 해제하여야 한다.

계엄법에 따라 비상계엄의 선포와 동시에 계엄사령관은 계엄지역 안의 모든 행정 사무와 사법사무를 관장하며, 비상계엄 지역 안에 있어서 일정한 범죄는 군사 법원에서 재판하게됩니다.

또한 통신이나 인터넷 등 정보 매체에 대한 통제가 가능해지며, 필요에 따라 광범위한 검열과 감시가 이루어질 수 있게 되는 등 군사적 권한과 행정적 권한이 대폭 확대 됩니다.

과거 정부에서는 이를 악용하여 자신의 정권 유지를 위해 발동되었었고, 국회가 재적의원 과반수의 찬성으로 계엄의 해제를 요구하면 대통령은 계엄령을 해제하도록 명시하고 있습니다.

계엄령 해제 가결

윤석열 정권은 비상계엄을 선언하고 난뒤 바로 국회에 무장 군인들을 보내 국회의원들의 입장을 방해하려고 하였으나, 계엄령 소식을 들은 시민들과 국회보좌관들이 무장한 군인들의 진입을 막아내며 여•야 190명의 국회의원들이 참석한 가운데, 190명 전원이 찬성해 비상계엄 해제 요구 결의안을 가결할수 있었습니다.

4일 새벽 1시경에 해제 가결되었으므로 비상계엄령은 2시간 35분 정도 발동이 된 셈입니다.

<무장 군인 국회진입 시도>

<국회 내부 대치 모습>

헌정사상 12번째, 45년만의 비상계엄

이번 계엄령은 헌정 사상 12번째 비상계엄선포(경비계엄은 4번) 이자 박정희 대통령 서거 직후인 1979년 10월 26일 이후 45년 만입니다. 우리나라 최초의 비상계엄은 1948년에 발생한 여순사건으로 10월 21일에 발효됐으며, 이승만 전 대통령은 1960년 4월 19일 4·19혁명이 일어나자 계엄령을 선포했습니다. 그리고 이듬해인 1961년 박정희 전 대통령은 5월 16일 군사쿠데타를 일으키며 비상계엄령을 선포했습니다.

※ 비상계염령 전문

존경하는 국민 여러분, 저는 대통령으로서 피를 토하는 심정으로 국민 여러분께 호소드립니다.
지금까지 국회는 우리 정부 출범 이후 22건의 정부 관료 탄핵 소추를 발의했으며 지난 6월 22대 국회 출범 뒤 10명째 탄핵을 추진 중에 있습니다. 이것은 세계 어느 나라에도 유례가 없을 뿐 아니라 건국 이후에 전혀 유례가 없던 상황입니다.판사를 겁박하고, 다수의 검사를 탄핵하는 등 사법 업무를 마비시키고 행안부장관 탄핵, 방통위원장 탄핵, 감사원장 탄핵, 국방장관 탄핵 시도 등으로 행정부마저 마비시키고 있습니다.
국가 예산 처리도 국가 본질 기능과 마약범죄 단속, 민생 치안 유지를 위한 모든 주요 예산을 전액 삭감하여 국가 본질 기능을 훼손하고, 대한민국을 마약 천국, 민생 치안 공황상태로 만들었습니다. 민주당은 내년도 예산에서 재해 대책 예비비 1조원, 아이 돌봄 지원 수당 384억, 청년 일자리, 심해 가스전 개발 사업 등 4조 1000억원 삭감, 심지어 군 초급 간부 봉급과 수당 인상, 당직 근무비 인상 등 군간부 처우 개선비조차 제동을 걸었습니다.
이러한 예산 폭거는 한마디로 대한민국 국가 재정을 농락하는 것입니다. 예산까지도 오로지 정쟁의 수단으로 이용하는 이러한 민주당의 입법 독재는 예산안 탄핵까지도 서슴지 않았습니다.국정은 마비되고 국민들의 한숨은 늘어나고 있습니다. 이는 자유대한민국의 헌정 질서를 짓밟고, 헌법과 법에 의해 세워진 정당한 국가 기관을 교란시키는 것으로서 내란을 획책하는 명백한 반국가 행위입니다.국민의 삶은 안중에도 없고, 오로지 탄핵과 특검, 야당 대표의 방탄으로 국정이 마비 상태에 있습니다. 지금 우리 국회는 범죄자 집단의 소굴이 되었고, 입법 독재를 통해서 국가의 사법 행정 시스템을 마비시키고 자유민주주의 체제 전복을 기도하고 있습니다.자유민주주의 기반이 되어야 할 국회가 자유민주주의 체제를 붕괴시키는 괴물이 된 것입니다.
지금 대한민국은 당장 무너져도 이상하지 않을 정도의 풍전등화의 운명에 처해있습니다.
친애하는 국민 여러분, 저는 북한 공산세력의 위협으로부터 자유 대한민국을 수호하고, 우리 국민의 자유와 행복을 약탈하고 있는 파렴치한 종북 반국가세력을 일거에 척결하고 자유 헌정 질서를 지키기 위해 비상 계엄을 선포합니다.
저는 이 비상 계엄을 통해 망국의 나락으로 떨어지고 있는 자유 대한민국을 재건하고 지켜낼 것입니다. 이를 위해 저는 지금까지 패악질을 일삼은 망국의 원흉 반국가세력을 반드시 척결하겠습니다. 이는 체제 전복을 노리는 반국가세력의 준동으로부터 국민의 자유와 안전, 그리고 국가 지속 가능성을 보장하며 미래 세대에게 제대로 된 나라를 물려주기 위한 불가피한 조치입니다.저는 가능한 한 빠른 시간 내에 반국가 세력을 척결하고 국가를 정상화시키겠습니다. 계엄 선포로 인해 자유대한민국 헌법 가치를 믿고 따라주신 선량한 국민 여러분께 다수의 불편이 있겠지만 이러한 불편을 최소화하는 데 주력할 것입니다.이러한 조치는 자유 대한민국 영속성을 위해 부득이한 것이며 국제사회에 책임과 기여를 다한다는 대외 정책 기조에 아무런 변함이 없습니다. 대통령으로서 국민 여러분께 간곡히 호소드립니다. 저는 오로지 국민 여러분만 믿고 신명을 바쳐 자유대한민국을 지켜낼 것입니다. 저를 믿어주십시오. 감사합니다.

※ 계엄문 포고령 전문

계엄사령부 포고령(제1호)

자유대한민국 내부에 암약하고 있는 반국가세력의 대한민국 체제전복 위협으로부터 자유민주주의를 수호하고, 국민의 안전을 지키기 위해 2024년 12월 3일 23:00부로 대한민국 전역에 다음 사항을 포고합니다.

1. 국회와 지방의회, 정당의 활동과 정치적 결사, 집회, 시위 등 일체의 정치활동을 금한다.[9]
2. 자유민주주의 체제를 부정하거나, 전복을 기도하는 일체의 행위를 금하고, 가짜뉴스, 여론조작, 허위선동을 금한다.
3. 모든 언론과 출판은 계엄사의 통제를 받는다.
4. 사회혼란을 조장하는 파업, 태업, 집회 행위를 금한다.
5. 전공의를 비롯하여 파업 중이거나 의료 현장을 이탈한 모든 의료인은 48시간 내 본업에 복귀하여 충실히 근무하고 위반 시에는 계엄법에 의해 처단한다.
6. 반국가세력 등 체제전복세력을 제외한 선량한 일반 국민들은 일상생활에 불편을 최소화할 수 있도록 조치한다.

이상의 포고령 위반자에 대해서는 대한민국 계엄법 제9조(계엄사령관 특별조치권)에 의하여 영장없이 체포, 구금, 압수수색을 할 수 있으며, 계엄법 제14조(벌칙)에 의하여 처단한다.

2024. 12. 3.(화) 계엄사령관 육군대장
박안수

<2025년> 통신판매업 신고번호 조회 방법(공정거래위원회 홈페이지 이용)

OSMU-PIPELINE — Sun, 4 Feb 2024 10:56:40 +0900

온라인 스토어에서 사업자로 입점하기 위해서는

통신판매업 신고번호가 필요합니다.

실제 통신판매업 신고서와 함께

각종서류(사업자등록증 사본, 대표자 신분증)를

구비하여 관할 구청에 방문해서

신청하는 방법도 있지만,

간편하게 온라인으로 통신판매업 신고번호 조회

하는 방법에 대해서 알려드리겠습니다.

온라인으로 조회하는 방법은

공정거래위원회 홈페이지

(https://www.ftc.go.kr)

를 이용하시면 됩니다.

1. 공정거래위원회 홈페이지 접속 → 정보공개 → 통신판매사업자

2. 일반 이용고객 → 통신판매사업자 조회

3. 사업자등록번호 입력 → 검색 → 상호 클릭

상호, 대표자 이름으로도 검색이 가능합니다.

사업자 등록번호가 조회되지 않을 경우

국세청 홈택스에서 사업자 등록상태 조회가 가능합니다.

4. 통신판매번호 조회(완료)

해당 정보에서 통신판매번호를 확인하시면 됩니다.

종합비타민 VS 멀티비타민 차이점과 선택방법

OSMU-PIPELINE — Sun, 3 Sep 2023 11:42:12 +0900

종합비타민과 멀티비타민의 차이점 알아보기

현대인들의 서구화된 식습관, 바쁜 일상생활, 운동부족 등으로 필수 영양소인 비타민과 미네랄이 부족한 경우가 많습니다.

이처럼 영양 불균형을 해소하기 위해 종합 비타민과 멀티 비타민들을 복용하시는 분들이 많으실 텐데요. 오늘은 종합비타민과 멀티비타민의 차이점에 대해서 정리해보려고 합니다.

1. 종합비타민

비타민 A, B군(1종 이상), C, D, E 중에서 5가지가 모두 포함된 영양제입니다.

식품의약품 안전청 영양정책과에 따르면 위의 5가지 항목을 반드시 포함하며, 1일 영양소 기준치의 30% 이상씩을 함유할 때 표기할 수 있습니다.

단, 종합비타민의 조건을 충족시켰다 하더라도 업체가 굳이 원할 경우 멀티비타민으로 표기할 수 있습니다.

실제로 종합비타민이더라고 하더라도 멀티비타민으로 판매하는 제품들이 있는 만큼 제품함유량 표기를 확인하고 구매를 하는 것이 좋겠습니다.

2. 멀티비타민(=복합비타민=혼합비타민)

비타민 A, B군(1종 이상), C, D, E 중에서 2가지 이상이 포함된 영양제입니다.

식품의약품 안전청 영양정책과에 따르면 필수비타민 5가지 중에서 2가지 이상의 비타민을 1일 영양소 기준치의 30% 이상씩 함유하고 있을 때 표기할 수 있습니다.

비타민 중에서도 비타민 B군에는 그 자체적으로 함유하고 있는 비타민 종류가 많은데요,

비타미 B군 : 티아민(B1), 리보플래빈(B2), 나이아신, 피리독신(B6), 판토텐산, 코발라민(B12), 엽산, 비오틴 등 8종

식약청에 따르면 비타민 B군에 속하는 비타민의 개수가 몇 개 이든지 간에 비타민 1종으로 취급하고 있습니다.

예를 들어, 비타민A, B1, B6, C, D, K가 들어있는 경우에는 비타민B1과 B6가 1종으로 취급되어 6종이 아닌 5종의 비타민이 포함된 것으로 인정되며, 5종이긴 하지만 필수 비타민인 비타민E가 포함되어 있지 않으므로 종합비타민으로 표기할 수가 없습니다.

3. 종합비타민 vs 멀티비타민 선택방법

종합비타민과 멀티비타민 제품들의 함유량을 살펴보면, 멀티비타민은 각 비타민의 일일 영양소 기준치의 30~300%의 함유량을 가지고 있으나, 종합비타민은 일일 영양소 기준치의 30~100% 사이의 함유량을 가지고 있습니다.

때문에 복용자의 건강상태와 현재 복용하고 있는 영양제 종류, 식습관 등에 따라 선택하시면 되겠습니다.

자신의 건강상태가 양호하며 영양소의 불균형 예방차원이라면 종합비타민이 좋은 선택이 될 것이며, 식단관리를 잘하고 있고 특정한 영양소를 강화하고 싶으실 경우에는 멀티비타민을 고르시는 것이 좋은 선택이 될 수 있습니다.

이상으로 종합비타민과 멀티비타민의 차이점에 대하여 알아보았습니다.

바쁜 일상생활에서도 필수영양소인 비타민을 챙겨드시고 활기찬 하루 보내시기 바라겠습니다.

블로그 광고 애드센스 용어 CPC, CTR, RPM 정리(feat.페이지 뷰, 노출수, 방문자수)

OSMU-PIPELINE — Sat, 2 Sep 2023 09:30:14 +0900

블로그 애드센스 용어 CPC, CTR, RPM 정리

1. 페이지 뷰(조회수) vs 노출수 vs 방문자수

애드센스 용어를 설명드리기 전에 기본적으로 이해하고 넘어가야 될 부분부터 설명을 드리겠습니다.

페이지 뷰, 노출수, 방문자수는 얼핏 보면 비슷해 보이지만 엄연히 다른 뜻을 가지고 있습니다.

페이지뷰(Page View : pv)

블로그 방문자가 애드센스 광고가 게재된 페이지를 조회한 수를 말합니다. 예를 들어 방문자가 작성자의 글을 3개를 보게 된다면 글마다 페이지가 다르기 때문에 페이지뷰는 3이 됩니다.

노출수

방문자에게 노출된 광고의 개수, 즉 방문자가 클릭은 하지 않았더라도 화면상에 노출된 광고의 개수를 뜻합니다. 예를 들어 한 페이지에 광고가 2개가 보였다면 노출수가 2가 되는 것이고, 만약 광고가 2개씩 있는 페이지에서 페이지 뷰가 100pv가 된다고 하면 노출수는 200이 됩니다.

방문자수

블로그를 방문한 방문자수입니다. 이 방문자수는 아이디와 ip 등으로 구별하므로, 블로그의 다른 페이지나 다른 글을 조회하더라도 방문자수는 1로 집계됩니다. IP를 변경해서 블로그 방문자수를 늘리려는 꼼수를 쓰는 경우도 있는데 구글에서는 어떠한 방식으로든 색출하게 되어있으니 그러한 모험은 하지 않는 것이 좋습니다.

클릭수

방문자가 애드센스 광고를 클릭한 횟수입니다.

2. CPC

Cost Per Click의 약자이며, 클릭당 수익을 말합니다. 블로그의 방문자가 광고를 한번 클릭했을 때 게시자가 얻게 되는 수익입니다.

이 CPC는 글의 주제를 선정하는데있어서 아주 큰 영향을 끼칩니다. 쓴 글의 주제에 따라 배정되는 광고의 종류도 달라지기 때문에 CPC 또한 천차만별입니다. 고단가의 광고가 달리는 키워드 중에는 금융, 보험, 부동산 등 돈과 관련된 주제들이 있으며, 그만큼 포스팅의 경쟁률도 높습니다. 따라서 힘들지만 고단가의 주제로 포스팅을 할 것이냐 아니면 단가는 낮지만 경쟁이 쉬운 주제로 포스팅을 할 것이냐 하는 전략을 세우는 것이 중요합니다.

CPC를 구하는 공식은 다음과 같습니다.

CPC = 광고클릭으로 발생한 총 수익 / 클릭 수

3. 페이지 CTR

Click Through Rate의 약자로 클릭률을 말합니다. 이 CTR은 클릭수를 페이지 뷰로 나눈 값인데요,

한마디로 페이지뷰당 클릭수입니다. 페이지 조회수가 200회이고 광고클릭이 1이 발생하게 된다면 클릭률은 0.005, 즉 0.5%가 됩니다. 이 CTR이 높다는 것은 게시글이 광고클릭을 유도하기 좋은 주제의 글이라는 뜻이 됩니다.

CTR의 공식은 다음과 같습니다.

CTR = 클릭수 / 페이지 뷰

4. 페이지 RPM

Revenue Per Mille의 약자입니다. revenue는 수익, Mille은 라틴어로 1000을 뜻하기 때문에 페이지 뷰 1000회당 얻는 수익을 말합니다. 예를 들어 총 페이지 뷰(pv)가 2000회이고 그로 인한 수익이 4달러이면 RPM은 2달러가됩니다. 한 달 조회수는 대체적으로 1000회를 넘기기 때문에 이것을 기준으로 대략적으로 얻는 수익을 계산할 때 많이 쓰는 지표입니다.

RPM의 계산식은 아래와 같습니다.

RPM = (수익 / 페이지 조회수) X 1000

민사소송 VS 형사소송 차이점 알아보기

OSMU-PIPELINE — Sat, 26 Aug 2023 07:26:35 +0900

우리가 일상생활하면서, 또는 드라마나 영화를 보면서 민사소송, 형사소송이라는 단어를 많이 접하셨을 것입니다.
하지만 그 뜻을 정확하게 설명해주지도 않고 딱딱한 법률 용어이다 보니 그냥 듣고 지나치는 경우가 많았는데요.
이번에는 민사소송과 형사소송의 차이점에 대해서 정리해보려고 합니다.

먼저 소송의 뜻부터 짚고 가보겠습니다.

소송
재판에 의하여 원고와 피고 사이의 권리나 의무 따위의 법률관계를 확정하여 줄 것을 법원에 요구함.

소송의 뜻을 좀 더 풀어보자면 개인과 개인 또는 개인과 국가 간 등의 분쟁을 해결하기 위해 국가기관인 법원이 재판권에 의해 법률적 또는 강제적으로 분쟁을 해결 및 조정하기 위한 절차를 말합니다.

▶ 형사소송

이해가 쉽게 살인미수사건을 예로 들어보겠습니다.

살인이라는 행위는 국가가 미리 정해 놓은 형법의 적용을 받게 되는 사건으로, 강도, 폭행, 절도, 사기 등이 이에 해당됩니다. (그밖에 형법에는 위조범죄, 공무원범죄, 과실범죄, 풍속범죄 등도 포함)

이 형법에 속하는 범죄들은 사회질서 유지를 위해 국가기관이 개입하여 가해자에게 형벌을 주게 되는데 이에 해당되는 것이 형사소송입니다.

형사소송에서는 국가기관인 검찰이 원고가 되고 가해자가 피고인이 됩니다.

(원고, 피고, 피고인의 차이에 대해 알아보기 )

때문에 국가수사기관인 경찰과 검찰이 범죄를 입증하기 위해 수사하고 범죄자를 처벌하게 됩니다.

형사소송은 국가가 범죄자에게 형벌권을 행사하여 가해자를 벌금이나 징역형으로 처벌하는 것이 주목적입니다.

▶ 민사소송

이번엔 피해자의 입장에서 생각해 보겠습니다.

피해자의 입장에서는 부상으로 인해 정신적인 트라우마가 생겼을 것이고, 일을 못하게 되는 등 피해를 보게 될 것입니다.

피해자는 피해보상을 받기 위해서 가해자를 상대로 소송을 진행할 수 있는데, 이때 진행하는 것이 바로 민사소송입니다.

즉, 개인과 개인 사이에서의 분쟁을 해결하기 위한 소송인 것이죠.

이때 원고는 피해자, 피고는 가해자가 됩니다.

친구가 빌린 돈을 갚지 않는다거나 전세금을 돌려받지 못할 때 등이 민사소송에 해당됩니다.

일반 민사소송에서는 범죄의 입증의무가 원고에게 있습니다.

때문에 개인이 입증 자료를 수집한다거나, 법률을 잘 아는 변호사를 선임하는 등의 행동을 하게 됩니다.

이상으로 일상생활에서 자주 접하는 용어인 민사소송, 형사소송에 대해 정리해 보았는데요,
이러한 기본 개념을 알고 있는 상태에서 법률적인 상황에 직면하게 된다면, 상황을 이해하는데 많은 도움이 될 것이라 생각합니다. 아무쪼록 이해하시는데 작은 도움이라도 되었으면 좋겠습니다.

원고? 피고? 피고인? 이제 헷갈리지 말자고요~(feat.피의자)

뉴스나 드라마에서 원고, 피고라는 말을 자주 듣긴 하는데, 일상생활에서는 잘 사용하는 단어가 아니어서 저처럼 헷갈리시는 분들이 많으실 거라 생각합니다. 자주 듣는 단어라 사실 헷갈리지

semo-info.com

OEM? ODM? 이제 그만 헷갈리자고요~

OEM과 ODM... 저는 매번 들으면서도 헷갈리더라고요. 헷갈리는 개념일 때는 영어의 풀네임을 해석하면서 의문이 풀리는 경우가 많은데 아무리 풀네임을 해석해 봐도 매번 헷갈립니다. Original Equipme

semo-info.com

원고? 피고? 피고인? 이제 헷갈리지 말자고요~(feat.피의자)

OSMU-PIPELINE — Sat, 5 Aug 2023 02:09:50 +0900

뉴스나 드라마에서 원고, 피고라는 말을 자주 듣긴 하는데, 일상생활에서는 잘 사용하는 단어가 아니어서 저처럼 헷갈리시는 분들이 많으실 거라 생각합니다.
자주 듣는 단어라 사실 헷갈리지만 아는척하면서 자연스럽게 넘어가곤 했었는데, 이젠 명확하게 알고 싶어 해당 내용을 정리해 보았습니다.

▶ 원고 vs 피고

먼저 사전적인 의미는 다음과 같습니다.

원고 : 소송을 제기하여 재판을 청구한 사람
피고 : 소송을 당한 사람

여기까지는 일반적으로 설명할 때 얘기하는 부분이죠.
근데 여기서 한번 더 들어가게 되면 더 쉽게 기억할 수 있습니다.
바로 한자 뜻풀이입니다.

원고

원(原 또는 源) : 근원 원
고(告) : 고할 고, 알릴 고
고함의 근원이라는 뜻이므로 소송을 제기한 당사자가 됩니다.
이 근원 원자를 쓰는 단어들에는 원동력(움직임을 일으키는 근본), 원본(본디의 서책), 어원(말의 근원) 등이 있는데, 이처럼 원천적이고 근본적임을 나타낼 때 사용됩니다.

피고

피(被) : 입을 피, 당할 피
고(告) : 고할 고, 알릴 고
고함을 당하다는 뜻이므로 소송을 당한 측의 당사자가 됩니다.
이 당할 피를 쓰는 단어들에는 피해자(해를 입은 사람), 피부양자(부양을 받는 사람), 피의자(의심을 당하는 자), 피습(습격을 당하는 것) 등이 있습니다.

일상생활에서도 많이 쓰이는 단어들이 같은 뜻의 한자를 쓰고 있어서 어렵지 않게 외워지실 거라 생각합니다.
이렇게 한자 뜻풀이만 해봐도 일상생활에서 많이 헷갈리는 용어들을 쉽게 구별할 수 있으니 참고하시면 좋겠습니다.

▶ 피고 vs 피고인 vs 피의자

소송에는 민사소송과 형사소송이 있는데요.
피고는 민사소송에서 사용하는 용어입니다.

(민사소송, 형사소송의 차이점에 대해 알아보기)
괜히 피고라는 말을 들으면 뭔가 나쁜 일을 저질러서 소송을 당한 자라는 생각이 들어 인식이 좋지는 않은데요.
원고와 피고는 단순히 소송을 신청한자와 소송을 당한 자의 뜻을 가지므로 피고라고 해서 죄가 있는 것이 아닙니다. 죄의 유무는 판사에 의해 결정됩니다.

하지만 피고인은 다릅니다.
피고인은 형사소송에서 사용되는 용어인데요.
형사소송은 간단히 말해 국가가 범죄자를 처벌하기 위한 절차이기 때문에 원고는 국가기관인 검사가 됩니다.
검사가 형사사건의 재판을 청구하는 것을 공소라고 하는데요.
수사과정에서는 피의자(의심을 받는 자)의 신분으로 수사를 받다가, 검사가 공소를 하게 되면 피고인의 신분으로 재판에 서게 됩니다.

아무래도 수사기관에서 수사를 끝마치고 검사가 죄의 유무를 입증하기 위한 재판을 하는 과정에서 피고인이란 용어가 등장하기 때문에 피고와 피고인의 무게감이 많이 다릅니다.

이처럼 민사소송에서는 피고라는 용어를 사용하고 형사소송에서는 피고인이라는 용어를 사용하는데요,
단순히 피고라는 용어에 사람 '인'을 붙여서 부르는 게 아닌 명백히 다른 의미라는 점을 짚고 넘어가시면 좋겠습니다.

다시 한번 더 정리하자면

피고 : 민사소송에서 단순히 소송을 당한 자의 의미이며, 죄의 유무와는 관련이 없음.
피고인 : 형사소송에서 죄의 유무를 입증하기 위해 법정에 서게 된 자.

라고 할 수 있겠습니다.

이상 많이 헷갈리실법한 원고, 피고, 피고인, 피의자 등 법률 용어에 대해 정리해 보았습니다.
헷갈리셨던 분들에게 조금이나마 쉽게 외우시는데 도움이 되었으면 좋겠습니다.

아는 만큼 보인다고 했던가요, 이젠 TV나 드라마를 볼 때 원고 측에 검사가 있는지, 용어를 피고인으로 쓰는지 등을 관심 있게 보게 될 것 같네요~

민사소송 VS 형사소송 무슨 차이인거죠?

우리가 일상생활하면서, 또는 드라마나 영화를 보면서 민사소송, 형사소송이라는 단어를 많이 접하셨을 것입니다. 하지만 그 뜻을 정확하게 설명해주지도 않고 딱딱한 법률 용어이다 보니 그냥

semo-info.com

OEM? ODM? 이제 그만 헷갈리자고요~

semo-info.com

OEM? ODM? 이제 그만 헷갈리자고요~

OSMU-PIPELINE — Tue, 25 Jul 2023 13:15:57 +0900

OEM과 ODM... 저는 매번 들으면서도 헷갈리더라고요.

헷갈리는 개념일 때는 영어의 풀네임을 해석하면서 의문이 풀리는 경우가 많은데

아무리 풀네임을 해석해 봐도 매번 헷갈립니다.

Original Equipment Manufacturing : 원래의 장비 제조? 이게 주문자 상표부착 생산 방식과 선뜻 연관이 되지 않고

Original Development Manufacturing : 원래의 개발 제조? 생산자 개발 방식이라는 개념과 연관이 잘되질 않더라고요.

그래서 이번에야 말로 헷갈리지 않게 정리하고 넘어가기 위해 글을 정리해 봅니다.

▶ OEM(Original Equipment Manufacturing)

간단하게 말해 주문자와 생산자가 분리되어 있는 형태입니다.

보통 제조업은 기업이 스스로 제품을 설계, 개발하고 제조설비를 통해 생산하고 제품을 판매하는 구조를 가지고 있습니다.

대표적으로 삼성, 현대가 될 수 있겠죠. 이런 대기업들은 막대한 투자금으로 공장을 지어 제조설비를 구축하기가 쉽습니다.

하지만 이제 시작하는 스타트업이나 중소기업들은 이러한 제조 설비를 구축한다는 것이 엄청난 리스크가 될 수 있습니다.

때문에 이미 생산 설비를 갖춘 기업에게 위탁을 함으로써 시간, 돈, 위험성을 줄일 수가 있는데 이러한 방식이 OEM 방식입니다.

주문자가 좋은 아이디어가 있어 제품을 기획하고, 설계, 개발까지 진행하지만 제품의 생산은 다른 제조업체에게 위탁하는 것입니다.

이렇게 생산된 제품에는 주문자의 상표를 부착하여 판매하는 과정을 거치게 되므로 주문자 상표부착 생산 방식이라고 부릅니다.

가장 대표적으로 애플은 폭스콘, 퀄컴은 TSMC가 제조 부분을 담당하고 있습니다.

나이키의 경우, 러닝화의 20%가량이 대한민국의 태광실업에서 제조된 후 나이키의 상표가 부착되어 판매가 되고 있습니다.(산업별로 용어는 다르지만 아웃소싱, 외주, 위탁, 펩리스 등도 개념은 OEM과 비슷하다고 볼 수 있습니다.)

이렇게 다른 제조업체에게 생산을 위탁할 때는 아무래도 제조장비, 제조환경, 제조 품질들을 꼼꼼히 따져서 최종적으로 선별하게 될 것입니다.

Original의 사전적인 의미에는 '독창적인'이라는 뜻도 있는데

Original Equipment Manufacturing = '독창적인 장비로 제조하는 업체에 위탁한다'

라고 생각하시면 이해가 쉬울 것이라 생각됩니다.

▶ ODM(Original Design/Development Mamufacturing)

ODM은 OEM의 방식에 설계나 개발이 추가된 방식입니다. OEM은 단순히 설계도를 받아 제조를 한 뒤 상표를 부착하는 방식이라면, 제조업체에서 설계, 개발부터 제품 생산까지 모두 처리한 뒤 주문자의 상표를 부착하여 판매를 하는 방식입니다.

만약 위에 예로든 태광 실업이, 신발을 직접 디자인하고 설계해서 제품까지 완성하게 된다면 ODM(생산자 개발 방식)이 되는 것입니다.

이러한 ODM 업체는 상당히 기술력이 있는 회사들입니다. 하지만 자체 브랜드의 인지도가 낮기 때문에 다른 브랜드를 부착하여 판매를 하게 됩니다.

이러한 ODM 기업에는 국내의 코스맥스와 한국콜마가 대표적인데, 유명 화장품 브랜드인 로레알, 시세이도, 에스티로더 등에 납품을 하고 있습니다.

▶ OEM과 ODM

이렇듯 OEM과 ODM은 주문자의 상표를 부착하여 판매한다는 점은 동일합니다.

생산자의 입장에서 봤을 때 제조만 담당하느냐, 설계/개발까지 담당하느냐에서의 차이가 있습니다.

Original Equipment Manufacturing : '독창적인 장비로 제조'

Original Design/Development Manufacturing : '독창적인 설계/개발로 제조'

이상으로 OEM과 ODM에 대해서 알아보았습니다.

저처럼 매번 헷갈리셨던 분들에게 조금이나마 도움이 되었으면 좋겠습니다.

원고? 피고? 피고인? 이제 헷갈리지 말자고요~(feat.피의자)

semo-info.com

<2024년>기본증명서 인터넷 발급방법(PDF) + 간편인증(비회원)

OSMU-PIPELINE — Sat, 22 Jul 2023 22:14:51 +0900

⩗기본증명서란?

기본증명서는 개인의 출생과 사망 등에 관한 사실을 증명하는 서류로 출생, 국적변경, 개명, 친권, 사망 등의 내용이 기재됩니다. 기본증명서 일반은 현재 유효한 사항이 표시되며 기본증명서 상세는 개명 전 이름과 같이 과거의 사항도 함께 표시됩니다.

기본 증명서의 개념

호주제 폐지

호주제는 호주(집주인)를 중심으로 한 가족 구성원의 출생, 혼인, 사망 등 신분 변동을 기록하는 신분등록제였습니다. 예전에는 남성이 우선적으로 호주가 되었었고, 여성운동의 결실로 2008년 1월 1일 부로 호주제가 폐지되었습니다.

호적등본? 그리고 제적등본?

호적부 : 호주의 변경 등을 기록한 장부
등본 : 장부의 모든 내용을 열람할 수 있는 문서
초본 : 장부의 내용 중 일부를 열람할 수 있는 문서

호적부에는 호주를 중심으로 한 가족의 인적사항이 기록되어 있습니다. 기존 호주가 사망하게 되면 장남 등이 호주를 승계를 하게 되고 이 과정에서 새로운 호적부가 만들어지게 되는데 기존의 호적부는 폐쇄가 됩니다. 이렇게 폐쇄가 된 호적부를 제적부라고 부릅니다.

2008년에 호주제가 폐지되면서 기존 호적부는 모두 폐쇄됨에 따라 현재는 제적부로 남아있습니다.

그래서 2007.12.31까지의 신분관계를 확인하려면, 제적등본을 발급받아야 하며, 2008년 1월 1일 이후의 신분관계 확인을 위해서는 가족관계증명서, 기본증명서, 혼인관계증명서 등을 발급받아야 합니다.

기본증명서 발급 방법은 크게 3가지로 나눌 수 있습니다.

첫째, 시군구청이나 읍면동사무소에서 직접 발급받는 방법
둘째, 무인민원발급기 사용
셋째, 인터넷 발급입니다.

그중 기본증명서 인터넷 발급 방법에 대해 알아보겠습니다.

1. <대한민국 법원-전자가족관계등록시스템> 홈페이지를 방문합니다.

<대한민국 법원-전자가족관계등록시스템>에서 수수료 없이 온라인으로 가족관계증명서를 발급받으실 수 있습니다.

>> [대한민국 법원-전자가족관계등록시스템] 홈페이지 바로가기

2. 기본증명서를 클릭합니다.

3. 약관 동의 → 신청인 정보 입력 → 간편인증 버튼을 클릭합니다.

※ PC방이나 공용 PC에서 사용 시 '키보드보안 프로그램 적용'을 눌러 보안 프로그램 설치를 권장드립니다.

4. 사용하기 편한 인증방법을 선택하고 간편인증을 완료합니다.

5. 가족관계등록부 열람/발급 신청 양식을 작성합니다.

※필요한 양식에 맞춰 가족관계등록부 열람/발급 신청을 작성합니다.

5. 수령방법에서 전자문서지갑은 모바일로 발급받고 싶을 때 사용하며, 전자문서지갑을 사용하시려면 먼저 정부24 앱에서 전자문서지갑 발급 신청을 하셔야 됩니다.
신청 완료 후, 수령방법에서 전자문서지갑을 선택하시게 되면 정부24 앱의 전자문서지갑 안으로 문서가 발급됩니다.
>>전자문서지갑 발급방법 및 확인방법 보러 가기

6. 프린터 버튼을 클릭합니다.

※ 인쇄창이 뜨지 않을 경우 팝업 차단이 활성화되어 있는지 확인해 보시기 바랍니다.

7. PDF로 저장 또는 Microsoft Print to PDF로 선택 후 인쇄 버튼을 클릭합니다.

※ Microsoft Print to PDF 선택 시 A3, A4 등 원하는 용지크기로 저장하실 수 있습니다.

<2025년>가족관계증명서 인터넷 발급방법(PDF) + 간편인증(비회원)

OSMU-PIPELINE — Fri, 21 Jul 2023 23:15:33 +0900

⩗가족관계 증명서란?

본인을 기준으로 부모, 배우자, 자녀를 표시하는 증명으로 보통 친자관계를 증명할 때 사용되며, 형제자매는 표시가 안 되므로 형제자매 관계를 증명하기 위해서는 부모의 가족관계증명서를 발급받아야 합니다.

가족관계증명서는 본인뿐만 아니라 한국에 거주하고 있는 직계가족(부모, 배우자 등)을 통해 발급받을 수 있습니다.

가족관계증명서 발급 방법은 크게 3가지로 나눌 수 있습니다.

첫째, 시군구청이나 읍면동사무소에서 직접 발급받는 방법
둘째, 무인민원발급기 사용
셋째, 인터넷 발급입니다.

그중 가족관계증명서 인터넷 발급 방법에 대해 알아보겠습니다.

1. <대한민국 법원-전자가족관계등록시스템> 홈페이지를 방문합니다.

<대한민국 법원-전자가족관계등록시스템>에서 수수료 없이 온라인으로 가족관계증명서를 발급받으실 수 있습니다.

>>[대한민국 법원-전자가족관계등록시스템] 홈페이지 바로가기

2. 가족관계 증명서를 클릭합니다.

3. 약관 동의 → 신청인 정보 입력 → 간편인증 버튼을 클릭합니다.

※ PC방이나 공용 PC에서 사용 시 '키보드보안 프로그램 적용'을 눌러 보안 프로그램 설치를 권장드립니다.

4. 사용하기 편한 인증방법을 선택하고 간편인증을 완료합니다.

5. 가족관계등록부 열람/발급 신청 양식을 작성합니다.

※필요한 양식에 맞춰 가족관계등록부 열람/발급 신청을 작성합니다.

5. 수령방법에서 전자문서지갑은 모바일로 발급받고 싶을 때 사용하며, 전자문서지갑을 사용하시려면 먼저 정부24 앱에서 전자문서지갑 발급 신청을 하셔야 됩니다.
신청 완료 후, 수령방법에서 전자문서지갑을 선택하시게 되면 정부24 앱의 전자문서지갑 안으로 문서가 발급됩니다.
>>전자문서지갑 발급방법 및 확인방법 보러 가기

6. 프린터 버튼을 클릭합니다.

※ 인쇄창이 뜨지 않을 경우 팝업 차단이 활성화되어 있는지 확인해 보시기 바랍니다.

7. PDF로 저장 또는 Microsoft Print to PDF로 선택 후 인쇄 버튼을 클릭합니다.

※ Microsoft Print to PDF 선택 시 A3, A4 등 원하는 용지크기로 저장하실 수 있습니다.

<2024년>주민등록등(초)본 인터넷 발급방법(PDF) + 간편인증(비회원)

OSMU-PIPELINE — Sun, 16 Jul 2023 00:27:28 +0900

주민등록등본(초본) 발급 방법은 크게 3가지로 나눌 수 있습니다.

첫째, 시군구청이나 읍면동사무소에서 직접 발급받는 방법
둘째, 무인민원발급기 사용
셋째, 인터넷 발급입니다.

그중 주민등록등본(초본) 인터넷 발급 방법에 대해 알아보겠습니다.

1. 정부24 홈페이지를 방문합니다.

정부24에서 수수료 없이 온라인으로 주민등록등본(초본)을 발급받으실 수 있습니다.

>> 정부24 - 홈페이지 바로 가기

2. 주민등록등본(초본) 발급을 클릭합니다.

3. 발급하기 버튼을 클릭합니다.

4. 비회원 신청하기 버튼을 클릭합니다.

※ 회원이신 분은 '회원신청하기'를 선택하시면 되겠습니다.

5. 동의합니다를 선택합니다.

6. 동의합니다를 선택합니다.

※ PC방이나 공용 PC에서 사용 시 '키보드보안 프로그램 적용'을 눌러 보안 프로그램 설치를 권장드립니다.

7. 이름, 주민등록번호, 보안 문자 입력 후 확인 버튼을 클릭합니다.

8. 주민등록상의 주소에 속하는 시도와 시군구를 선택합니다.

9. 필요한 양식에 따라 발급형태를 선택합니다.

※특별한 양식이 없을 경우 '발급'을 선택합니다.

10. 수령방법을 선택하고 민원신청하기 버튼을 클릭합니다.

11. 간편인증을 클릭합니다.

※인증서가 있으신 분은 '공동•금융인증서'를 클릭하시고 진행하시면 되겠습니다.

12. 사용하기 편한 인증방법을 선택하고 간편인증을 완료합니다.

13. 신청한 민원서비스의 문서출력을 클릭합니다.

14. 인쇄 버튼을 클릭합니다.

※ 인쇄창이 뜨지 않을 경우 팝업 차단이 활성화되어 있는지 확인해 보시기 바랍니다.

15. PDF로 저장을 선택하고 저장 버튼을 클릭합니다.

삼성 갤럭시 A25, 렌더링 및 예상 스펙

OSMU-PIPELINE — Fri, 7 Jul 2023 01:49:34 +0900

고가의 플래그십 스마트폰이 주를 이루는 시장에서 보급형 모델이 소비자들 사이에서 인기를 끌고 있습니다.

갤럭시 A 시리즈가 그 대표작일 텐데요. 갤럭시 A 시리즈로 유명한 삼성전자가 최근 LTE 기기로 갤럭시 A24를 출시했습니다. 일반적으로 LTE 모델로 출시된 이후 일부 스펙을 조정해서 5G 모델로 별도 출시를 하는 방식인데 갑자기

갤럭시 A24 5G 모델이 아닌 갤럭시 A25의 렌더링이 등장했습니다.

이에 갤럭시 A25의 렌더링과 유출된 정보에 대해 살펴보겠습니다.

전면 디자인

갤럭시 A24와 유사하게 갤럭시 A25는 U자형 노치 안에 전면 카메라가 위치하는 인피니티-U 디스플레이를 탑재할 것으로 예상됩니다. 렌더링에서는 화면 상단과 하단의 베젤이 비대칭으로 고급형 기기에 비해 다소 두꺼워 투박한 모습을 보여 줍니다. 측면 프레임 디자인은 갤럭시 A24와 일관성을 유지하며, 일체감 있는 디자인을 보여줍니다.

후면 디자인

이전 모델인 갤럭시 A24와 매우 유사하다는 것을 볼 수 있습니다. 후면 디자인은 세로 배열의 트리플 카메라를 탑재하고 있으며, 다른 갤럭시 모델에서 흔히 볼 수 있는 친숙한 물방울 카메라 레이아웃을 보여줍니다. 후면 패널은 A24에 사용된 유리느낌의 글라스틱 패널을 유지하지만 무광택 마감을 추가하여 세련된 외관을 제공할 것이라고 합니다.

예상 사양

최근 보고서에 따르면 Galaxy A25는 보급형 5G 스마트폰 시장에 진출하는 삼성의 첫 번째 제품이 될 것입니다.

6.44인치 디스플레이와 퀄컴 스냅드래곤 768 프로세서로 예측되며, 용량은 128, 256GB 두 가지로 제공될 것이라고 합니다.

이밖에 3.5mm 이어폰 잭과 USB-C 포트를 제공할 것이며, 지문센서는 측면 전원 버튼에 통합된 형태로 제공된다고 합니다.

그리고, 구체적인 세부 사항은 아직 알 수 없지만 Galaxy A25의 메인 카메라는 64MP 일 것으로 추측되고 있습니다. 전작인 A24에서는 은 50MP(메인) + 5MP(초광각) + 2MP(접사) 트리플 카메라 구성이었습니다. 또한 상당한 크기의 5000mAh 배터리가 탑재될 것으로 예상하고 있습니다.

갤럭시 S23 FE : 가성비 좋은 스마트폰의 귀환

삼성전자의 갤럭시 S23 FE(팬에디션)가 올 4분기 출시를 앞둔 가성비 스마트폰으로 주목받고 있다. FE는 갤럭시 S20에서 첫 등장 후로 갤럭시 S22 버전으로는나오지 않아 단종설에 둘러싸여있었는데

semo-info.com

아스파탐(Aspartame)! 발암물질 2B군 지정임박, '제로 칼로리' 식품들 이대로 안전한가?

OSMU-PIPELINE — Sun, 2 Jul 2023 18:38:16 +0900

최근 세계보건기구(WHO) 산하 국제암연구소(IARC)가

아스파탐을 발암 가능성이 있는 물질로 분류한다는 발표가 있어

식품 및 음료 산업 내에서 우려를 불러일으켰습니다.

아스파탐? 생소한 단어이실 텐데요,
아스파탐이란 무엇인지 한번 알아보겠습니다.

1. 아스파탐이란?

<식품과학사전>
아스파틸 페닐알라닌 메틸 에스터. 아스파트산과 페닐알라닌의 메틸 에스터인 합성 감미료로 단맛은 설탕보다 약 160~200배이다. 뒷맛이 없고 당뇨병에도 사용할 수 있다. 대사 과정에서 페닐알라닌이 유리되므로 페놀케톤뇨증 환자는 사용할 수 없다. 식품 첨가물의 하나이다.

<국어사전>
단맛이 설탕의 200배나 되는 아미노산계 식품 감미료. 설탕과 같은 탄수화물계가 아니므로 당뇨병 환자가 사용할 수 있다.

위 내용에서 알 수 있듯이 용어는 생소하지만
이미 우리 생활에서 많이 사용되고 있는
인공 감미료의 한 종류입니다.
열량은 1g당 4kcal로 설탕과 같습니다.
하지만 단맛이 200배나 강하기 때문에
1/200g으로도 같은 효과가 나타나
저칼로리 식품에 널리 사용되고 있습니다.
1965년에 발견된 이후 제로 콜라와 껌,
요구르트 등에 쓰였지만
아스파탐의 위험성 연구가
충분하지 않다는 지적도 있었습니다.

2. 아스파탐 암 유발 가능성 2B군 물질로 분류

세계보건기구(WHO:World Health Organization)에 따르면 발암 물질은
위의 분류처럼 1군, 2A군, 2B군, 3군, 4군으로
총 5개 등급으로 분류하고 있습니다.
이 중 아스파탐은
2B군인 "인체 발암 가능 물질"로
분류할 것이라는 것입니다.

발암물질 2B군은
"암을 일으킬 수 있지만, 암과 연관이 있다는
인체 연구 자료 또는 동물 실험 결과가
충분하지 않을 때 부여하는 등급" 입니다.

각 등급별 발암 물질을 찾아보면
다음과 같습니다.

1군 : 사람에게 암을 일으킨다는 증거가 있는 물질
-담배, 방사선, 라돈, 석면가루, 벤젠, 헬리코박터, 소금에 절인 생선, 소시지와 햄 등 가공육.

2A군 : 발암 추정물질, 동물에선 증거가 충분하나 사람에겐 부족한 경우
-교대근무, 기름으로 튀긴 음식, 소고기, 돼지고기 등.

2B군 : 발암 가능 물질, 인간에게 제한적 증거가 있고 동물에서도 증거가 충분하지 않은 경우
-커피, 김치, 코코넛 오일, 스마트폰의 전자파와 자기장 등.

[WHO-IARC 방문하기]

IARC – INTERNATIONAL AGENCY FOR RESEARCH ON CANCER

LABORATORY SUPPORT, BIOBANKING, AND SERVICES

www.iarc.who.int

3. 아스파탐이 사용된 제품

일반 설탕과는 달리 칼로리가 매우 적은 인공
감미료이므로 저열량 식품에 널리 사용됩니다.
제로칼로리를 내건
제로 탄산음료, 껌, 막걸리, 무설탕 캔디 등이
이에 해당됩니다.

4. 인공 감미료의 위험성

WHO 산하 국제식품첨가물
전문가위원회(JECFA)는 1981년 이후
아스파탐이 일일 제한량인 50mg/kg 이내로 섭취하면 안전하다고 해왔습니다.
예를 들자면, 체중이 60㎏인 성인이
음료에 함유된 아스파탐의 양에 따라
매일 12~36캔의 다이어트 탄산음료를 마셔야
위험에 처할 수 있는 양입니다.
하지만 이번에 IARC가 아스파탐을
발암물질 2B군으로 지정하게 되면
기존의 JECFA의 기준에도 변화가 있을
가능성이 커졌습니다.
앞서 WHO는 지난 5월 “체중조절을 위해
인공감미료를 사용하지 말라"라는
새로운 권장 사항을 발표했습니다.
갈수록 점점 더 많은 인공감미료가
식품에 첨가되는 추세에 따라서 관련된
잠재적 위험성을 알리기 위한 것입니다.
WHO가 명명한 인공감미료에는 잘 알려진
사카린, 스테비아, 아스파탐을 비롯해
수크랄로스, 네오탐, 아세설팜칼륨,
사이클라메이트 등이 포함됩니다.

5. 대처방안

이미 많은 식품에서 아스파탐을 쓰고 있기 때문에
아스파탐으로부터 완벽히
벗어날 방법은 없을 것입니다.
2B군 발암물질로 지정되기 이전 JECFA에서
발표한 위험 섭취 기준을 보더라도
상당히 과도한 섭취량입니다.
혹여 아스파탐이 발암물질로 지정되어,
더 엄격한 기준을 적용받게 되더라도
일반적인 섭취량을 훌쩍 뛰어넘을 것입니다.
때문에 너무 과도한 우려는 하지 마시고
무엇보다 과도한 섭취를 자제하는 것이
중요해 보입니다.
또한 해당 제품군의 산업계에서도 대응 없이는
매출에 타격을 받을 수밖에 없기 때문에
아스파탐을 대체하는 방안을
발 빠르게 적용시켜 나갈 것입니다.
ㄱ
아래글은 관련업계 관계자의 인터뷰 글입니다.

국내 대표 막걸리 업체 서울장수는 상황에 따라 아스파탐 대신 다른 감미료를 사용하는 등 레시피 변경도 염두하고 있다.
서울장수 관계자는 “이번 사안에 대해 하위 기준이 명확하지 않기 때문에 식약처 등 외부 전문 기관 등의 하위 기준이 명확해진다면 후속 사항들을 보며 전면 교체도 검토할 예정”이라며 “관련 기관 및 업계 관계자들이 공동의 대응 기준을 마련해 나가며 함께 논의를 통해 대응할 것”이라고 말했다.

이처럼 관련 업계에서도 다른 감미료를 사용하는 등 발 빠르게 대처해 나갈 것이라 생각됩니다.
평상시에 더 많이 접하는 돼지고기, 소고기도
아스파탐보다 더 높은 발암물질 2A군에
속해 있는 만큼 너무 해당 제품들을
기피하기보다는 과도한 섭취를 자제하는 것이
중요할 것입니다.

갤럭시 S23 FE : 가성비 좋은 스마트폰의 귀환

OSMU-PIPELINE — Sun, 2 Jul 2023 13:31:55 +0900

삼성전자의 갤럭시 S23 FE(팬에디션)가 올 4분기

출시를 앞둔 가성비 스마트폰으로 주목받고 있다.

FE는 갤럭시 S20에서 첫 등장 후로

갤럭시 S22 버전으로는 나오지 않아

단종설에 둘러싸여 있었는데,

유출된 렌더링 이미지와 소문난 스펙으로

복귀에 대한 관심이 높아지고 있다.

유출된 장치의 세부사항을 살펴보자.

Galaxy S23 FE의 디자인

유출된 갤럭시 S23 FE의 렌더링 이미지에서는

상대적으로 갤럭시 S23 보다 상대적으로

두꺼운 베젤을 가진 것으로 보인다.

하지만 후면의 물방울 모양의 트리플 카메라가

탑재되어 전체적인 외관은
갤럭시 S23과 매우 흡사한 모습을 보여준다.
IT 팁스터인 아이스 유니버스(Ice Universe)는

갤럭시 A54와 비슷한 카메라 렌즈와

플래시 위치로 인해 주요 디자인 변경이

없을 것이라 예상하고 있다.

스펙

IT매체 샘모바일에 따르면 갤럭시 S23 FE는

5000만 화소 기본 카메라에 1200만 화소 초광각

렌즈와 망원 렌즈가 탑재될 것으로 알려졌다.

삼성전자의 엑시노스 2200 프로세서를 탑재해

효율적인 성능을 제공할 것으로 보인다.

8GB RAM 구성과 함께 128GB 및 256GB의

스토리지 옵션이 제공될 가능성이 높다.

또한 25W 고속 충전을 지원하는

4500mAh 배터리 탑재가 예상된다.

가격

FE모델은 프리미엄 스마트폰인 갤럭시 S시리즈 부품을

재활용하거나 사양을 낮춘 준프리미엄급이다.

2020년 갤럭시 S20 FE 출시 당시 S시리즈와 같은

애플리케이션 프로세서(AP)를 탑재했지만

출고가는 S시리즈보다 30~40만원 저렴한

89만 9800원으로 책정돼 화제가 됐었다.

이번에도 전작과 비슷한 가격이 될 것이라 예상된다.

FE시리즈가 메인 라인업에서 후퇴한 것은 삼성전자가

중저가 갤럭시A 시리즈의 성능 강화에 주력해 글로벌

시장점유율 확보에 기여했기 때문인 것으로 풀이된다.

FE 시리즈는 프리미엄 S 시리즈와 중가 A 시리즈

사이에서 독보적인 위치를 점하고 있지 못해

포지셔닝이 더욱 불확실하다.

삼성전자는 오는 7월 새로운 폴더블폰인

갤럭시 Z플립 5와 갤럭시 Z폴드 5 출시를

준비하는 가운데 4분기 갤럭시 S23 FE 출시로

제품 격차를 메우고 시장점유율을

확보하려는 의도로 보인다.

FE 모델의 잠재적인 부활과 함께 가성비

스마트폰으로 소비자에게 다양하게

어필할 수 있는 기회가 되길 바란다.

(참고: 제공된 정보는 작성 시점의 기사 및 소문을

기반으로 작성되었으며, Galaxy S23 FE의

정확한 사양 및 기능 확인을 위해

삼성전자의 공식 발표를 기다리고 있습니다.)

삼성 갤럭시 A25, 렌더링 및 예상 스펙

고가의 플래그십 스마트폰이 주를 이루는 시장에서 보급형 모델이 소비자들 사이에서 인기를 끌고 있습니다. 갤럭시 A 시리즈가 그 대표작일텐데요. 갤럭시 A 시리즈로 유명한 삼성전자가 최근

semo-info.com

selenium에서 암시적(implicit) VS 명시적(explicit) 대기의 차이점 및 사용법(feat. time)

OSMU-PIPELINE — Sat, 1 Jul 2023 21:54:46 +0900

selenium을 사용하다 보면 대기하는 시간을 활용하게 되는데 그중에는 대표적으로 3가지 방법이 있다.

1. time.sleep() : time 모듈 사용

from selenium import webdriver
import time

driver = webdriver.Chrome()
driver.get('https://wwww.naver.com')
time.sleep(10)

가장 대표적인 방법으로 지정한 시간 만큼 대기하는 방법이다.

가장 쉬운 방법이긴 하지만 이미 페이지 로딩이 끝났음에도 지정한 시간만큼 계속 대기해야 하는 loss time이 발생한다.

2. 암시적 대기(implicitly wait) : implicitly_wait() 메서드 사용

*특정 조건을 명시하지 않음

from selenium import webdriver

driver = webdriver.Chrome()
driver.get('https://wwww.naver.com')
driver.implicitly_wait(10)

.implicitly_wait(10)의 뜻은 네이버의 페이지 로딩이 끝날 때까지 최대 10초까지 기다린다는 뜻으로,

로딩이 끝나는 대로 다음 명령어를 수행하며, 10초가 넘어갈 동안 페이지 로딩이 끝나지 않는다면 다음 명령어를 수행하게 된다.

3. 명시적 대기(explicitly wait) : WebDriverWait, expected_conditions, By 필요

*특정 조건을 명시함

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

driver = webdriver.Chrome()
driver.get('https://www.naver.com')
wait = WebDriverWait(driver, 10)  # Wait for a maximum of 10 seconds

element = wait.until(EC.presence_of_element_located((By.ID, 'myElement')))

명시적 대기는 특정 조건이 발생할 때까지 대기하는 기능을 제공하고 있어 암시적 대기보다 세밀한 제어를 할 수 있다.

예를 들어, 네이버에 로그인을 하고 싶다면 페이지의 모든 요소가 나타날때까지 대기하는 것이 아닌 로그인 창에 대한 요소들의 로딩이 끝날 때까지만 대기하면 된다.

이처럼 페이지를 구성하고 있는 특정 요소가 사용자가 정한 조건에 부합할 때까지 대기할 경우에 사용한다.

.until(EC.presence_of_element_located((By.ID,'myElement')))

위의 부분이 사용자가 정하는 조건을 설정하는 부분이며,

presence_of_element_located((By.ID, 'myElement'))는 'myElement'라는 요소가 나타날 때까지 대기한다라는 뜻을 가진다.

요소의 상태에 따라 사용자가 정하는 조건에는 다음과 같이 다양한 방식들이 존재한다.

EC.title_is(...)
EC.title_contains(...)
EC.presence_of_element_located(...)
EC.visibility_of_element_located(...)
EC.visibility_of(...)
EC.presence_of_all_elements_located(...)
EC.text_to_be_present_in_element(...)
EC.text_to_be_present_in_element_value(...)
EC.frame_to_be_available_and_switch_to_it(...)
EC.invisibility_of_element_located(...)
EC.element_to_be_clickable(...)
EC.staleness_of(...)
EC.element_to_be_selected(...)
EC.element_located_to_be_selected(...)
EC.element_selection_state_to_be(...)
EC.element_located_selection_state_to_be(...)
EC.alert_is_present(...)

다시한번 요약하자면, 암시적 대기는 사용자의 특정한 조건 없이 모든 요소에 대한 전역 대기 시간을 설정하는 반면 명시적 대기는 사용자의 특정 조건을 명시(정의)하고 그 조건에 부합할 때까지의 대기시간을 설정하는 것이다.

위의 세가지 방법 중 어떤 것이 가장 좋다고 할 수 없으며 상황에 따라 적절하게 사용하면 될 것이다.

<봄>3월이 제철인 과일들의 특징과 효능 - 2월은 놓쳤어도 3월은 놓치지 마세요!!

OSMU-PIPELINE — Sun, 26 Feb 2023 04:08:41 +0900

1. 딸기(1월~5월)

원래 딸기는 이른 봄부터 꽃이 피어서

5월~6월이 제철이었다고 합니다.

하지만 날씨가 더워지면

물러지고 보관기간도 짧아져서

겨울부터 비닐하우스에서 키운다고 합니다.

그래서 딸기의 제철 기간은 1월~5월입니다.

효능

- 비타민 C와 식이섬유가 풍부합니다.

식이섬유는 소화를 돕고 혈당을 안정시키는데 도움을 준다고 하네요.

- 항산화제인 안토시아닌을 함유합니다.

안토시아닌은 심혈관 건강을 촉진하고 염증을 줄이는 데 도움을 준다고 합니다.

- 다양한 미네랄과 비타민이 풍부합니다.

엽산, 칼륨, 망간, 마그네슘등이 포함되어 있다고 하니

꼭 드셔보아야겠죠?

2. 한라봉(12월~3월)

한라봉은 일본 구마모토현의 특산물로 유명합니다.

1990년대부터 도입해 제주도에서 재배가 이루어지고 있는데요.

현재는 제주도의 대표적인 특산품이 되었습니다.

한라봉은 포멜로와 귤의 잡종으로,

다른 감귤류 과일과는 다른 독특한 맛인데,

달콤하면서도 새콤한 맛을 가지고 있습니다.

우선 과즙이 풍부하고 식감이 부드러워서 먹기에 아주 좋습니다.

효능

- 높은 함량의 비타민 C가 있습니다.

면역 체계를 강화해 질병으로부터 보호하고,

건강한 피부를 촉진하는 데 도움을 줍니다.

- 플라보노이드가 함유되어 있습니다.

플라보노이드는 염증을 줄이고

심혈관 건강을 증진시키는 데 도움을 줍니다.

- 건강에 아주 좋은 저칼로리 과일이다.

개당 약 40-60 칼로리밖에 들어 있지 않아서

건강한 식단 관리에 도움을 줍니다.
-식이섬유를 함유하고 있다.

따라서, 소화 촉진과 변비 예방에 도움을 줍니다.

3. 천혜향(1월~3월)

2000년대 초에 한라봉과 마찬가지로

일본에서 들여온 품종이에요.

공모를 통해서 '천혜향'이라 이름을 지었는데,

'하늘이 내린 향기'라는 뜻이라네요.

한라봉처럼 특유의 향이 있는데요,

맛은 감귤에 비해 달짝지근하면서도,

오렌지 특유의 새콤한 맛도 납니다.

효능

-비타민 C와 카로티노이드가 풍부한데요,

이는 항산화 작용으로 인체의 면역력 강화 및 노화 방지에 도움을 줍니다.

-식이섬유 많이 함유되어 있습니다.

장 건강을 촉진하고 변비 예방에 효과가 있습니다.

-루테인이 함유되어 있습니다.

루테인은 눈 건강을 촉진하는데

노안 등의 질환 예방에 효과적입니다.

-식욕 억제 효과도 있습니다.

천혜향을 간식으로 먹으면

적은 양으로도 포만감을 느끼게 되어

다이어트에 도움을 줄 수 있습니다.

지금까지 3월이 제철 과일인 딸기, 한라봉, 천혜향에 대해 알아보았네요.

어떤 과일이던 제철일 때가 가장 싸고 맛있으니 시기를 놓치지 마시고,

맛있게 먹고 건강도 지키셨으면 좋겠습니다~^^

DRS/DPM 기능 원리

OSMU-PIPELINE — Wed, 19 Oct 2022 04:04:14 +0900

DRS (Distributed Resource Scheduler) 클러스터란

<DRS>

VMware vSphere에서 클러스터를 구성한다고 할 경우에는 보통 두 가지 기능을 묶어서 말하는데 바로 HA 클러스터와 DRS 클러스터 기능이다. 우리가 보통 운영체제에서 클러스터 서비스를 이용한다라고 표현하는 것은 대부분 HA 클러스터 기능, 즉 물리적인 서버에서 하드웨어적인 장애가 발생하였을 경우 서비스를 Failover 하는 기능을 의미한다.

vSphere에서도 마찬가지로 HA 클러스터 기능을 가지고 있다. ESXi 서버의 물리적인 장애가 발생할 경우 장애가 발생한 ESXi 서버에서 작동 중이던 가상 머신을 HA 클러스터 내의 다른 ESXi 서버에게 Failover 시켜 주는 기능이다. 반면에 DRS클러스터 기능은 장애를 대비한 기능이라기보다는 전체 클러스터 내의 ESXi 서버들이 적절하게 리소스가 분산되어 그 밸런스를 유지하고 있는지에 대해서 초점을 맞추는 기능이다.

DRS 클러스터가 구축되면, vCenter 서버는 DRS 클러스터 내의 모든 ESXi 서버들의 현재 리소스 사용량을 모니터링하게 된다. 이때 만일 특정 ESXi 서버가 다른 ESXi 서버에 비해 리소스 사용량이 급증하거나 과도한 워크로드로 인해 상당한 부하를 안고 있을 경우, vCenter 서버는 해당 ESXi 서버에서 작동되고 있는 가상 머신들을 VMotion 기술을 이용하여 좀 더 리소스 여유가 있는 다른 ESXi 서버들 쪽으로 이동시켜서 스스로 전체 DRS 클러스터 내의 전체 리소스를 균형 있게 유지시켜 준다. 따라서 고가용성이라는 기능을 이용하고자 할 경우에는 HA 클러스터 기능을 사용하고, 리소스 밸런스를 자동화시키고 스스로 최적화시키는 기능을 이용하고자 할 경우에는 DRS 클러스터 기능을 사용한다. 또한 당연히 이 두 기능을 하나의 클러스터로 통합하여 사용할 수도 있다.

DRS 클러스터가 실제 리소스를 소비하는 가상 머신을 재배치하거나 이동시키는 경우는 크게 두 가지이다.

• 가상 머신을 Power on 할 때 - 가상 머신을 Power on 할 경우, vCenter 서버는 어느 ESXi 서버가 현재 가장 리소스 여유가 많은지 파악하여 그 ESXi 서버에서 가상 머신이 Power on 될 수 있도록 한다.

•가상 머신이 작동하는 도중 - 특정 가상 머신들의 CPU 및 메모리 사용량 증가로 인해 해당 가상 머신이 위치한 ESXi 서버의 리소스 사용량이 증가할 경우, vCenter 서버는 전체 DRS 클러스 내의 리소스 밸런스를 맞추기 위해 가상 머신을 좀 더 리소스 여유가 있는 다른 ESXi 서버로 VMotion 한다.

DPM 기능이란

<DPM>

DPM(Distributed Power Management) 기능은 별도의 클러스터 기능으로 따로 존재하는 것은 아니며 DRS 클러스터 구성시 같이 연동되어 작동되는 기술이다. DPM은 DRS 클러스터 내의 전체 리소스 사용량에 따라 ESXi 서버 자체를 Power off 하거나 Power on 함으로써 전력 비용을 절감시켜 주는 기술이다. DPM은 우선 전체 DRS 클러스터 내의 유휴 리소스 용량과 비교하여 만일 DRS 클러스터 내의 전체 리소스 용량이 매우 충분하다고 판단된다면 가상 머신들을 VMotion 실행함과 동시에 ESXi 서버들을 Stanby 모드로 전환하여 Power off 시킨다. 그렇게 함으로써 전력 비용을 절감시키고 전체 리소스 사용량을 극대화시켜 가상 머신을 통합시키게 된다. 만일 다시 가상 머신의 CPU 및 메모리 사용량이 증가하게 되고 I/O가 늘어날 경우, DPM은 스스로 ESXi 서버를 다시 Power on 시키고 VMotion을 통해 다시 가상 머신들을 적절하게 재배치시킨다. 현재 DPM이 ESXi 서버의 전원을 조정하기 위해서 크게 세 가지 프로토콜 방식을 활용하고 있다.

IPMI(Intelligent Powere Management Interface)
HP iLO(integrated Lights-Out)
WOL(Wake-On-Lan)

IPMI나 WOL의 경우 대부분의 x86 시스템에서 기본적으로 제공하는 기능이며, HP 프로라이언트 서버에 장착된 iLO 포트의 경우는 오직 HP에서만 제공하는 내부 서버 관리용 포트이다. WOL과 같은 경우 WOL을 지원하는 네트워크 카드인지 여부를 먼저 확인해야 한다. 또한 두 개 이상의 네트워크 카드가 장착되어 있을 경우, 어떤 카드가 정확하게 WOL을 지원하는지의 여부도 확인해야 하며, 보통 BIOS에서 그 설정을 바꾸거나 확인할 수 있다. ESXi 서버에서는 UDP 방식을 통해 WOL 패킷을 전달하므로 라우팅이 된다 하더라도 브로드캐스트 방식의 UDP 패킷을 스위치에서 drop 시킬 수도 있기 때문에 반드시 면밀히 테스트를 거쳐야 한다. 또한 이러한 WOL 패킷은 VMotion용 네트워크를 통해 전달되어야 하기 때문에 WOL 이 사용 가능한 네트워크 카드는 반드시 VMotion용 네트워크 전용으로 설정해야 한다.

Standby Mode : 전력 비용을 절감시키기 위해 DPM은 ESXi 서버를 Power off 한다고 말했지만, 이것을 VMware에서는 Standby 모드로 전환시킨다고 표현한다. Standby 모드로 전환된다는 의미는 정확하게 말하면 ACPI S5 모드로 전환되었음을 의미한다. S1부터 S4까지 각각의 ACPI Power state가 정해져 있지만, S5는 S4 하이버네이션 모드 다음에 해당하는 가장 최저 전력 상태를 의미하며 WOL 기능에 의해 응답하기 위한 최소한의 하드웨어 컴포넌트들만 전력을 소비하는 형태이다. WOL에 의해 서버가 다시 ACPI S5 상태에서 빠져나오기 위해서는 VMotion용 네트워크를 통해 WOL패킷을 전달받아야 한다는 사실을 잊어서는 안 된다. IPMI 또는 HP의 iLO와 같은 전용 포트를 사용할 경우에는 WOL과 상관없이 작동시킬 수 있다. 또한 ACPI S5 상태의 서버를 정상적으로 다시 Power on 시키는 것은 DRS 클러스터 내의 다른 ESXi 서버에서 하는 것이며, vCenter 서버가 Power on 시키는 것은 아니다. 따라서 DPM 기능이 작동하여 모든 서버가 전부 Power off 될 수는 없으며 최소한 단 한 대의 ESXi 서버는 작동되고 있어야 한다.

FT 작동 원리

OSMU-PIPELINE — Tue, 18 Oct 2022 03:19:22 +0900

FT(Fault Tolerance) 작동 원리

VMware FT는 HA(High Availibility) 기능이 제공할 수 있는 수준을 넘어서서 더 높은 고가용성을 요구하는 미션 크리티컬한 서비스를 작동시켜야 할 경우 FT가 바로 그 대안이 될 수 있다. FT의 작동 배경을 간단하게 소개하면 다음과 같다. 우선 가상 머신에게 FT를 설정하게 되면, 해당 가상 머신은 원본(Primary) 가상 머신으로 선정이 되고 원본 가상 머신의 디스크 파일을 같이 공유하여 바라보게 되는 복제(Secondary) 가상 머신이 생성된다. 이때 복제 가상 머신은 VMotion의 기법을 이용하여 생성되며 HA 클러스터로 구성된 ESXi 서버 내에서도 원본 가상 머신이 작동되고 있지 않는 다른 ESXi 서버 위에 생성된다. VMkernel은 원본 가상 머신에서 일어나는 모든 CPU 명령과 I/O를 저장하여 복제 가상 머신에 그대로 전달한다.

외부에서 바라볼 때는 원본 가상 머신만 존재하며 원본 가상 머신을 통해서만 I/O를 전달할 수 있다. 복제 가상 머신은 외부에 드러나지 않으며 모든 I/O 처리는 기본적으로 원본 가상 머신을 통해서만 이루어진다. 만일 원본 가상 머신이 작동되고 있는 물리적인 서버에서 장애가 발생할 경우, 복제 가상 머신은 즉각 원본 가상 머신 역할을 도맡게 되어 중단 없이 I/O 처리를 계속 진행하게 되고 새로운 복제 가상 머신이 다른 물리적인 ESXi 서버 위에서 또다시 VMotion 기술을 통해 재생성된다. 그런데 여기서 핵심은 바로 어떻게 해서 원본 가상 머신과 복제 가상 머신이 항상 동일한 내용을 공유할 수 있는가 여부이다. 물리적인 시스템에서 순간적으로 장애가 발생하였을 경우 그 장애 시점 이후부터 전혀 I/O 중단 없이 복제 가상 머신이 그 I/O를 도맡아 처리할 수 있어야 할 것이다. VMware에서는 이것을 Record/Replay라는 기법을 통해 해결하고 있다.

Record/Replay

일반적으로 컴퓨터에서 CPU가 명령을 실행하는 단계를 보통 5단계로 나누어서 설명한다 명령을 끌어오고, 디코딩하고, 실행하며, 전송하고 마지막으로 결괏값을 레지스터와 캐시 등에 저장한다. CPU가 이렇게 일련의 정해진 절차를 거쳐 규칙적으로 명령을 처리하지만 주변 장치들이 개입할 경우에는 그렇지가 않다. CPU가 어떤 명령을 실행하여 처리하고 있는 도중에 느닷없이 키보드 입력이나 마우스 이동과 같은 아주 간단한 하드웨어 인터럽트부터, 네트워크 패킷이 입력되거나 디스크 읽기, 그리고 타이머 이벤트와 같은 인터럽트들이 중간에 끼어들게 된다. 이러한 인터럽트들은 말 그대로 끼어들기이므로 CPU 입장에서는 하던 일을 멈추고 이러한 인터럽트들을 처리해 주어야 한다. 한마디로 예측 불가능한 이벤트들이다. FT에서의 핵심은 바로 이러한 예측 불가능한 인터럽트들이 원본 가상 머신에게 발생하였을 경우 어떤 방식으로 복제 가상 머신에게 전달해 줄 것인가이다. 무중단 시스템 구축의 어려움이 바로 이러한 문제점이었다. 원본 가상 머신에서 일어나는 이러한 모든 인터럽트들을 어떻게 하면 복제 가상 머신에게 그대로 다 전달해 줄 수 있을지가 바로 핵심이었던 것이었다.

Record/Replay기술은 바로 이것을 해결하기 위함이다.

우선 VMkernel은 원본 가상 머신에서 발생하는 예측 불가능한 인터럽트들(마우스 이동, 키보드 입력, 네트워크 패킷 입력 등)을 로그 버퍼에 전부 기록(Record)해둔다. VMkernel은 이 로그 버퍼를 milliseconds 단위로 매우 빠르게 저장하고 비우게(flush) 된다. 로그 버퍼를 비울 경우 FT 로그 전용 네트워크를 통해 복제 가상 머신이 작동되고 있는 다른 ESXi 서버의 로그 버퍼로 저장해 둔 로그를 전송한다. 로그를 전송받은 복제 가상 머신 측의 VMkernel은 전송된 로그를 바탕으로 그대로 복제 가상 머신에게 재현(Replay)시킨다. 즉, 복제 가상 머신에서 프로세스가 실행되고 처리되는 중간에 그 인터럽트 이벤트들을 끼워 넣어주는 식으로 재현시키는 것이다.

원본 가상 머신에서 발생한 인터럽트를 Record 한 다음 복제 가상 머신의 프로세스에 끼워 넣어 Replay 하게 되면 아무리 빠르게 재현한다 할지라도 자연의 법칙을 넘어설 수는 없으며, 원본 가상 머신과 복제 가상 머신 사이에서는 지연시간이 발생할 수밖에 없다. 이 지연 시간은 FT 전용 네트워크의 지연시간을 의미하는 것이 아니며, 원본 가상 머신과 복제 가상 머신 간의 프로세스 처리 지연시간을 의미한다. 이러한 지연 시간은 FT를 구성한 다음 원본 가상 머신에서 vLockstep Interval이라는 값으로 확인할 수 있다.

한편 원본 가상 머신에서 발생하는 로그를 전송하기 위해서 FT 전용 네트워크가 필요한다. 이 FT 전용 네트워크의 대역폭 크기는 크면 클수록 좋으며 최소 1Gbps 전용 네트워크는 필수이다.

이러한 Record/Replay 기술이 실제로 구현되기 위해서는 VMkernel 하이퍼바이저만의 S/W 기술만으로는 불가능하며 인텔과 AMD CPU의 하드웨어 기술 도움을 받아야 한다. 바로 하드웨어 CPU 가상화 기술인 Inter VT-x와 AMD-V 기능이 그것이며, FT 성능과 관련한 몇 가지 프로세서 익스텐션 값들이 추가되어야 했기 때문에 모든 인텔과 AMD CPU에서 FT 기능을 사용할 수 있는 것은 아니다. 때문에 FT를 사용할 수 있는 CPU의 종류를 잘 확인해서 구현해야 할 것이다.

장애감지 방법

그렇다면 FT는 어떻게 해서 ESXi 서버의 장애를 감지하게 되는 것일까? FT를 구성할 경우 FT 전용 네트워크를 생성해야 한다. 이때 VMotion과 같이 FT 전용 네트워크에도 IP 주소를 입력하게 된다. 이 IP 주소를 통해서 heartbeat 프레임을 던지게 되는데 만일 0.5초 안에 응답이 없을 경우 ESXi 서버에 장애가 발생한 것으로 간주하며, 만일 원본 가상 머신 측의 ESXi 서버라면 복제 가상 머신이 즉각 원본 가상 머신을 도맡게 된다. 반대로 복제 가상 머신 측의 ESXi 서버에 장애가 발생한 것이라면 HA 클러스터 내의 다른 ESXi 서버 위에 새로운 복제 가상 머신을 생성한다.

하드웨어에 실제 장애가 발생하여서 heartbeat 통신 유무를 판별하기 위해서 VMware는 rename 방식을 통해 판별한다.

Heartbeat 프레임에 응답이 없을 경우 ESXi 서버는 특정된 공통 파일에 대하여 이름 변경(rename)을 시도하게 된다. 하드웨어에 장애가 발생하였다면 파일에 접근이 불가능하고 이름 변경도 안 되는 점을 이용하는 것이다. 파일 이름 변경이 가능한 ESXi 서버 위에서 작동되는 가상 머신이 복제 가상 머신일 경우 FT는 즉각적으로 복제 가상 머신을 원본 가상 머신으로 대체한다.

HA 개요 및 작동 원리

OSMU-PIPELINE — Fri, 14 Oct 2022 23:57:45 +0900

HA(High Availability) 작동 원리

VMware vSphere에서는 클러스터 기능을 크게 두 가지로 나누어서 부른다 - HA 클러스터와 DRS 클러스터가 있다. 보통 이 두 개의 기능을 한데 묶어 사용하기도 하지만 제각기 따로 사용할 수도 있다. HA 클러스터 그룹을 생성한 다음 ESX 서버를 추가하게 되면 vCenter 서버에서는 ESXi 서버에 HA Agent를 설치하게 되고, 이 HA Agent는 ESXi 서버의 AAM 소프트웨어를 대신하는 중간 계층 역할을 담당한다. HA 클러스터가 일단 구성되면 클러스터 그룹 내의 ESXi 서버들은 HA Agent를 통해 서로를 인식하게 되며, vCenter의 도움이 전혀 필요 없다. 최초 HA 클러스터를 구성하고자 할 경우에만 vCenter 서버가 반드시 필요하다. 일단 HA 클러스터가 구성되고 나면 vCenter 서버에 자애가 발생하였다 할지라도 클러스터 서비스 자체는 정상 작동된다.

HA 클러스터 내의 ESXi 서버들은 서로의 상태를 확인하기 위해 네트워크를 통해 heartbeat 패킷을 서로 주고받는다. 클러스터 내의 다른 ESXi 서버로부터 15초 내에 heartbeat 응답이 없을 경우 장애 상태로 간주하고, 장애가 발생한 ESXi 서버에서 작동 중인 가상 머신을 클러스터 내의 다른 ESXi 호스트들이 가로채어 재시작하게 된다. 여기서 중요한 것은 가로챈다라는 의미이다. 클러스터 내의 다른 ESXi 서버들이 하드웨어적인 장애가 발생하여 작동을 멈춘 ESXi 서버에서 작동 중인 가상 머신의 디스크 파일과 구성 파일을 정상적으로 열어 본다는 뜻이다. 즉, VMFS 또는 NFS 데이터스토어 볼륨은 복수의 ESXi 서버들이 동시에 읽고 쓸 수 있지만, 가상 머신의 구성 파일과 디스크 파일은 오직 하나의 ESXi 서버에서만 열어 볼 수 있다. 가상 머신은 오직 한 대의 ESXi 서버 위에서만 power on이 되며, 한 번 power on이 되면 해당 가상 머신의 구성 파일과 디스크 파일은 해당 ESXi 서버에 의해 락이 걸리게 되고 다른 ESXi 서버들은 열어 볼 수가 없다. 하지만 ESXi 서버에 장애가 발생하여 정상 작동하지 않을 경우 그 위에서 작동 중인 가상 머신의 구성 파일들은 락이 풀린 채 release 되어버린 상태이므로, 다른 ESXi 서버에서 자연스럽게 해당 가상 머신의 구성 파일과 디스크 파일을 열어서 power on 하게 된다.

Primary 노드와 Secondary 노드

HA 클러스터의 구성원 간에는 크게 두 가지 역할을 하는 노드가 존재한다 - Primary 노드와 Secondary 노드가 있다. 우선 HA 클러스터는 ESXi 서버들을 멤버로서 추가할 수 있는데 Primary 노드는 HA 클러스터 구성 시 최초 5대의 ESXi 서버가 그 역할을 도맡게 되며 그 이후에 추가되는 ESXi 서버들은 모두 Secondary 노드 역할을 맡게 된다. HA 클러스터를 생성한 다음 해당 클러스터에 ESXi 서버를 추가하게 되면 추가하는 첫 번째 순서대로 Primary 노드로 자동 지정된다. 이때 클러스터에 추가될 경우 ESXi 서버에는 HA agent 구성 파일들이 전송되어 자동으로 구성된다. Primary 노드들은 서로 HA 클러스터의 모든 구성 값 및 현재 상태들을 모두 공유하게 된다. 만일 Primary 노드 5대가 모두 다 장애가 발생하여 죽는다면, 나머지 Secondary 노드의 존재 유무와 상관없이 HA 클러스터 기능은 작동하지 않는다. 따라서 HA 클러스터 디자인을 할 경우, 하나의 클러스터에 5개 이상의 ESXi 서버를 추가하게 된다면 Primary 노드가 전원 등의 장애로 인해 동시에 장애를 겪을 수 있는 동일 랙이나 인클로저에 몰려 있지 않도록 분산시켜야 할 필요가 있다.

초기 HA 클러스터 구성 시 vCenter 서버가 필요하지만, 그 이후 vCenter 서버에 장애가 발생하여 작동하지 않더라도 HA 클러스터 본연의 기능은 정상 작동한다고 이미 언급하였다. 원래 ESXi 서버의 장애 발생 시 HA 클러스터 내의 다른 ESXi 서버들의 리소스 배분을 고려하여 계산을 도맡는 역할을 바로 vCenter 서버가 하고 있으나, 만일 vCenter 서버가 정상 작동하지 않는 경우라면, Primary 노드가 가지고 있는 최근의 리소스 사용률에 근거하여 적당하게 가상 머신을 분배할 뿐이다.

각 노드들은 heartbeat를 전달한다고 설명했지만, 정확하게 말하면 Primary 노드들은 Primary 노드끼리만 heartbeat 프레임을 전달하며 Secondary 노드들은 오직 Primary 노드들에게만 heartbeat 프레임을 전달하고 서로에게는 전달하지 않는다. 이 heartbeat 프레임은 기본적으로 1초에 한 번씩 보내게 된다.

정리하자면, VMware HA는 ESXi 서버가 하드웨어적인 장애가 발생하더라도 그 위에서 작동 중인 가상 머신을 HA 클러스터 내의 다른 ESXi 서버로 Failover 시켜주는 서비스이다. VMotion과 달리, VMware HA는 관리자가 사전에 개입할 수 없는 하드웨어 장애를 대비하기 위해 존재하는 서비스이므로 가상 머신의 downtime을 최소한으로 줄여주기 위함에 초점을 맞추고 있다.

그러나 분명 가상화 데이터센터 환경에서는 미션 크리티컬한 서비스가 가상 머신 위에서 제대로 작동이 되어야만 하며, downtime 자체가 없는 고가용성 가상화 환경을 만들 필요가 있다. 그로 인해 VMware에서는 downtime자체가 없는 FT(Fault Tolerance) 기능을 제공하고 있으며, 데이터센터 운영 환경에 따라 상호 보완적으로 운영을 고려해 볼 필요가 있다.

Storage VMotion 작동 원리

OSMU-PIPELINE — Thu, 13 Oct 2022 06:03:57 +0900

Storage VMotion

VMotion이 가상 머신을 Shutdown 하거나 Power off 하지 않은 채 다른 ESXi 서버로 이동시키는 기술이라면, Storage VMtion은 VMotion과 마찬가지로 가상 머신을 Shutdown 하지 않은 채 가상 머신의 디스크 파일을 다른 데이터스토어로 이동시키는 기술을 의미한다.

Storage VMotion이 활용될 수 있는 사례는 다음과 같다.

• 노후화된 스토리지를 교체해야 할 경우 - 구 기종의 스토리지 위에서 가상 머신을 운영하다가 새로운 기종의 스토리지를 도입하여 가상 머신 디스크 파일을 이동해야 할 경우, 가상 머신의 서비스는 온라인 그대로 운영하면서 가상 머신의 디스크 파일을 이동시킬 수 있다.

• 이기종 프로토콜 스토리지 간의 이동이 필요할 경우 - 광채널 스토리지 시스템에서 iSCSI 스토리지 또는 NFS 스토리지 등으로(또는 그 반대로도) 이동이 필요할 경우에도 가상 머신을 Shutdown 할 필요 없이 온라인 중에 가능하다.

• 디스크 성능과 관련한 병목 현상을 해결하고자 할 경우 - VMFS 또는 NFS 데이터스토어에 과도한 가상 머신 디스크 파일이 통합되어 운영될 경우, 별도의 데이터스토어를 새롭게 추가하여 가상 머신 디스크 파일을 이동시켜서 부하를 분산시키고자 할 경우에도 사용 가능하다.

그렇다면 Storage VMotion이 작동되는 실제 원리에 대해 알아보면 다음과 같다. 우선 DS01이라는 데이터스토어에 VM01이라는 가상 머신 디스크 파일이 존재한다고 가정해 보자. 여기에 DS02라는 새로운 데이터스토어를 생성하였고 DS01에서 DS02로 가상 머신 디스크 파일을 이동시킨다고 가정한다.

먼저 VM01의 가상 머신 구성 파일을 DS02 데이터스토어로 먼저 복사한다. VM01의 가상 머신 구성 파일들은 VMX 파일이나 각종 로그 파일 등이 해당되며, 이러한 파일들은 가상 머신의 실제 디스크 파일들이 아니므로 쉽게 복사가 가능하다.
가상 머신 디스크 구성 파일 복사가 완료되면 DS01 데이터스토어 위치한 가상 머신 디스크 파일을 DS02 데이터스토어로 복사해야 한다. 실제로 이 작업이 바로 Storage VMotion에서 핵심이다. 가상 머신 디스크 파일이 계속해서 열려 있는 상태, 즉 데이터의 변동이 가해지는 상태에서 복사가 이루어져야 한다. 읽기만 한다면 문제가 없지만 쓰기와 같은 작업이 이루어질 경우 그러한 변동된 값에 대한 보정이 별도로 이루어져야 한다는 것이다. 데이터 파일에 무언가 변동이 가해졌다는 것을 알아차리기 위해서는 크게 파일 레벨에서 구현하는 방법과 디스크 블록 레벨에서 구현하는 방법이 존재한다. 파일 레벨에서 구현하는 방법은 게스트 운영체제 내부에 별도의 에이전트를 설치하여 통신을 해야 하거나 또는 아예 가상 머신 디스크 파일을 마운트 하여 일일이 열어 보아야 하는 문제점이 존재한다. 반면에, 디스크 블록 레벨에서 구현하는 방법은 디스크 블록을 매번 전부 읽어 들여야 하기 때문에 스토리지 자체에 커다란 부하를 줄 수 있는 단점이 존재한다. VMware에서는 결국 블록 레벨에서 구현하는 방법을 선택하였는데, 스토리지에 가해지는 부하를 최소화하기 위해 CBT라는 기능을 사용한다. CBT는 Change Block Tracking의 약자로서, 말 그대로 블록에 무언가 변경이 가해졌는지 아닌지의 여부를 추적하는 기법이다. 특정 시점 이후에 블록에 변동이 가해졌는지 아닌지를 추적할 수 있도록 일종의 로그 파일을 이용한다. 그렇게 함으로써 변동된 값이 있는지 그 여부를 파악하기 위해 디스크 블록 전체를 전부 스캔할 필요 없이 CBT 값을 이용하여 변동된 블록의 위치를 쉽게 알아차릴 수 있게 되었다.
다시 설명하자면 가상 머신 구성 파일 복사가 완료되면 가상 머신 디스크 파일에 대하여 자동으로 CBT 기능을 설정한다. 그다음, 우선 가상 머신 디스크 파일을 pre-copy 하여 DS02 데이터스토어에 복사를 시작한다.
가상 머신 디스크 파일의 pre-copy 작업이 완료된 다음 복사가 진행되는 동안 혹시 변경된 블록이 있었는지 여부를 CBT 기능을 통해 파악한다. 변경된 블록이 존재한다면 해당 블록까지 복사를 진행한다.
그런 다음, 복사가 완료된 순간 가상 머신은 재빠르게 Suspend 상태로 빠진다. 그리고 새롭게 옮겨진 DS02 데이터스토어의 가상 머신 디스크 파일 위치로 경로가 변경된 다음, 다시 가상 머신은 Suspend 상태에서 빠져나오면서 아무 일도 없었다는 듯 서비스가 재개된다.

Storage VMotion을 실제로 구현하기 위해서는 반드시 먼저 VMotion의 준비사항이 마련되어야 하는 것은 아니다. Storage VMotion이 가상 머신을 실시간으로 다른 ESXi 서버로 이동시키는 것이 아니라 데이터스토어의 위치를 바꾸는 것이기 때문이다. Storage VMotion을 실행하기 위해서 별도의 실행 메뉴가 존재하는 것은 아니며, VMotion과 마찬가지로 가상 머신을 선택한 후 Migrate 메뉴를 클릭하면 작업이 시작된다.

VMotion이나 Storage VMotion이 가지고 있는 최대 장점은 뭐니 뭐니 해도 가상 머신을 Shutdown 할 필요 없이 이동시키거나 가상 머신 디스크 파일을 다른 데이터스토어 쪽으로 이동시킬 수 있다는 점이다. 가상화 환경의 장점 중 하나가 바로 이렇게 가상 머신이 하드웨어 시스템과 독립적으로 분리되고 또한 파일화되어 있기 때문에 물리적 시스템 환경에서라면 구현 불가능한 것들이 이러한 기능들로 인해 가능해질 수 있다는 점이다. 또한 점진적으로 이러한 기능들로 인해 가상 머신에 좀 더 미션 크리티컬한 서비스가 올라가고 있으며, DRS, DPM 기능과 같이 사용함으로써 얻는 시너지 효과는 엄청나다고 볼 수 있다.

VMotion 작동 원리

OSMU-PIPELINE — Wed, 12 Oct 2022 10:16:42 +0900

VMotion

운영 중인 가상 머신이 power off 되거나 중지되지 않은 채 그대로 다른 물리적 서버로 이동하기 위해서 해결해야 할 과제는 크게 세 가지이다.

첫 번째는 가상 머신의 게스트 운영체제가 가지고 있는 메모리 값과 CPU 상태를 어떻게 다른 물리적인 서버의 VMkernel로 이동시킬 것인지에 관해서이다. 우선 원본 ESXi 서버 위에서 작동 중인 가상 머신에게 VMotion 명령이 떨어지게 되면 가상 머신의 메모리 페이지 값들이 대상 ESXi 서버 쪽으로 네트워크를 통해 먼저 복사가 이루어진다. 복사가 이루어지는 동안에도 계속하여 가상 머신 내의 게스트 운영체제는 I/O를 처리하고 있기 때문에 메모리 페이지 값은 항상 변경될 수 있다. 원본 ESXi 서버는 이렇게 변경되는 메모리 페이지 값을 저장하기 위해 최초 메모리 페이지 값 복사가 시작되는 순간부터 별도의 저장 위치를 만들어 두는데, 이것을 메모리 비트맵이라 부른다. 메모리 비트맵에는 1차적으로 가상 머신의 메모리 페이지 값이 대상 ESXi 서버로 복사가 된 이후부터 변경된 모든 메모리 페이지 값이 저장된다.

원본 ESXi 서버가 1차적으로 가상 머신의 모든 메모리 값을 대상 ESXi 서버 쪽으로 복사해 둔 다음 최종적으로 변경된 메모리 값이 저장된 메모리 비트맵 값을 대상 ESXi 서버 쪽으로 복사를 해야 한다. 하지만 그 순간에도 역시 계속하여 원본 ESXi 서버의 가상 머신에서는 서비스를 진행하고 있기 때문에 메모리 페이지 값이 변경될 수 밖에 없다.

그렇다고 해서 무한정 메모리 비트맵에 저장만 하고 있을 수는 없기 때문에 최종적으로 메모리 비트맵을 대상 ESXi 서버로 복사하는 순간 가상 머신은 멈추게 된다. 그러나 크게 걱정하지 않아도 된다. 최초 전체 메모리 값을 복사는 시간이 조금 소요될 뿐, 변경된 메모리 비트맵 값이 복사되기 위해서 걸리는 시간은 매우 짧으며 보통 2초를 넘기지 않는다.

메모리 이전과 아울러 CPU 실행 상태의 이전 역시 많은 주의가 필요하다. 우선 기본적으로 인텔 CPU는 인텔 CPU 끼리, AMD CPU는 AMD CPU 끼리만 서로 이동이 가능하다. 인텔과 AMD CPU와의 상호 VMotion 이동은 불가능하다. 이는 각각의 CPU 제조사에서 구현한 명령어 체계(Instruction set)가 조금씩 틀리기 때문이다. 또한 같은 제조사의 CPU라 할지라도 호환 가능한 CPU세대가 정해져 있으므로 VMware 홈페이지에서 해당 CPU 호환성을 파악하는 것이 중요할 것이다.

VMotion이 작동되기 위해 해결되어야 할 두 번째 숙제는 바로 가상 머신의 게스트 운영체제가 담겨 있는 VMDK 파일에 대한 접근 문제이다. 대용량의 VMDK 파일을 메모리 페이지 값 복사와 같이 네트워크를 통해 복사를 할 수는 없기 때문에, 반드시 가상 머신의 VMDK 파일은 원본 ESXi 서버와 대상 ESXi 서버가 서로 접근할 수 있는 공유 스토리지 볼륨에 위치하고 있어야 한다. 바로 VMFS 데이터스토어 또는 NFS 데이터 스토어가 그것이다. VMotion을 해야 하는 가상 머신들의 VMDK 파일은 다른 ESXi 서버들이 접근할 수 없는 로컬 SCSI 기반의 VMFS 데이터스토어에 저장되어서는 안 된다. VMFS 데이터스토어의 경우 클러스터 파일 시스템 구조를 가지고 있기 때문에 다수의 ESXi 서버가 동시에 접근할 수 있지만, 그 위에 존재하는 VMDK 파일은 오직 하나의 ESXi 서버만 열 수가 있다. 그렇기 때문에 VMotion이 실행되면 해당 가상 머신의 VMDK 파일에 대한 소유권 및 접근 권한이 원본 ESXi 서버에서 대상 ESXi 서버로 변경이 이루어진다. NFS 데이터스토어 역시 파일 수준의 공유 서비스를 지원하기 때문에 다수의 ESXi 서버들이 동시에 접근이 가능하지만, 별도의 lock 파일을 통해 VMDK 파일이 단 하나의 ESXi 서버에서만 열릴 수 있다.

세 번째 숙제는 바로 가상 머신의 네트워크 정보이다. 가상 머신이 대상 ESXi 서버로 VMotion 되어 이동하더라도 가상 머신의 MAC 주소 값은 어차피 가상으로 생성된 주소이므로 변경되지는 않는다. 그러나 가상 머신의 위치가 변경된 것은 상위의 물리적 스위치가 알 수 없기 때문에, VMotion이 완료되면 ESXi 서버는 가상 머신의 MAC 주소 값과 포트 위치 값을 새로 갱신하기 위해 RARP 요청을 자동으로 날린다.

VMotion이 진행되는 전체 과정을 순서대로 살펴보면 다음과 같다.

우선 두 대의 ESXi 서버가 존재하며 ESX01번 위에서 한대의 가상 머신이 작동되고 있다고 가정하자. 각각의 ESXi 서버에는 VMkernel용 포트 그룹을 지닌 가상 스위치와 가상 머신용 포트 그룹을 지닌 가상 스위치가 준비되어 있으며, 각 가상 스위치는 상단의 물리적 스위치와 같이 연결되어 있다. 한편 공유 스토리지 위에 가상 머신의 가상 디스크 파일이 존재하고 있으며, 두 대의 ESXi 서버가 공유 스토리지의 볼륨을 같이 바라보고 있다.
VMotion이 시작되면 ESXi01에서 작동 중인 가상 머신의 메모리 페이지 값을 ESXi02로 복사하기 시작한다. 이때 VMotion 네트워크를 통해 복사가 이루어진다. 이와 동시에 메모리 비트맵 값이 생성되는데, 가상 머신은 계속해서 운영되고 있기 때문에 메모리 페이지 값이 복사되는 와중에도 언제든지 메모리 페이지 값이 변경될 수 있다. 이때 변경되는 메모리 페이지 값들은 메모리 비트맵에 저장된다.
가상 머신의 메모리 페이지 값이 전부 복사가 완료되었다면 ESXi01에서 작동 중인 가상 머신은 잠시 멈추게 된다. 바로 메모리 비트맵 값을 최종적으로 ESXi02쪽으로 복사하기 위해서 이다. 이때의 시간은 전체 메모리 페이지 값을 복사하는 시간보다는 훨씬 짧으며 대략 2초 안에 복사가 완료된다. 한편 ESXi01에서 가상 머신이 멈추면서 ESXi02에서 가상 머신 시작 준비를 한다. 가상 머신이 작동하는데 필요한 모든 구성 파일과 가상 디스크 파일은 공유 스토리지에 존재하므로, ESXi01에서는 해당 가상 머신의 구성 파일과 가상 디스크 파일에 대한 소유권을 버리게 되고(Release) 대상 서버인 ESXi02에서 파일을 열게 된다.
이제 마지막으로 가상 머신의 MAC 주소 값과 물리적인 스위치 포트 매핑이 변경되었다는 RARP 요청이 뿌려지고, 물리적인 스위치들은 포워딩 테이블 값을 업데이트하게 된다. 이와 함께 최종적으로 가상 머신은 ESXi02에서 시작되면서 VMotion은 마무리된다.

가상 머신 스냅샷

OSMU-PIPELINE — Tue, 11 Oct 2022 11:13:28 +0900

스냅샷

스냅샷이란 운영 중인 가상 머신의 상태를 그대로 보전해 주어 언제든지 원할 때 이전 상태로 돌아가게끔 해주는 기능이다. 가상 머신이 모두 파일로 존재하기 때문에 가상 디스크 및 구성 파일들을 전부 순간 복사하는 것이라고 이해하면 좋다. 실제 물리적인 서버에 Windows 운영체제를 설치하여 사용 중인 환경에서 중요한 핫픽스 프로그램을 설치하기 전 혹시나 발생할 수 있는 문제를 미연에 방지하고자 하드웨어 어레이 컨트롤러에 의해 미러가(RAID 1)되어 있는 디스크 한 개를 온라인상에서 제거한 다음 핫픽스 패치를 적용하고, 시스템 재시작 후 다시 디스크를 리빌딩하는 식의 위험천만한 방법을 사용하고 있는 경우가 많다. 스냅샷은 바로 이러한 운영 상의 문제점을 해결할 수 있는 대안이다.

운영 중인 시스템에 새로운 핫픽스 프로그램을 설치하거나 신규 서비스나 애플리케이션 테스트를 해야 할 경우 또는 시스템 업그레이드나 패치 작업을 해야 할 경우 스냅샷을 이용하면 언제든지 그 이전의 상태로 되돌아갈 수 있다.

가상 머신에 대하여 스냅샷을 적용하는 순간 가상 머신을 구성하고 있는 모든 파일 및 데이터가 보존되는데, 스냅샷 적용 이전으로 언제든지 돌아가야 하기 때문에 가상 머신이 작동되는 순간의 모든 데이터와 메모리 값이 그대로 보존되어야 한다. 스냅샷을 적용할 경우 새로 생성되는 파일은 다음과 같다.

<스냅샷>

• <가상 머신명>-delta.vmdk - 스냅샷을 생성하게 되면, 가상 머신의 VMDK 가상 디스크 파일은 읽기 전용(Read-only) 속성으로 바뀌게 되며, 이후 가상 머신에게 전달되는 모든 I/O는 delta.vmdk 파일, 즉 델타 디스크에 업데이트 된다. 델타 디스크 파일은 최초 16MB의 크기로 시작되며, 원본 가상 디스크의 블록에 변경이 가해질 경우 실제 업데이트는 델타 디스크 파일에 가해진다. 이때의 변경은 단순히 파일이 생성되는 것만이 아니며, 삭제와 이동과 같이 디스크의 블록 자체가 변경되는 모든 작업이 해당된다. VMFS의 특성상 파일 크기가 변경되면 메타데이터가 업데이트되어야 한다. 이때 과도한 SCSI reservation을 막기 위해 약 16MB 크기로 매번 증가한다. 그러나 델타 디스크가 계속 커져서 원본 가상 디스크보다 더 커지는 일은 발생할 수 없다. 왜냐하면 어디까지나 델타 디스크 파일은 원본 가상 디스크 파일에 변경된 블록 데이터 값을 가지고 있을 뿐이다. 원본 가상 디스크의 모든 데이터가 변경되거나 삭제되었다고 하더라도 이론상 그 크기가 같아질 수는 있겠지만 원본의 크기를 넘어설 수는 없다.

• <가상 머신명>.vmsd - 스냅샷에 대한 각종 메타데이터 정보를 담아두는 구성 파일이다. 최초 0바이트 크기로 시작되지만 스냅샷을 적용하게 되면 이후 스냡샷명, UID 값, 디스크 파일명 등의 정보를 텍스트 기반으로 업데이트 하게 된다. 일종의 스냅샷 히스토리 내역을 관리하는 파일이며, 스냅샷을 지우더라도 vmsd 파일은 남아 있게 된다.

• <가상 머신명>.vmsn - 스냅샷 작동 당시의 가상 머신 상태 정보 및 메모리 값을 담아두는 파일이다.

SQL이나 Exchange 서버 서비스와 같이 매우 빈번하게 데이터가 업데이트되는 경우, 델타 디스크 크기는 급격하게 증가될 것이지만, 웹 서버 서비스나 애플리케이션 서비스용 서버 같은 경우에는 그 증가율이 크지 않다. 그렇기 때문에 가상 머신이 어떤 서비스의 성격이냐에 따라 최초 VMFS 볼륨 크기를 적절하게 설정해야 한다. 보통 스냅샷을 위한 공간으로서 가상 디스크 크기 대비 평균 약 20% 이상의 여유 공간을 확보하는 편이다.

스냅샷 생성 시 두 가지 옵션을 발견할 수 있는데, 첫 번째는 Snapshot the virtual machine's memory이며, 두 번째는 Quiesce guest file system이다.

우선 두 번째 옵션을 먼저 설명하면, Quiesce guest file system의 경우 VMware Tools 설치 시에 포함된 SYNC 드라이버 또는 VSS 드라이버를 이용하는 방식이다. 먼저 SYNC 드라이버를 사용하게 되면, 스냅샷이 작동되는 순간 게스트 운영체제의 파일 시스템에 어떠한 데이터 업데이트도 되지 않도록 I/O를 막아주고, 캐시 등의 메모리에 잔존해 있는 데이터를 정상적으로 디스크에 업데이트 하게 된다. 이렇게 함으로써 스냅샷이 작동되어 완료되는 그 순간까지의 I/O 업데이트가 이루어지지 않기 때문에 그 이전과 이후의 상태가 서로 동일해지는 무결성 상태를 유지하게 된다.

그러나 이 옵션으로는 완벽하지가 않다.

첫 번째 옵션인 Snapshot the virtual machine's memory는 가장 정밀하고 깨끗하게 스냅샷을 생성하고자 할 경우 선택하는 옵션이다. 가상 머신의 메모리 내용을 보존하지 않은 채 스냅샷을 생성한 다음 다시 이전 상태로 되돌릴 경우, 게스트 운영체제는 마치 순간 하드웨어 장애가 발생한 다음 재시작된 것으로 착가하게 된다. 왜냐하면 아직 채 디스크에 업데이트하지 못하고 메모리에 잔류하고 있던 각종 데이터들이 생성된 스냅샷 이전으로 복구되면, 갑자기 필름이 끊긴 듯 머릿속이 텅 비어 버렸기 때문이다. 바로 이러한 경우를 대비하고자 Snapshot the virtual machine's memory 옵션이 존재한다. 이 옵션을 선택할 경우 스냅샷이 작동되는 그 시점에 가상 머신의 모든 메모리 값들마저 전부 보존된다. 이때 가상 머신에게 할당된 메모리 크기만큼 <가상 머신명>.vmsn 파일이 생성된다. 그렇기 때문에 이 옵션을 선택할 경우 그렇지 않았을 경우보다 스냅샷 파일 생성시간이 좀 더 소요된다.

가상 머신의 구조

OSMU-PIPELINE — Mon, 10 Oct 2022 01:39:16 +0900

가상 머신의 구성 파일

<가상머신 구성 파일>

VMware ESXi 서버 운영체제 입장에서의 가상 머신이란 일종의 파일 집합체이다. 시스템이 부팅하기 위해 필요한 BIOS 정보도 파일로 존재하며 몇 개의 CPU를 장착하고 있는지, 메모리 크기는 어느 정도인지, 하드 디스크 종류와 크기가 어느 정도인지 등 하드웨어 구성과 관련한 내용들이 전부 파일로 존재한다. 가상 머신을 구성하는 대표적인 파일들의 종류는 다음의 표와 같다.

파일 종류	설명
<가상머신명>.vmx	가상 머신의 구성 파일
<가상머신명>.vmdk	가상 디스크의 종류 및 형태를 정의하는 descriptor 파일
<가상머신명>-flat.vmdk	실제 데이터가 담겨져 있는 가상 디스크 파일
<가상머신명>.nvram	가상 머신의 BIOS 파일
vmware.log	가상 머신의 로그 파일
vmware-#.log	가상 머신의 예전 로그 파일(로테이션)
<가상머신명>.vswp	가상 머신의 스왑파일
<가상머신명>.vmsd	가상 머신의 스냅샷 정의 파일

VMX 파일은 가상 머신의 핵심 구성 파일로서 어떤 하드웨어로 구성되어 있는지에 관하여 종합적인 정보를 담고 있다.

vmdk 파일은 크게 두 가지로 나뉘는데, 첫 번째는 <가상 머신명>.vmdk 이고 두 번째는 <가상 머신명>-flat.vmdk 파일이다.

flat이 붙지 않은 <가상 머신명>.vmdk 파일은 일종의 descriptor 파일이며, 가상 머신 디스크 파일이 어떤 크기와 형태로 갖춰져 있는지 나타내는 구성 파일이다. 반면에, <가상 머신명>-flat.vmdk 파일은 실제 가상 머신 디스크의 데이터가 담긴 파일이다. descriptor 파일은 삭제가 되더라도 언제든지 재생성할 수 있는 방법이 있지만 flat 파일은 절대 삭제되어서는 안 된다. 만일 백업이 되지 않은 상태에서 삭제되었다면 되살릴 수 있는 방법은 없다. 만일 두 번째 가상 디스크를 생성하였다면 <가상 머신명>_#.vmdk와 같은 파일명으로 존재한다. 예를 들어, vm01이라는 가상 머신이 존재한다면 천 번째 가상 디스크 파일명은 vm01.vmdk와 vm01-flat.vmdk이다. 이때 두 번째 가상 디스크가 생성되었다면 그 이름은 vm01_1.vmdk와 vm01_1-flat.vmdk가 된다.

바이오스 파일이나 로그 파일 등은 사실 삭제가 되어도 가상 머신 재시작 시 자동적으로 재생성된다. vswp 파일이 가상 머신의 스왑 파일이라고 해서 이 스왑 파일을 가상 머신 내의 게스트 운영체제의 스왑 메모리 영역이라고 오해할 수 있으나, 사실 전혀 그렇지 않다. 이미 게스트 운영체제의 스왑 메모리 - 이를 테면 Windows의 pagefile.sys 파일이나 Linux의 스왑 파티션 영역-는 <가상 머신명>-flat.vmdk 안에 포함되어 있으며, vswp 파일은 하이퍼바이저 스와핑을 위해 생성되는 파일이다. vswp 파일은 기본적으로 가상 머신 생성 시에 할당한 메모리 크기만큼 동일한 크기의 파일로, 가상 머신 시작 시에 생성된다. 예를 들어, 16GB 크기의 메모리를 가진 vm01이라는 가상 머신을 생성하였다면 16GB 크기의 vm01.vswp 파일이 가상 머신 시작 시에 자동적으로 생성된다. vmsd 파일은 가상 머신의 스냅샷과 관련한 정보를 담고 있는 파일이다. 스냅샷과 관련한 것은 다음에 자세히 다루도록 하겠다.

모든 파일명은 최초 가상 머신을 생성하면서 부여한 이름으로 명명되므로 공백이나 특수문자 등이 입력되지 않도록 주의를 기울여야 한다. 물론 이후에 가상 머신명을 바꿀 수는 있지만, 그것은 어디까지나 vSphere Client에서 바라보는 인벤토리명만 바뀔 뿐 실제 위와 같은 가상 머신의 구성 파일명 등은 바뀌지 않기 때문에 최초 입력 시에 주의를 요한다. 이러한 파일들은 각각의 가상 머신별로 따로 존재하며, VMFS 데이터스토어 또는 NFS 데이터스토어 위에 가상 머신별 이름과 동일한 폴더 아래에 위치한다. 해당 데이터스토어에서 마우스 우측 버튼으로 Browse Datastore를 선택하게 되면 가상 머신별 이름과 동일한 폴더를 찾을 수 있으며, 각 폴더 안에서 가상 머신 구성 파일들을 찾을 수 있다.

vCenter 서버 구조

OSMU-PIPELINE — Sun, 9 Oct 2022 09:08:19 +0900

핵심 서비스

vCenter 서버는 다음과 같은 핵심 서비스(Core Service)를 제공하고 있다.

• 가상 머신 배포 - 단일 ESXi 서버에서도 가상 머신을 생성할 수 있지만, 오직 vCenter 서버를 통해서 사용자들은 다양한 환경과 요구사항에 부합하는 템플릿을 제작할 수 있으며, 이러한 템플릿을 바탕으로 손쉽고 매우 빠르게 가상 머신을 생성, 배포할 수 있다.

• ESXi 호스트 및 가상 머신 구성 - vCenter 서버에 접속하여 복수의 ESXi 호스트와 가상 머신들의 구성 정보들을 단일 콘솔 화면만으로 손쉽게 살펴보고 수정할 수 있다.

• 가상 머신 및 리소스 인벤토리 관리 - 데이터센터 내의 리소스들을 구별하기 쉽게 객체화하여 관리자에게 정확하고 간편한 인벤토리 관리 기능을 제공한다.

• 성능 데이터 및 로그 제공 - ESXi 호스트, 가상 머신, 클러스터 리소스 등 데이터센터 내의 모든 객체 단위별 성능 데이터를 제공하며, 각 리소스와 관련한 로그들을 한눈에 살펴볼 수 있다.

• 알람 및 이벤트 관리 - 데이터센터 내의 여러 개체에 대하여 알람을 설정한 다음, 설정해 놓은 조건에 부합할 경우 SNMP 트랩 메시지를 전달하거나 이메일을 전송하기도 하고, 또는 스크립트를 실행하는 등 다양한 방법으로 이벤트들을 관리할 수 있다.

• 작업 스케줄링 관리 - 원하는 시간에 가상 머신을 VMotion 하거나 또는 스냅샷을 작동시키는 등 다양하게 미리 설정된 여러 작업들을 스케줄링하여 자동화시킬 수 있다.

분산서비스

분산 서비스는 다수의 ESXi 서버들을 관리하면서 vCenter 서버의 기능을 확장해 주는 서비스이며, 분산 서비스의 대표적인 기능이 바로 DRS, DPM, FT, HA, VMotion과 같은 기능이다. 이러한 기능들은 전부 vCenter 서버와 함께 연계되어 작동되므로 vCenter 서버 없이는 기능 구현이 되지 않는다.

액티브 디렉토리 통합 인터페이스

한 두대의 ESXi 서버만 존재하는 환경이라면 각 ESXi 서버별 사용자 관리는 그다지 문제가 되지 않는다. 하지만 다수의 ESXi 서버가 통합 관리되어야 하는 경우라면 사용자 인증 및 관리 시스템이 중요해질 수 밖에 없다. vCenter 서버는 이러한 문제를 해결하기 위해 Windows 사용자 인증 시스템을 도입하였다. vCenter 서버는 Windows 운영체제에 설치하게 되므로 자연스럽게 Windowd의 SAM(Security Account Manager) 데이터베이스의 사용자 계정과 그룹명을 이용하여 각 ESXi 서버에 적절한 권한을 가지고 접근할 수 있게 되었다.

사용자 권한 설정 서비스

위의 액티브 디렉토리 통합 인터페이스와 연계할 수 있는 사용자 권한 설정 서비스는 각 개별 사용자들이 데이터센터, 호스트, 가상머신, 네트워크, 스토리지 등의 각 개체들에 대하여 어느 정도의 권한을 가지고 접근할 수 있는지 세밀하게 설정할 수 있다. 물론 사전에 적절한 권한을 가진 그룹들도 존재하지만, 이와 달리 별도로 새로운 사용자 또는 그룹을 생성하여 권한을 세밀하게 설정할 수도 있다.

vSphere API

또한 vCenter 서버에는 플러그인(Plugin) 기능이 포함되어 있다. 이 플러그인은 말 그대로 기타 부수적인 기능을 갖춘 프로그램들이며, vCenter 서버 프로그램 위에서 작동된다. 이러한 플러그인들은 이후에 언제든지 vCenter 서버 위에 추가하거나 삭제할 수가 있다. 대표적인 플러그인 기능이 바로 VMware Update Manager와 같은 것들이 있다.

vSphere Web Access

vSphere Web Access는 웹 접속이 가능한 곳이라면 언제든지 웹 브라우저를 통해 접속하여 관리할 수 있는 인터페이스를 제공한다. Web Access는 크게 가상 머신의 관리에 초점이 맞추어져 있으며, Web Access로 할 수 있는 대표적인 작업들은 다음과 같다.

• 가상 머신 생성

• 생성된 가상 머신 속성 정보 변경

• 가상 머신을 기존의 인벤토리에 추가

• 기존의 인벤토리에서 가상 머신을 제거

• 가상 머신을 시작하거나 중지, 정지 등 일련의 운영 작업

• ESXi 서버 또는 가상 머신의 상태 확인

• 원격 콘솔을 통해 가상 머신을 직접 제어

• 가상 머신의 스냅샷 생성 및 관리

vCenter Server 통신 포트 종류

포트번호	포트종류	설명
22	TCP	SSH 통신용
80	TCP	443 https 포트로 리다이렉션해 주기 위해서 존재하며, 실제 80번 포트를 통해 데이터 통신을 하지는 않는다.
123	UDP	NTP 통신용
443	TCP	https 통신용
902	TCP, UDP	전체 포트를 통틀어서 가장 중요한 포트 중의 하나이다. vCenter 서버와 ESXi 서버끼리의 인증(Authentication)과 Heartbeat를 전달해주기 위한 포트이다. 또한 가상 머신의 Console과 연결시켜 주기 위한 포트로 사용된다.
903	TCP	가상 머신의 Remote Console 연결용으로 사용되며, 이 역시 902 포트와 마찬가지로 매우 중요한 포트이다.
2049	TCP	NFS 서비스와 통신하기 위한 포트
2050-2250	TCP, UDP	HA 구성 완료 후 ESXi 서버끼리 통신하기 위한 포트
3260	TCP	iSCSI 서비스와 통신하기 위한 포트
8000	TCP	VMotion 트래픽이 사용하는 포트
8042-8045	TCP, UDP	HA 구성 완료 후 ESXi 서버끼리 통신하기 위한 포트
8100, 8200	TCP, UDP	Fault Tolerance가 작동하기 위한 통신 포트

VMware 스토리지 - 데이터스토어

OSMU-PIPELINE — Sat, 8 Oct 2022 23:19:02 +0900

데이터스토어는 ESXi에서 가상 머신을 담아두기 위한 저장소 역할을 한다. ESXi 서버에서는 이러한 저장소 위치를 논리적으로 구별하기 쉽게 하기 위하여 스토리지 볼륨을 생성하여 연결할 경우 label을 부여할 수 있는데, ESXi 서버에서는 그것을 데이터스토어라고 부른다. 데이터 스토어는 크게 세 가지 종류로 나뉜다.

VMFS 데이터스토어

VMFS 데이터스토어는 ESXi 서버에서 가상 머신의 디스크를 저장하는 저장소로서 가장 많이 선택하는 데이터스토어이며 VMFS 파일 시스템으로 포맷된 스토리지 볼륨을 나타낸다. 가상 머신 디스크 파일들(VMDK)은 VMFS 볼륨 위에 저장되며, 각 개별 가상 머신들은 VMDK 파일을 마치 자신에게 물리적으로 연결된 SCSI 디스크로 인식하게 된다. 하지만 ESXi 서버 입장에서 이러한 가상 머신 디스크들은 전부 파일로 존재할 뿐이다.

VMFS는 가상 머신 디스크의 특성상 고속의 접근이 가능하게끔 블록 크기가 매우 커다란 특징을 가지고 있다. 최초 VMFS 파일 시스템 생성 시 최소 1MB 블록 크기에서 최대 8MB 블록 크기를 선택할 수 있는데, 블록 크기가 크면 클수록 더 큰 크기의 가상 머신 디스크를 저장할 수 있다. 예를 들어, 만일 700GB의 디스크 크기가 필요한 가상 머신을 생성해야 할 경우라면 반드시 블록 크기가 4MB 이상으로 포맷된 VMFS 데이터스토어가 있어야 한다. 만일 초기 VMFS 데이터스토어 생성 시 이러한 사이징(Sizing) 계산의 실수로 인해 블록 크기를 1MB로 선택하여 VMFS를 생성하였다면 700GB 크기의 단일 가상 머신 디스크는 해당 VMFS 위에 생성할 수 없다. 이미 생성된 VMFS의 블록 크기는 VMFS 데이터스토어를 삭제하고 재생성하지 않는 한 변경할 수 없다.

가상 머신이 특정 ESXi 서버에서 작동하게 되면 VMFS는 다른 ESXi 서버가 열어 볼 수 없게끔 해당 가상 머신 디스크 파일에 대하여 Lock을 걸게 된다. 그렇게 함으로써 운영 중인 가상 신 디스크 파일에 대하여 동시에 2대 이상의 ESXi 서버가 업데이트 할 수 없도록 파일 보존성을 유지하게 된다. 한편 VMFS는 최대 32대의 ESXi 서버가 동시에 읽고 쓸 수 있도록 분산 락 매니지먼트(Distributed Lock Management) 기법을 통한 고성능 클러스터 파일 시스템 구조를 갖추고 있다. 이러한 특징으로 인해 가상화 데이터센터 운영에 절대적으로 필요한 VMotion이나 HA, DRS 등과 같은 기능들이 구현될 수 있게 되었다.

NFS 데이터스토어

VMFS 데이터스토어와 마찬가지로 NFS 데이터스토어 역시 가상 머신 디스크를 저장하기 위한 저장소로 사용된다. NFS 서비스를 제공하는 NAS 스토리지 시스템이나 서버와 연결하기 위해서는 VMkernel용 포트 그룹을 생성해야 하고 NFS 서비스와 통신할 수 있는 IP 주소를 입력해야 한다. NFS 데이터스토어는 VMFS 데이터스토어와 달리 블록 기반의 데이터스토어가 아니며, 운영체제가 제공하는 파일 기반의 공유 서비스를 이용한다. 그렇기 때문에 SCSI 명령을 통해 데이터 전송을 하는 것도 아니므로 VMFS 파일 시스템을 생성할 이유가 없다. 하지만 NFS 데이터스토어에서도 마찬가지로 VMotion과 HA, DRS 등의 기능이 실행 가능하다. 이렇게 복수의 ESXi 서버가 동시에 NAS 볼륨을 마운트 하여 사용할 경우 VMFS 데이터스토어에서와 마찬가지로 가상 머신 디스크 파일에 Lock을 걸어야 한다. 특정 서버에서 가상 머신이 작동할 경우 NFS 데이터스토어 안에는 별도의 .lck-XXX로 시작하는 숨겨진 파일이 생성되며, 다른 ESXi 서버에서 해당 가상 머신 디스크 파일을 열어볼 수 없도록 한다.

RDM 데이터스토어

RDM(Raw Device Mapping)은 가상 머신이 VMFS 데이터스토어나 NFS 데이터스토어 위에 가상 머신 디스크 파일을 소유하고 있는 것과 달리, 스토리지 시스템에서 제공하는 LUN을 직접 액세스 할 때 사용할 수 있는 데이터스토어이다. 가상 머신이 RDM을 사용해야 하는 대표적인 경우는 아래와 같다.

• 대량의 파일 크기로 인해 가상 디스크로 데이터 이전하기가 힘들 경우

• 가상 머신을 Microsoft Cluster Service를 이용하여 Cluster 구성할 경우

• 가상 머신에 SAN 스토리지 관리 소프트웨어를 직접 실행해야 하는 경우

RDM의 구현 방식은 위 그림과 같다.

RDM을 복잡하게 생각할 것 없이 일종의 심볼릭 링크(Symbolic Link) 또는 매핑 파일과 같은 것으로 이해해도 좋다. 윈도우 운영체제를 가상 머신 위에 설치하였다면 가상 머신 디스크는 VMFS 데이터스토어 또는 NFS 데이터스토어 위에 생성되지만, 스토리지 시스템에서 생성한 LUN을 직접 가상 머신에게 연결시켜야 한다면 RDM을 이용하면 가능하다.

RDM은 크게 두 가지 방식으로 지원된다.

• Virtual 호환 모드 - 가상 머신이 Raw 볼륨을 직접 액세스 하면서도 일반적인 가상 머신 디스크와 별반 차이 없이 작동된다는 장점이 있다. 가상 머신 디스크를 사용할 경우에 얻을 수 있는 여러 가지 기능들을 그대로 Virtual 호환 모드로 설정된 Raw 볼륨에게 적용시킬 수 있다.

• Physical 호환 모드 - Virtual 호환 모드의 경우 가상 머신 내의 게스트 운영체제가 Raw 볼륨에게 전달하는 SCSI 명령어들이 모두 필터링되거나 변환되어 전달되는 데 반해, Physical 호환 모드로 설정된 경우에는 REPORT LUNs SCSI 명령어를 제외한 모든 SCSI 명령어가 그대로 전달된다.

그렇기 때문에 하드웨어 스토리지 볼륨을 직접 접근해야 하는 SAN 기반의 스냅샷 관리 소프트웨어를 가상 머신에서 실행하거나, 또는 하나는 가상 머신이면서 다른 하나는 물리적 머신으로 MSCS를 구축해야 하는 경우에 사용한다. Physical 호환 모드는 VMkernel에서 최대한 SCSI 명령어를 필터링하지 않고 그대로 전달해 준다는 점이 장점이 될 수도 있지만, 대신에 Virtual 호환 모드를 사용함으로써 얻을 수 있는 스냅샷과 같은 기능들은 사용할 수 없다는 단점이 있다.

VMware 네트워킹 - 분산 스위치(Distributed Switch)

OSMU-PIPELINE — Thu, 6 Oct 2022 00:01:43 +0900

분산 스위치(Distributed Switch)

표준 가상 스위치를 생성하고 구성하는 것은 전부 ESXi 서버 호스트 위에서였다. 예를 들어, 3대의 ESXi 서버 호스트 위에 표준 가상 스위치를 생성한다고 가정해 보면, 가상머신용 포트 그룹을 가진 가상 스위치와 VMkernel용 포트 그룹 가상 스위치를 만들고 각각의 가상 스위치에 서버의 물리적인 NIC를 업링크로 연결시킨다. 업링크 연결 후 각 가상 스위치별 보안 설정과 Teaming 구성을 끝내고 난 후 네트워크가 정상 연결된 것을 확인한 다음, 이러한 똑같은 작업을 두 번째, 세 번째 서버에서 반복해야 한다. 세 번째 서버까지는 그러한 작업이 가능하나 10대, 20대, 100대가 넘는 ESXi 서버를 관리하는 가상화 데이터 센터 관리자라면 이야기가 틀려진다.

수십 대의 ESXi 서버에 여러 개의 표준 가상 스위치를 생성하고, 각각의 가상 스위치에 존재하는 각 포트 그룹이 제대로 생성되었는지, 그리고 가상 스위치별 보안 설정과 Teaming 설정은 문제가 없는지 20대의 ESXi 서버 전부 일일이 확인하는 것 정도는 애교 수준이다. 간혹 몇몇 가상 머신을 사용하는 유관 부서나 서비스 비용을 지불하는 특정 고객들이 SLA에 의거하여자신들의 네트워크 환경에 대한 별도의 보안이나 이중화 설정을 요구하게 되면, 해당 가상 머신이 작동되는 ESXi 서버에서만 가상 스위치 설정을 변경하는 것으로는 문제 해결이 되지 않는다. HA 구성을 위해서 클러스터 내의 다른 ESX서버에 대한 가상 스위치 환경도 다시 변경해야 하고 거기에 VMotion이나 FT와 같은 기능까지 설정해야 한다면, 그 순간부터는 무아지경에 이르게 될 것이다. 이러한 불편함과 복잡성을 제거하고 동시에 날로 거대해져 가는 가상화데이터 센터 네트워크 인프라를 좀 더 효과적으로 유연하게 관리하기 위해 VMware에서는 표준 가상화 스위치를 대체할 수 있는 vNetwork 분산 스위치 기능을 선보이게 되었다.

vNetwork 분산 스위치는 전체 ESXi 서버에 걸쳐져서 작동되는 일종의 거대한 데이터센터용 스위치이다. 정확하게 표현하면, 이 vNetwork 분산 가상 스위치의 실제 L2 스위치 엔진은 여전히 각 개별 ESXi 서버에서 작동하는 표준 가상 스위치이지만, 관리자가 가상 머신에게 네트워크를 연결하기 위해 바라보는 vNetwork 분산 가상 스위치는 전체 클러스터 내의 모든 ESX 서버를 하나로 통합시켜 관리하는 vCenter 서버에 존재하는 템플릿의 형태이다. ESXi 서버의 표준 가상 스위치에 생성하였던 포트 그룹은 전부 사라지고 전체 ESXi 서버를 아우르는 vCenter 서버 내의 vNetwork 분산 스위치 위로 올라가게 되었다.

vNetwork 분산 스위치를 생성하기 위해 vCenter 관리 서버는 반드시 필요하지만, 실제 네트워크 I/O를 담당하고 있지 않기 때문에 vCenter 서버에 장애가 발생하였다고 해서 전체 네트워크의 장애가 발생하는 것은 아니다. 다시 강조하건대, vNetwork 분산 스위치는 전체 클러스터 내의 모든 ESXi 서버에 걸쳐져서 작동되는 제목 그대로의 분산 스위치이지만, 이것은 어디까지나 관리자 입장에서 동일한 네트워크 화경을 빠르고 손쉽고 명확하게 지원해 주기 위한 일종의 커다란 템플릿의 개념으로 이해해야 한다. 같은 가상 머신 포트 그룹에 속해 있다 할지라도, 만약 가상 머신들이 다른 ESXi 호스트에 나뉘어 있다면, 서로가 통신하기 위해서는 반드시 업링크를 통해 외부 네트워크와 연결이 되어야만 가능하다는 점을 잊지 말아야 한다.

vNetwork 분산 스위치에 대하여 몇 가지 용어 정리를 해야 한다.

• 분산 스위치(dvSwitch) - 공식적인 명칭은 vNetwork Distributed Switch이다. 실제 vsphere를 관리하거나 VMware의 공식 매뉴얼이나 문서를 보게 되면 앞으로 dvSwitch라는 용어를 자주 접하게 될 것이다. dvSwitch는 vNetwork 분산 스위치를 나타내는 축약어이다.

• 분산 가상 포트(dvPort) - dvSwitch에 연결되는 VMkernel 또는 가상 머신용 네트워크 어댑터들이 연결되는 포트를 의미하며, 분산 가상 포트(Distributed Virtual Port)라고 부른다.

• 분산 가상 포트 그룹(dvPortGroup) - dvPort들의 그룹이며, 분산 가상 포트 그룹(Distributed Virtual Port Group)이라고 부른다. 표준 가상 스위치에서의 포트 그룹과 유사하다고 이해하는 편이 좋으며 다양한 Policy들을 적용할 수 있다. 단, dvPortGroup이 표준 가상 스위치의 포트 그룹처럼 Vmkernel용, 가상 머신용으로 나뉘어 있는 것은 아니다.

• 분산 가상 업링크 포트(dvUplink ports) - dvSwitch와 연결되는 ESXi 서버들의 각 물리적 NIC들이며, dvSwitch 입장에서는 업링크 포트를 의미한다. 분산 가상 업링크 포트(Distributed Virtual Uplink Port)라고 부른다. dvSwitch에서 dvUplink 포트를 지정할 때에는 각 ESXi 서버에서 업링크 포트로 몇 개를 사용할 것인지 지정해 주어야 하며, 이러한 업링크 포트로 지정된 물리적 NIC들은 전부 외부의 물리적 스위치와 연결되어 있어야 한다.

VMware 네트워킹 - 표준 가상 스위치

OSMU-PIPELINE — Wed, 5 Oct 2022 14:55:22 +0900

표준 가상 스위치

가상 스위치 앞에 표준(Standard)을 붙인 이유는 분산 스위치와 구별하기 위함이며, 또한 실제로 VMware에서도 Standard Virtual Switch라 구별하여 부르고 있기 때문이다.

가상 스위치는 VMkernel 위에서 CPU 파워를 이용하여 소프트웨어 기반으로만 작동되는 OSI Layer 2 기반의 스위치이다. 물리적인 L2 스위치와 비교하자면 몇 가지 공통점과 차이점을 가지고 있다. 기본적으로 L2 스위치 본연의 임무로써 MAC 주소를 전달해 준다는 점과 표준 VLAN 구성 및 업링크 연결까지 지원해 준다는 점에서 공통점을 가지고 있다. 반면에, 차이점은 루프 구조가 형성되지 않기 때문에 스패닝 트리 프로토콜이 작동하지 않는데, 즉 가상 스위치와 가상 스위치끼리 직접 연결할 수 있는 방법이 존재하지 않는다는 것이다. 또한 별도의 외부 인터페이스를 가지고 있지 않기 때문에 가상 스위치 내부 구성 자체를 열어볼 수는 없다는 점도 차이점이라 할 수 있다. 다시 강조하건대, ESXi 서버에서의 가상 스위치는 OSI Layer 2에 기반하기 때문에 라우팅 기능이 전혀 포함되어 있지 않다.

가상 스위치를 생성하면서 ESX 서버가 설치된 호스트 시스템의 어떤 물리적인 NIC를 업링크로 사용할 것인지 선택할 수도 있지만, 그 반대로 선택하지 않을 수도 있다. 다시 말하자면 업링크가 존재하지 않는, 즉 물리적인 NIC와 연결되어 있지 않은 가상 스위치를 생성할 수 있다. 이 경우에는 대부분 가상 머신들이 외부 세계와 통신할 필요가 없고 내부 통신만을 이용하는 경우에 많이 사용하기도 하며, 가상 머신에 가상 NIC를 두 개 장착해서 일종의 라우팅(Routing) 소프트웨어 기능을 게스트 운영체제에 답재하여 외부 업링크와 연결할 필요가 없는 가상 스위치와 함께 다른 가상 머신들을 위한 라우터 역할을 하는 데 사용하기도 한다.

Port Group

포트 그룹은 이전에 설명한 바와 같이 가상 스위치에 생성해야 하는 논리적인 포트 단위별 그룹인데, 가상 스위치를 생성하게 되면 최소한 무조건 한 개 이상의 포트 그룹을 생성해야 한다. 실제 가상 머신이 가상 스위치와 연결하기 위해서는 가상 스위치 이름을 보고 연결하는 것이 아니라 각 가상 스위치에 생성된 포트 그룹명에 연결하는 것이기 때문에 포트 그룹의 이해가 선행되어야 한다. 그런데 처음 ESXi 서버를 접하는 일부 사람들은 포트 그룹의 정체에 대하여 조금 의아해하는데, 사실 솔직히 포트 그룹을 설명하기가 애매한 것이 사실이다. 왜냐하면 전통적인 물리적인 스위치 환경과 비교하자니 딱히 그 비교 대상이 모호하다. 포트 그룹은 VLAN과 같은 개념도 아니고, 그렇다고 눈에 보이지도 않는 가상 스위치의 포트를 특정해서 부르는 것도 아니기 때문이다. 포트 그룹은 보안과 트래픽 단위 조절, 그리고 네트워크 이중화와 같은 속성을 지정할 수 있는 일종의 템플릿 단위라고 이해하는 편이 편하다. 그러나, 사실 이러한 보안이나 트래픽 조절, 네트워크 이중화와 같은 속성은 가상 스위치 레벨에서 지정할 수 있으며, 포트 그룹별로 특별히 속성을 설정하지 않는 한 가상 스위치의 속성을 그대로 이어받는다.

포트 그룹은 다음과 같은 종류가 존재한다.

• 가상 머신 포트 그룹

• VMkernel 포트 그룹

각 포트 그룹의 종류가 의미하는 바와 같이 가상 머신이 통신하기 위해서는 가상 머신 포트 그룹과 연결되어야 하며, VMotion이나 iSCSI와 같이 VMkernel이 외부와 연결하기 위해서는 VMkernel 포트 그룹을 가지고 있는 가상 스위치가 필요하다. 어떤 포트 그룹 종류를 선택하든지 각 포트 그룹에는 Network Label이라는 이름을 정의해 주어야 하며, 이 이름은 구별하기 쉽고 이해하기 쉬운 이름으로 명명하는 것이 좋다. 예를 들어, 가상 머신이 실제 네트워크 통신을 하기 위해서는 미리 생성하여 지정해 놓은 가상 머신용 포트 그룹과 연결을 해야 한다. 하지만 가상 머신 포트 그룹의 label 명이 public이나 VM network와 같은 이름으로 명명되어 있다면 조그마한 규모의 환경이라면 별 문제는 없겠지만 대규모의 환경이라면 부적합한 이름이 아닐 수 없다. 가능하다면 네트워크의 성격이나, IP 범위 또는 VLAN ID명과 같은 식의 조합으로 명명하는 것이 바람직하다.

NIC Teaming

서버 네트워크의 장애를 대비하기 위해 두 개 이상의 물리적인 NIC를 하나의 그룹으로 묶어 장애 대비를 도모함과 동시에 네트워크 트래픽의 부하를 분산시키고 있다. 흔히 이러한 구성을 티밍(Teaming)이라고 부르며, 본딩(Bonding)이라고 부르기도 한다. 이러한 티밍 구성은 크게 부하 분산과 장애 대비를 위한 두 마리 토끼를 잡기 위한 방안이다. ESXi 서버 역시 티밍 구성을 지원하고 있다.

Load Balancing

현재 물리적인 서버를 운영하는 사용자들 대부분은 물리적인 NIC의 트래픽 부하 분산을 위해 네트워크 드라이버 레벨에서 제공하는 로드 밸런싱 기능을 활용하고 있다. 마찬가지로, ESXi 서버에서도 이러한 로드 밸런싱 기능을 이용할 수 있다.

이 기능을 설정하기에 앞서 반드시 기억해야 할 두 가지 사항이 있다.

첫째로, 표준 가상 스위치에서 제공하는 모든 로드 밸런싱은 전부 Transmit 네트워크 트래픽, 즉 ESXi 서버에서 외부로 전달되는 네트워크 트래픽에 대해서만 관여하며, Receive 트래픽, 즉 외부에서 ESXi 서버로 들어오는 네트워크 트래픽에 대해서는 로드 밸런싱 기능이 작동되지 않는다는 점이다.

둘째로, 이러한 로드 밸런싱의 범위는 가상 스위치와 연결된 ESXi 서버의 물리적 NIC와 상위 물리적 스위치 간의 업링크 레벨에서만 해당된다. 개별적인 가상 머신과 가상 스위치와의 네트워크 연결 레벨에서는 로드 밸런싱 기능을 별도록 적용시킬 수 없다.

VMware 리소스 가상화 - 스토리지 가상화

OSMU-PIPELINE — Wed, 5 Oct 2022 02:30:02 +0900

스토리지 가상화

ESXi 서버 내의 가상 머신 안에서 작동되는 게스트 운영체제들은 자신이 인식하고 있는 디스크가 물리적인 디스크 컨트롤러에 연결된 일종의 하드 디스크라고 착각할 뿐이지만 실상은 그렇지 않다. ESXi 서버는 수많은 가상 머신들에게 다양한 크기의 디스크와 함께 또 각각 원하는 개수만큼, 그러면서 동시에 읽고 쓰는 데 있어 전혀 문제가 없게끔 디스크를 인식시켜 주어야 하지만, 그렇다고 해서 VMkernel이 인식하고 있는 물리적인 디스크를 가상 머신의 개수만큼 직접 연결시켜 주어야 한다면 이 역시 진정한 가상화 환경이라고 볼 수가 없을 것이다.

<스토리지 가상화>

ESXi 서버가 제공하는 스토리지 가상화의 가장 큰 핵심은 크게 두 가지이다. 그 하나는 바로 이러한 수많은 가상 머신들에게 어떻게 해서 가상의 하드 디스크를 인식시켜 줄 것인지이며, 다른 하나는 그러한 개별 가상 머신들의 하드디스크 데이터를 어떻게 저장하고 관리할 것인지, 즉 ESX 서버에서 운영하는 파일 시스템의 구조와 운영 방법의 이해이다. 우선 각각의 가상 머신들에게 개별 하드 디스크를 인식시켜 주기 위해서 갖추어야 할 요소는 바로 디스크 컨트롤러와 디스크 자체이다.

ESXi 서버에서는 다양한 가상 디스크 컨트롤러를 가상 머신에게 제공하고 있으며, 사용자는 초기 가상 머신 생성 시에 어떤 디스크 컨트롤러를 사용할 것인지 선택할 수 있다. 한편, 디스크의 경우 개별 가상 머신들에게 마치 자신의 디스크 컨트롤러에 직접 연결된 로컬 하드 디스크인 마냥 인식시켜 주게 되는데, 이를 가상 머신 디스크(VMDK: Virtual Machine Disk) 파일이라고 부른다. 예를 들어, C 드라이브가 100GB인 Windows 서버 가상 머신을 생성하였다면, 실제 ESXi 서버의 스토리지 볼륨에는 100GB 크기의 단일 VMDK 파일이 존재하는 것이다. VMDK 파일을 이해하기 위해서 그리 복잡한 구조를 들여다볼 필요 없이 우리가 주변에서 쉽게 볼 수 있는 ISO 이미지 파일을 떠올려 보면 된다. ISO 이미지 파일들은 단일 파일이면서 동시에 크기도 상당하다. 게다가 그 안에는 수많은 파일과 디렉토리 구조를 그대로 가지고 있다.

마찬가지로 VMDK 파일 역시 ISO 이미지 파일과 매우 유사한 구조이며, 동시에 가상 머신에게는 지오메트리와 파일 시스템 구조를 지니고 있는 일종의 하드 디스크로 인식된다. 다시 말하면, 이러한 VMDK 파일은 엄연히 가상 머신에게 일종의 하드디스크로 인식된다는 것이다. 따라서 만약 VMDK 파일을 삭제하게 된다면 가상 머신의 입장에서는 디스크가 통째로 사라진 것과 같고, VMDK 파일을 복사하게 된다면 마치 노턴 고스트 유틸리티를 이용하여 동일한 디스크 복제본을 생성한 것과 같은 경우에 해당된다.

그런데 이러한 VMDK 파일들은 단일 파일이면서 동시에 그 크기가 상당하다. 또한 그 특성상 고속의 접근이 이루어져야 한다. ESXi 서버 운영체제 입장에서는 이러한 파일을 담아두어야 할 특별한 파일 시스템이 필요하지 않을 수 없었다. VMFS(VMware File System)가 개발된 이유가 바로 이것이다. VMFS는 ESXi 서버에서 사용하는 파일 시스템이다. VMDK 파일들은 대부분 VMFS 위에서 작동되는데, 이 파일 시스템은 다음과 같은 두 가지 커다란 특징을 가지고 있다.

• 거대한 블록 크기 - VMFS는 기본적으로 블록크기를 최하 1MB부터 최대 8MB까지 설정할 수 있는 고성능 파일 시스템이다. 블록 크기가 이렇게 커다란 이유는 바로 VMFS 위에 저장되는 VMDK 파일들의 기본 크기가 워낙 크기 때문이다. 이렇게 커다란 단일 파일을 고속으로 접근하기 위해서는 블록 크기를 크게 가져갈 수밖에 없다.

• 클러스터 파일 시스템 구조 - 가장 잘 알려진 OCFS(오라클 파일 시스템)이나 Veritas CFS(베리타스 클러스터 파일 시스템)처럼 VMFS 역시 클러스터 파일 시스템 구조를 가지고 있는데, 최대 32대의 ESXi 서버들이 동시에 단일 VMFS 볼륨에 대하여 읽고 쓸 수가 있다. 이러한 클러스터 파일 시스템 구조의 특징으로 인해 하나의 VMFS 볼륨에 여러 대의 ESXi 서버 호스트들이 동시에 읽고 쓸 수 있지만, VMDK 파일은 오직 한 대의 ESXi 서버 호스트만 열어볼 수 있다.

위의 클러스터 파일 시스템 구조에서 살펴본 바와 같이, VMFS 파일 시스템을 언급하면서 항상 대두되는 중요한 개념이 바로 공유 스토리지(Shared Storage)라는 것이다. 여기서 언급하는 공유라 함은 개념적으로는 기존의 물리적 서버들이 각자 따로 보유하고 있던 DAS(Direct Attach Storage) 형태의 디스크들이 하나의 거대한 스토리지로 통합되는 것을 의미한다.

그리고, 기술적으로는 VMware 서버 가상화에서 제공하는 핵심 기능들, 이를 테면 HA, VMotion, DRS, DPM 기능들이 구현되기 위해서는 ESXi 서버들이 스토리지 시스템에 접근하여 동일한 VMFS 볼륨을 동시에 액세스해야 하는 것을 의미한다.

이상으로, VMkernel이 어떻게 해서 네 가지 하드웨어 구성요소를 가상화하여 운영하는지 그 방법과 구조에 대하여 설명해 보았다. 사실 냉정하게 말하자면, 그동안 x86 시스템에서의 가상화 기술 구현은 VMware 또는 Open Source 측에서 독자적으로 소프트웨어적인 기법을 통해 그 한계점을 벗어나고자 하는 몸부림 그 자체였으며, 뒤늦게 이에 대한 하드웨어적인 기술 지원과 같은 발판을 인텔과 AMD가 만들어 주고 있는 양상이다. 특히 CPU와 메모리의 가상화 기술 지원에 있어 인텔과 AMD 하드웨어 제조업체의 지원이 눈에 띄게 증가하고 있다.

이러한 지원과 기술의 발전에 힘입어 다가올 미래에 어떤 모습으로 가상화 진화하게 될지 너무나 기대가 된다.

이러한 지원과 기술의 발전에 힘입어 다가올 미래에 어떤 모습으로 가상화가 진화하게 될지 너무나 기대가 된다.

VMware 리소스 가상화 - 네트워킹 가상화

OSMU-PIPELINE — Tue, 4 Oct 2022 14:37:09 +0900

네트워킹 가상화

가상 머신들은 외부 세상과 통신하기 위해서는 반드시 물리적인 네트워크 인터페이스 카드(NIC)를 이용해야 한다. 호스트 시스템에 장착된 NIC에게 패킷을 전달하여 외부 세상과 통신해야 하지만 각각의 가상 머신들이 전부 자신만의 물리적인 NIC를 필요로 한다면 호스트 시스템에 장착해야 하는 NIC 개수는 가상 머신의 개수만큼 필요하다는 이야기이다. 이를테면 30개의 가상 머신이 작동되고 있는 x86 서버 시스템에 물리적인 NIC가 30개 장착이 되어야 한다는 것이다.

그러나 이것은 가상화 사상에 맞지도 않을뿐더러 현실성도 없는 이야기이다. 네트워킹 가상화는 바로 이러한 문제를 해결하기 위한 것이다. 즉, 모든 가상 머신들은 자신만의 가상 네트워크 어댑터를 가지고 호스트 시스템의 물리적인 NIC를 공유하여 사용하게 된다. 이러한 네트워킹 가상화의 간단한 구성은 다음을 통해 이해할 수 있다.

이 그림에서 가장 큰 핵심 요소는 바로 가상 스위치(Virtual Switch)라 할 수 있다. 게스트 운영체제의 애플리케이션에서 패킷을 보내고자 한다면 그러한 요청은 기본적으로 게스트 운영체제 안의 적절한 네트워크 스택(stack)에 의해 네트워크 어댑터 드라이버로 전달되지만, 운영체제 안에 설치된 가상 네트워크 어댑터 드라이버는 네트워크 패킷을 물리적인 NIC에 바로 전달하는 것이 아니라 VMkernel이 생성하여 운영하고 있는 가상 스위치에게 전달해 주고 가상 스위치는 전달받은 패킷을 적절한 주소로 다시 보내준다. 이때 가상 스위치는 소프트웨어적으로만 작동되기 때문에 가상 머신과의 물리적 연결이 필요 없으며, 사실상 일반적인 물리적인 스위치 구조에서 발생할 수 있는 케이블 미디어에서 발생하는 충돌 문제(Collision)나 오버헤드(Overhead) 자체가 존재하지 않는다는 장점이 있다. 가상 네트워킹 환경을 구성하는 각 요소들을 살펴보면 다음과 같다.

• 가상 NIC - 각각의 가상 머신들은 가상 스위치와 통신을 하기 위해 가상의 네트워크 인터페이스 카드를 갖추게 되는데, 이러한 가상 NIC는 각각 고유한 자신만의 MAC 주소를 갖게 되며 가상 스위치와 Auto Negotiation으로 연결을 하게 된다. 각각의 가상 머신에게 할당되는 가상 MAC 주소는 실제로 가상 머신이 생성되고 거기에 가상 NIC를 부여할 때마다 생성된다. 이때 그 MAC 주소는 아래의 범위에서 랜덤 하게 생성되어 부여된다.

00:05:59

00:0C:29

00:1C:14

00:50:56

위의 OUI(Organizationally Unique Identifier) 주소는 엄연히 VMware에서 IEEE에 정식으로 등록을 하였으며, 이는 IEEE 홈페이지에서 확인할 수 있다. 최종적으로는 이러한 OUI 주소값과 함께 ESX 서버가 설치된 시스템의 SMBIOS UUID 값 그리고 해당 가상 머신의 이름을 이용한 해시 값을 조합하여 가상 MAC 주소가 생성된다. 가상 NIC의 드라이버는 특별히 설정하지 않는 한 거의 모든 게스트 운영체제가 자체적으로 가지고 있는 AMD PCNET 드라이버는 최대 10 Mbps의 속도만을 제공할 뿐이다. 그렇기 때문에 항상 가상 머신을 생성한 이후에는 특별한 이유가 없는 한 반드시 VMware tools를 설치하여야 한다.

• 가상 스위치 - ESXi 서버에서는 모든 가상 머신들이 물리적인 네트워크 인터페이스 카드를 통해 외부와 통신하기 위해 가상 스위치를 만들게 된다. 이 가상 스위치는 엄연히 MAC 주소 값을 가지고 프레임을 전달해 주는 OSI Layer 2 기반의 스위치로서 VLAN 기능을 지원해 주고, 몇 가지 보안과 관련한 기능까지 갖추고 있어 기본적인 물리적 스위치와 매우 유사하다. 이것은 100% CPU 파워로만 작동되는 소프트웨어 스위치이기에 물리적인 구성 환경에서 발생할 수 있는 케이블 연결에 따른 오버헤드나 충돌 등의 문제가 전혀 발생하지 않는 장점이 존재하지만, 그렇다고 해서 하드웨어 기반의 기존 L2 스위치와 완전히 똑같은 기능을 갖춘 일반 스위치로 동일시 여겨서는 곤란하다.

• 포트 그룹(Port Group) - 포트 그룹은 가상 스위치에서 관리하는 일종의 논리적인 그룹 단위이며, 실제로 가상 머신이 가상 스위치에 연결하고자 할 경우에는 가상 스위치에 생성된 포트 그룹을 지정해주어야 한다. 포트 그룹은 크게 가상 머신용 포트 그룹, VMkernel용 포트 그룹의 종류로 나누어진다. 하나의 가상 스위치에는 복수의 포트 그룹이 존재할 수 있다. 예를 들어, 가상 머신이 가상 스위치를 통해 외부와 통신하기 위해서는 가상 머신용 포트 그룹과 연결되어야 한다. 마찬가지로, VMkernel용 포트 그룹은 VMotion이나 NFS 마운트, iSCSI 등의 연결과 같이 VMkernel에서 외부 네트워크 연결이 필요할 경우 생성해야 할 포트 그룹이다. 관리자들은 가상 스위치 전체를 하나의 포트 그룹 전용으로 설정할 수도 있으며 하나의 가상 스위치에 여러 형태의 포트 그룹을 혼용하여 사용할 수도 있다. 그러나 물리적인 NIC는 반드시 단 하나의 가상스위치에만 연결할 수 있으며 두 개 이상의 가상 스위치에 교집합처럼 연결될 수 없다. 따라서 물리적인 NIC에 여유가 없는 경우라면 소수의 가상 스위치에 포트 그룹을 세분화하여 사용할 수도 있지만, 그 반대로 물리적인 NIC가 여유가 있다면 포트 그룹별로 가상 스위치를 따로 생성하여 각각 물리적인 NIC를 할당하여 사용할 수 있다.

<가상 스위치 포트 그룹>

• 물리적 NIC - 호스트에 장착된 물리적 NIC는 가상 스위치와 맞물려 일종의 업링크 포트처럼 인식된다. 가상 스위치는 가상 머신용 포트 그룹에 연결된 각각의 가상 머신들의 네트워크 프레임을 물리적 NIC가 연결된 업링크 포트로 전달하여 외부 세상과 연결시켜 준다. 물리적 NIC는 VMkernel에서 PCI 버스 장치 순서대로 vmnicX라는 장치명으로 인식하는데, Linux로 말하자면 eth0, eth1과 같은 식이다.

• 물리적 네트워크 - 당연히 가상 머신이 최종적으로 외부 세계와 통신하기 위해서는 물리적인 스위치 또는 라우터가 존재하여야 하지만, 이러한 물리적 네트워크 환경과 ESXi 서버를 연결하면서 가장 크게 고려해야 하는 사항들은 바로 네트워크 이중화 구성과 대역폭 확장, 그리고 VLAN 구성과 관련한 부분들이다.

VMware 리소스 가상화 - 메모리 가상화 구현 기술

OSMU-PIPELINE — Tue, 4 Oct 2022 02:15:10 +0900

Transparent Page Sharing

호스트 시스템 위에 작동 중인 다수의 가상 머신들 대부분이 동일한 게스트 운영체제를 실행하는 조건이라면, 이를테면 Windows 운영체제에서 동일한 버전일 경우 그 안에서 필수적으로 항상 실행되는 기본적인 DLL이나 EXE 등과 같은 내용들은 동일하다. 따라서 이러한 내용들을 함께 공유할 수만 있다면 물리적 메모리 공간을 좀 더 효율적으로 사용할 수 있지 않을까 하는 것이 바로 Transparent 페이지 공유 기술(이하 TPS)의 배경이다.

우선 작동 중인 가상 머신 중에서 몇몇 후보군을 선택한 다음, 게스트 물리 메모리의 내용을 기반으로 한 해시(Hash) 값을 뽑아내어 그것을 기준으로 혹시 동일한 내용이 담겨 있는지 호스트 물리 메모리 페이지와 비교한다. 이때 해시 값과 동일한 엔트리 내용이 발견된다면 매우 정밀하게 페이지 전체를 스캔하여 그 내용이 완전하게 똑같은지 확인하게 된다.

만약 같을 경우 VMkernel은 해당 가상 머신이 공유 메모리 페이지를 바라보게끔 게스트 물리 메모리와 호스트 물리 메모리 간의 매핑 주소를 바꾸게 되며, 원래 자리를 차지하고 있었던 호스트 물리 메모리 페이지는 비워버리고 그만큼 공간을 확보하게 된다.

문제는 이렇게 가상 머신들이 동일한 공유 메모리 페이지를 바라보고 있다가 어느 한쪽의 가상 머신 중에서 갑자기 실제 해당 메모리 페이지 내용에 변경이 생겨 업데이트가 발생할 경우이다.

이러한 경우 VMkernel은 업데이트가 발생한 해당 가상 머신을 위한 메모리 페이지를 새롭게 생성해 주고 올바른 메모리 페이지 주소를 바라볼 수 있도록 다시 매핑 주소 값을 변경해 준다.

Memory Ballooning

메모리 풍선효과라 부르는 이 기술을 설명하기에 앞서 가상 머신과 하이퍼바이저 간의 메모리 인식에 관한 서로 간의 입장을 다시 살펴볼 필요가 있다. 가상 머신 안에서 작동 중인 게스트 운영체제는 자신이 인식하고 있는 메모리가 그저 실제 물리적 메모리인 것으로 이해하고 있으며, ESX 서버 내의 모든 가상 머신들은 그렇게 착각하고 있을 뿐이다. 하지만 ESXi 서버는 어떻게든지 최대한 더 많은 가상 머신들을 작동시켜 주기 위해 발버둥을 칠 뿐이며, 물리적인 메모리 크기가 턱없이 부족해지고 줄어들지언정 그렇다고 해서 가상 머신들이 그러한 어려움을 이해하고 자발적으로 메모리를 반납하는 일은 결코 없을 것이다.

메모리 풍선효과 기술은 바로 이러한 점을 노린다. ESXi 서버 내에 작동되는 가상 머신에는 각종 유틸리티 및 드라이버가 담겨 있는 VMware tools를 설치하게 되는데, 이 안에는 vmmemctl이라 불리는 메모리 컨트롤러 드라이버가 같이 설치된다. 이 드라이버는 VMkernel과 Private 채널을 생성하여 통신을 하며, 서로 간의 메모리 상태를 파악하고 각종 정보를 주고받게 된다. 호스트의 전체 물리적인 메모리 크기가 부족할 경우 VMkernel은 가상 머신들 안에 설치된 메모리 컨트롤러 드라이버에게 명령을 내려 게스트 운영체제 내부의 메모리를 팽창시키도록 한다. 게스트 운영체제는 영문도 모른 채 늘어만 가는 메모리 점유율을 줄이고자 자신이 가지고 있는 고유한 가상 메모리 스와핑(Swapping) 알고리즘을 이용하여-이를테면 windows의 pagefile.sys에-착실하게 메모리의 내용들을 가상 메모리 쪽으로 페이지 아웃시킨다. 메모리 컨트롤러 드라이버는 이렇게 비워져 버린 메모리 페이지 위치를 친절하게 VMkernel에게 알려주고, VMkernel은 그 위치에 해당하는 호스트 물리 메모리의 주소를 비우게 되어 최종적으로 물리 메모리의 공간을 확보하게 된다. 메모리 공간이 확보된 이후 호스트의 물리적인 메모리에 어느 정도 다시 여유가 생겼다면 VMkernel은 다시 메모리 컨트롤러 드라이버에게 팽창시킨 메모리를 수축시킬 것을 지시하고, 자연스럽게 게스트 운영체제의 메모리 알고리즘에 의해 스왑 메모리에 페이지 아웃되었던 메모리 내용들이 다시 원 위치로 돌아오게 된다.

하이퍼바이저 스와핑

TPS와 메모리 풍선효과 기술을 통해서도 호스트 물리 메모리의 공간 부족 압박이 해결되지 않을 경우, 최종적으로 ESXi 서버는 하이퍼바이저 스와핑 기술을 사용한다. 기본적으로 가상 머신이 시작될 때 ESXi 서버는 각 가상 머신에게 할당된 메모리 크기만큼 동일한 스왑 파일을 생성한다.

호스트 물리 메모리 공간 부족 압박이 심해질 경우 ESXi 서버는 가상 머신의 게스트 물리 메모리를 직접 스와핑 하면서 전체적으로 다른 가상 머신들을 위해서 호스트 물리 메모리의 공간을 확보하게 된다. TPS나 메모리 풍선효과 기술에 의해 호스트의 물리 메모리 공간이 최종적으로 확보되기 위해서는 나름대로 최적의 알고리즘에 의해 계산되기 때문에 어느 정도의 시간도 필요하며 즉각적이지는 않지만 성능에 크게 영향을 주지 않는 반면, 하이퍼바이저 스와핑은 확보할 수 있는 호스트 물리 메모리 공간은 확실히 눈에 띌 정도이며 즉각적이지만 그만큼 전체 가상 머신의 성능에는 커다란 영향을 끼친다. 가장 좋은 최선의 메모리 대처 방법은 애초 호스트 물리 메모리가 부족하지 않도록 적당한 수준에서 가상 머신의 메모리들을 사이지(sizing)하는 것이며, 가능한 하이퍼바이저 스와핑까지 일어나지 않도록 하는 것이다.

VMware 리소스 가상화 - 메모리 가상화

OSMU-PIPELINE — Mon, 3 Oct 2022 14:26:16 +0900

Shadow Page Table

현대 운영체제들은 메모리 관리를 하기 위해 두 가지 주소 체계를 사용하고 있는데, 하나는 물리적 주소(Physical Address)이며 다른 하나는 가상 주소(Virtual Address)이다. 물리적 주소는 실제 호스트 시스템에 장착된 물리적인 메모리의 크기에 해당하지만, 가상 주소는 운영체제에서 실행되는 모든 프로세스들에게 할당되는 주소이다. 32비트 운영체제의 경우 각 프로세스들은 약 4GB까지, 64비트 운영체제의 경우 이론적으로 약 16TB까지의 가상 주소를 사용할 수 있게 된다.

이렇게 각 프로세스들은 전부 자신만의 가상 주소 값을 가지게 되므로 물리적 주소의 실제 크기에 상관없이 운영체제에서 제공하는 크기만큼 소유하게 된다.

이러한 프로세스들이 포인터를 통해 가리키는 메모리 주소 위치는 실제 물리적인 메모리 주소가 아닌 가상 메모리 주소의 위치이므로, 누군가 이러한 가상 메모리 주소의 위치를 실제 물리적인 메모리 주소의 위치로 연결시켜 주는 역할을 담당해야 하며, 이것을 PTE(Page Table Entery)라 부르는 테이블에 인덱스화해서 저장하여 사용한다. 또한 이러한 연산 작업에 대한 부하를 줄이고자 CPU에 포함된 MMU(Memory Management Unit)와 TLB(Translation Lookaside Buffer)의 도움을 받는다.

여기까지는 전통적인 시스템 환경, 즉 가상화가 아닌 시스템에서의 이야기이지만, ESXi 서버가 실행되는 시스템에서는 조금 틀려진다. 예를 들어, 2GB 메모리를 지닌 가상 머신이 있다고 하자.

이 가상 머신을 실행하게 되면 VMkernel은 가상머신에게 2GB의 연속된 물리적인 메모리가 존재하는 것처럼 인식시켜 주며, 가상 머신은 자신에게 물리적인 2GB 메모리가 존재하는 것으로 착각하게 된다. 이렇게 VMkernel 위에서 초기 생성 시 설정된 메모리 크기만큼을 전부 실제 자신의 물리적인 메모리라며 착각하고 실행되는 가상 머신들이 한두 개가 아니다.

VMkernel은 모든 가상 머신들이 실제로 자신은 연속된 물리적인 메모리를 가지고 있다는 환상을 심어주어야 한다. 또한 게스트 가상 메모리 주소의 위치가 최종적으로 호스트 물리 메모리의 어떤 위치에 해당하는지에 대한 주소 매핑 작업을 해야만 하기 때문에, 결국 또 다른 주소 매핑을 도울 테이블이 필요하다. ESXi 서버에서는 그것을 Shadow Page Table이라고 부른다. Shadow Page Table을 통해 게스트 가상 메모리와 게스트 물리 메모리 간, 그리고 게스트 물리 메모리와 호스트 물리 메모리 간의 매핑이 이루어지게 된다. TLB 캐시는 직접 Shadow Page Table을 뒤져서 게스트 가상 메모리에서 호스트 물리 메모리까지의 매핑 주소 값을 직접 읽게 되어 일반적인 가상화의 메모리 주소 매핑에 따른 어려움을 해결하 수 있게 되었다.

Shadow Page Table을 통해 실제 게스트 가상 메모리와 호스트 물리 메모리 간의 매핑에 대한 숙제가 해결되었으나, 수많은 가상 머신들이 제한된 호스트 시스템의 물리적인 메모리를 좀 더 효과적으로 사용하고자 하는 노력은 오히려 메모리 오버커밋먼트와 같은 기술로 빛을 발한다. 메모리 오버컷먼트(Over-commitment)가 의미하는 기능은 매우 단순하다.

물리적으로 메모리 크기가 제한된 시스템 위에 전체 가상 머신의 메모리 합이 더 초과되더라도 정상적으로 운영할 수 있게끔 해주는 것이다.

간단하게 예를 들어, 4GB 물리적 메모리가 장착된 호스트 시스템 위에 2GB의 메모리를 지닌 가상 머신이 세 개가 실행되더라도 정상 작동되게끔 지원해 주는 것이 메모리 오버커밋먼트 기능이다.

ESXi 서버는 이러한 메모리 오버커밋먼트 기능을 크게 다음과 같은 세 가지 방법으로 지원하고 있다.

• Transparent Page Sharing

• Memory Ballooning

• 하이퍼바이저 Swapping(스와핑)

이 세 가지 기술에 대해서는 다음글에 기술하도록 하겠다.

VMware 리소스 가상화 - CPU 가상화

OSMU-PIPELINE — Mon, 3 Oct 2022 05:45:22 +0900

CPU 가상화

가상 머신도 엄연히 CPU를 지니고 있지만, 실제로 이러한 가상 머신 내의 게스트 운영체제에서 발생하는 모든 프로세스들은 전부 물리적인 CPU에서 처리가 이루어진다. 제2장에서 언급한 것처럼, 게스트 운영체제에서 발생하는 CPU 프로세스들은 VMkernel의 VMM을 통해 실제 물리적인 CPU로 프로세스 처리가 이루어질 수 있도록 전달된다. VMkernel은 모든 가상 머신들에게 발생하는 CPU 프로세스들을 기본적으로는 최대한 균등하게 분배될 수 있도록 전체 물리적인 CPU 리소스를 적극적으로 스케줄링한다.

VMekrnel은 모든 가상 머신에서 발생하는 프로세스들을 물리적인 CPU에 골고루 할당하여 처리한다. 이때 전체 물리적 CPU 리소스들에 과도한 부하가 발생하지 않도록 VMkernel은 이른바 Time-slice(시분할) 방식을 통해 프로세스를 처리하도록 노력한다. 기본적으로 VMkernel은 20ms 단위로 물리적인 CPU 상태를 확인하면서 한가한(Idle) CPU가 없는지 확인하며, 가상 CPU와 물리적인 CPU 간의 연결 작업을 진행한다.

흔히 CPU-bound 애플리케이션들, 즉 명령을 처리하는 데 있어서 사용자 또는 외부 장치와의 입력을 기다리거나, 그리고 데이터 추출을 위해 다른 프로세스를 처리할 수 있게끔 여유를 갖춘 애플리케이션이 아닌 순수하게 CPU 연산 작업만을 처리하는 데 있어 오랜 시간을 필요로 하는 애플리케이션들이 작동하는 가상 머신들이 있다. 그런 경우, 어디까지나 모든 가상 머신들이 충분히 균등하게 물리적인 CPU를 활용할 수 있도록 노력해야 하는 ESX 서버 입장에서는 그다지 환영할 만한 일은 아니다.

멀티코어 프로세서

현재 시장에서는 쿼드코어, 헥사코어, 옥타 코어 등 멀티코어 프로세서가 주류를 이룬다.

예를 들어 듀얼코어 2 소켓 CPU의 경우 ESXi 서버는 총 네 개의 논리적 프로세서 단위로 인식하고, 그 위에 가상 CPU를 할당하여 사용한다. 그렇기 때문에 두 개의 가상 CPU(가상 SMP)를 가지고 있는 가상 머신의 경우 동일한 소켓 안의 멀티코어에서 프로세스가 처리되는 경우도 있지만, 각각 다른 소켓의 코어에서 프로세스가 처리되는 경우도 있다.

정리하면, 물리적인 멀티코어 프로세서가 장착된 호스트 시스템에 ESXi 서버가 설치가 될 경우 최대한 모든 소켓의 코어에 균등하게 분배하여 가상 CPU가 할당될 수 있도록 노력하는 것이 기본적인 작동방식이다.

하이퍼스레딩

하이퍼스레딩(Hyperthreading)은 운영체제가 물리적인 한 개의 CPU를 두 개의 논리적인 CPU처럼 인식하여 작동하게끔 해주는 기술이다. 하지만 모두 알다시피, 듀얼코어의 경우 연산 라인(Instruction pipeline)과 실행 라인(Execution pipeline)이 각각 두 개씩 포함되어 있다. 그와 달리 하이퍼스레딩 기능만 가지고 있는 싱글코어의 경우는 연산 라인만 두 개이며, 실행 라인은 한 개에 불과하기 때문에, 하이퍼스레딩을 사용한다고 해서 성능이 두 배로 뛰어오르는 것은 아니다. 기본적으로는 연산 라인이 두 개이기 때문에 하이퍼스레딩 기능이 작동하지 않는 경우와 비교하면 데이터 입력의 경우는 이론적으로 빠를지 모르나, 데이터 출력을 담당하는 실행 라인이 어차피 하나이기 때문에 커다란 성능의 효과를 기대하기 힘들다. 게다가 CPU 내부의 캐시 메모리도 같이 공유하기 때문에 특정 애플리케이션의 경우 성능이 오히려 더 저하되는 경우도 발생할 수 있다.

ESXi 서버 역시 하이퍼스레딩을 지원한다. 하이퍼스레딩 기능이 설정된 경우, ESXi 서버는 그것을 전부 논리적 프로세서 단위로 인식한다. 이를테면 쿼드코어인 CPU를 네 개 장착한 시스템에 하이퍼스레딩을 사용하게끔 설정한 경우 ESX 서버에서 인식하는 논리적 프로세서 단위는 총 32개가 된다. 이때 ESXi 서버에서 인식하는 논리적 프로세서 순서는 코어 순서대로이다. 즉, 첫 번째 코어에서 CPU 0번과 1번을 인식하며, 두 번째 코어에서 CPU 2번과 3번을 인식하는 순서이다.

기본적으로 ESXi 서버는 가상 CPU를 모든 소켓의 코어에 균등하게 분배될 수 있도록 노력하기 때문에, 하이퍼스레딩이 설정되어 있는 경우에도 마찬가지로 가능한 한 동일한 하나의 코어에 가상 SMP머신이 할당되지 않도록 소켓 단위 또는 코어 단위로 분산시켜 할당한다. 그렇지만 이러한 분산 방식에 있어서도 항상 고정적인 것은 아니며, 가상 머신별로 아래의 세 가지 설정을 통해 논리적 프로세서들을 어떻게 할당받아 사용할 것인지 결정할 수 있다.

• Any - 기본적인 방식이며, 모든 가상 머신들은 하이퍼스레딩이 설정된 동일한 코어를 다른 가상 머신과 함께 공유하여 사용하도록 한다.

• None - 가상 머신이 일단 하나의 코어를 사용하고 있다면 다른 가상 머신들이 동일한 코어의 논리적 프로세서를 사용하지 못하도록 같은 코어 내의 다른 로지컬 프로세서를 Halt 상태로 떨어뜨려 버린다.

• Internal - None과 동일한 방식이다. 만일 SMP로 구성된 가상 머신의 경우, 같은 가상 CPU가 동일 코어 내의 논리적 프로세서를 사용하고자 할 경우에는 예외로 허용한다. 즉, 이 옵션은 SMP 가상 머신에서만 설정할 수 있다.

일반적인 환경에서는 None이나 Internal 옵션을 선택할 일이 전혀 없으나 간혹 캐시 공유 문제로 인해 애플리케이션의 성능이 과도하게 저하될 경우 이러한 옵션 변경을 통해 테스트를 시도해 보는 경우가 존재한다. 하지만 이러한 옵션 선택은 아주 신중해야 한다. 실제 서비스 운영 환경에서는 충분한 테스트와 검증을 통한 이후에만 적용해야 한다.

VMware ESXi 서버구조 - VMkernel

OSMU-PIPELINE — Sun, 2 Oct 2022 18:00:01 +0900

VMkernel

VMkernel의 가장 큰 역할은 하드웨어 리소스 스케줄링을 담당하는 것이다. 일반적인 범용 운영 체제와는 달리, 목적 자체가 가상 머신을 생성하고 작동시키기 위한 것이기 때문에 매우 가볍고 견고하게 제작되었다. 가상화를 위한 하드웨어 리소스 스케줄링을 포함한 기타 자세한 역할은 다음과 같다.

• 하드웨어 리소스 스케줄링 담당 - VMkernel은 하드웨어 리소스를 직접 조정하여 가상 머신들이 리소스 사용을 요구할 때 즉각 접근할 수 있게끔 리소스 스케줄링을 담당하는 가장 중요한 역할을 담당한다. 특히 CPU와 메모리 리소스를 가상화하는 방식은 상당히 중요하다. CPU, 메모리, HDD, 네트워크의 네 가지 중요한 하드웨어 리소스들을 어떻게 가상화하고 사용하는지 그 자세한 내용은 다음에 설명해 보도록 하겠다.

• User World 프로세스 담당 - VMkernel에서 실행되는 프로세스들을 ESX 서버에서는 User World 애플리케이션이라고 부른다. 정통 POSIX 규약을 따라가는 형태이지만, 그렇다고 일반 범용 운영체제(ex.Linux)의 프로세스와는 동일하지는 않으며, 가상화 운영체제를 작동하기 위한 목적에 부합되도록 제한된 syscall 기능을 갖추어 최적화되어 있다.

• 가상 머신을 위한 VMM 운영 - VMM은 Virtual Machine Monitor의 약자이며, 가상 머신에서 실행되는 실제 CPU 명령을 전달하는 중개자 역할을 담당한다. 모든 개별 가상 머신에게는 각각 하나의 VMM이 반드시 생성되는데, 가상 머신이 시작되면 CPU 명령어를 물리적인 CPU에 전달하고, 또한 개별 가상 머신들이 서로 충돌이나 간섭 없이 작동될 수 있도록 격리(isolation)시키는 역할도 담당한다. ESX 서버에서 VMM이 실제 물리적인 CPU에게 명령을 던질 경우에는 직접 물리적인 CPU에게 명령어를 던지거나, 또는 간접적으로 에뮬레이션 화해서 던지는 두 가지 방식을 선택한다. 이러한 상세한 접근 방법은 나중에 설명하겠다.

• VMX 프로세스 운영 - VMX 프로세스는 VMkernel에서 작동되는 User World 애플리케이션이며, 하나의 VM에게는 하나의 VMX 프로세스가 실행이 된다. 이 VMX는 직접 VMkernel에서 가상화하여 조종하는 장치가 아닌 CD-ROM, 플로피 드라이브, 시리얼 포트와 같은 장치들을 서비스 콘솔을 통해 가상 머신들이 접근하여 사용할 수 있게끔 중개자 역할을 한다. 또한 가상 머신들의 시작( Power on)과 종료(Shutdown) 시그널을 전달하는 역할도 담당하며, Hostd 프로세스와 통신하여 가상 머신의 각종 정보를 전달하기도 한다.

ESXi 구조

• Hostd 프로세스 - vCenter 서버 또는 VMware vCenter Client 프로그램과 통신을 하며 호스트의 구성 정보 값, 가상 머신들의 인벤토리 및 각종 정보, 성능 데이터 등을 전달한다.

• Vpxa 프로세스 - 흔히 vCenter 에이전트라고 부른다. ESXi 서버가 최초 vCenter 서버에 추가될 때 자동으로 설치/작동되며 vCenter 서버와 통신하기 위한 에이전트 서비스이다.

• DCUI(Direct Console User Interface) - 실제 하드웨어 시스템에 연결된 키보드와 비디오를 통해 VMkernel의 중요 정보 값들을 살펴보거나 구성할 수 있게끔 도와주는 사용자 인터페이스 프로그램이다. 마치 일반 시스템의 ROM BIOS 메뉴를 선택하는 것과 흡사한 인터페이스를 갖추었으며, 매우 손쉽게 설정할 수 있다는 장점이 잇다. DCUI를 통해 초기 IP 주소 입력과 root 계정의 암호 설정뿐만 아니라 로그 살펴보기, 네트워크 연결 테스트, Hostd 에이전트 재시작, 각종 설정 초기화 등 트러블슈팅과 관련 항목까지 작업할 수 있다.

• CIM 브로커(Broker) - 일종의 하드웨어 리소스 모니터링 프레임 워크이며, 흔히 CIM 브로커라 일컫는 CIM Object Manager와 다양한 CIM providers로 구성되어 있다. 이를 통해 ESXi는 별도의 에이전트 없이도 기본적인 하드웨어 모니터링 정보를 전달해 줄 수 있게 되었다.

• Syslog, SNMP 데몬 운영 - iptables에 기반한 방화벽 프로그램과 syslog 데몬 그리고 SNMP 서비스 등이 직접 VMkernel 위에서 실행된다.

ESXi 파티션 정보

ESXi의 파티션 구조는 크게 5개로 나누어진다. 각 파티션은 다음과 같은 정보를 담고 있다.

• Bootloader 파티션 - 부트로더가 담겨 있다.

• Boot Bank 주 파티션 - VMkernel(32MB)과 서버 하드웨어 제조업체들의 고유한 CIM providers(약 16MB)가 포함되어 있다.

• Boot Bank 부 파티션 - 주 파티션에 문제가 발생할 경우를 대비한 이중화 파티션이다. 이를테면 듀얼 바이오스와 같은 개념으로 이해하는 편이 좋다.

• 스토어 파티션 - VMware tools와 VMware vCenter Client 도구가 담겨 있다.

• 코어 덤프 파티션 - VMkernel의 크래시 덤프가 담겨 있다.

보다시피, 사실 VMkernel 자체는 32MB이지만 부트로더와 커널 파티션 이중화 그리고 각종 도구와 크래시 덤프 파티션을 담아두다 보니 전체 크기는 약 750MB이다. 재미있는 것은 Boot Bank가 이중화로 구성되어 있다는 것이다. 이것은 마치 일반 x86 서버에서도 확인할 수 있는 것처럼 ROM BIOS가 이중화되어 있는 것과 동일한 개념이다. 만일 첫 번째 Boot Bank 파티션이 깨지거나 문제가 발생하여 제대로 부팅이 되지 않을 경우 두 번째 부 파티션으로 부팅이 이루어진다. 필요하다면 초기 부팅에서 아예 어떤 파티션 쪽으로 부팅을 할 것인지 직접 선택하는 것도 가능하다.

VMware의 기능 소개(HA, Fault Tolerance, 기타 기능) - ②

OSMU-PIPELINE — Sun, 2 Oct 2022 07:00:33 +0900

VMware HA

<HA>

물리적인 ESX 호스트가 하드웨어 오류로 인해 작동이 멈출 경우 그 위에서 작동 중인 가상 머신들을 자동적으로 다른 클러스터 내의 ESX 호스트들에게 이동시켜(Failover) 주는 기능이다. 실제 하드웨어 장애가 발생하여 HA 기능이 작동될 경우 장애가 발생한 호스트 시스템에서 실행 중인 가상 머신들은 재시작되어 다른 ESX 호스트로 이동된다. 이런 이유로 많은 이들이 고가용성(High Availability)이라는 제목과는 어울리지 않는다는 지적을 하지만, 상대적으로 매우 저렴하고 간단하게 구성할 수 있는 고가용성 서비스임에는 틀림이 없다.

VMware Fault Tolerance

<FT>

위에서 언급한 HA 기능에 만족하지 못하는 경우, 어떠한 경우에도 99.99% 이상의 고가용성을 만족해야 하는 서비스를 운영해야 한다면 Fault Tolerance(이하 FT) 기능을 사용하길 권장하고 있다.

HA의 경우 하드웨어 장애가 발생할 때 가상 머신들이 재시작되어 이동된다는 단점이 존재하지만, FT의 경우
VMware에서 개발한 vLockStep 기술을 이용하여 원본 가상 머신과 완전히 똑같은 복제된 가상 머신을 다른 ESX 호스트에서 실행시키면서 원본 가상 머신에서 발생하는 모든 I/O와 인터럽트들이 복제된 가상 머신에서도 동일하게 일어나게 된다.

원본 가상 머신이 하드웨어 장애로 인해 운영이 중단되자마자 복제된 가상 머신에서 그 즉시 모든 작업을 이어받아 서비스 진행이 가능하다.

VMware vNetwork Distributed Switch(분산 스위치)

<분산 스위치>

과거의 제품의 경우 ESX 호스트 개별적으로 가상 스위치를 생성하고 관리해야만 했기 때문에 관리의 복잡성이 수반되었고 구성의 일관성이 필요하였다.

그래서 현재의 제품에는 전체 ESX 호스트에 걸쳐 작동되는 거대한 하나의 가상 스위치 프로파일을 생성할 수 있게 되었다.

개별 ESX 호스트별로 서비스 콘솔, VMotion, 가상 머신 등의 포트그룹을 지닌 vSwitch를 만들고 또 그것이 DRS와 HA 클러스터로 구성되어야 한다면 클러스터 내의 ESX 호스트들끼리 똑같은 가상 스위치를 만들어 주어야 하는 등 가상 스위치를 개별 서버별로 제각기 구성하는 것이 아니라 vNetwork 분산 스위치 기능을 이용하여 vCenter를 통해 전체 ESX 호스트에 동일한 네트워크 가상 스위치를 적용시키게 됨으로써 관리의 일관성과 단일성을 갖게 되었다.

VMware Update Manager

ESX 서버 운영체제의 패치 파일뿐만 아니라 대표적인 게스트 OS-Windows나 Linux의 패치 파일, 심지어 게스트 OS 내부에 설치되어 있는 애플리케이션들 중 일반적으로 잘 알려진 범용적인 프로그램들(Adobe, MS Office)의 패치파일까지

웹을 통해 다운로드하여 정해진 정책에 따라 패치 적용을 해주고 관리해 주는 프로그램이다.

수십, 수백 대의 가상 머신의 패치 적용 및 관리에 대한 효과적인 대안이 될 수 있다. 게다가 ESX 서버의 패치들 역시 일목요연하게 중앙에서 쉽게 관리할 수 있다. 시스템 재시작이 필요한 중요 패치의 경우 VMotion 기능과 연계하여 운영 중인 가상 머신들의 서비스 중단 없이 패치 작업을 진행할 수 있다.

VMware vShield Zone

vShield Zone은 소프트웨어 방식으로 구현되는 방화벽 프로그램이며, vCenter 서버와 연계하여 작동된다. vShiled zone은 OVF 파일 형식의 가상 어플라이언스 프로그램으로 배포가 되며, 사용자는 이 프로그램을 다운로드하여 일종의 가상 머신으로 설치를 하여 운영하게 된다. 운영자는 vShield Zone Manager를 통해 보호된 영역을 지정하고 그 영역에 포함되는 가상 머신들의 모든 네트워크 트래픽들은 vShield Zone에 의해 보호받게 된다. 소프트웨어 방식으로 구현되는 방화벽 장치라고 이해하는 편이 빠를 듯하다.

VMware VMsafe

악성코드(malicious)와 같은 프로그램들이 가상 머신에 침투하는 것을 하이퍼바이저 수준에서 원천봉쇄하자는 취지에서 개발된 일종의 API이며, VMsafe API를 이용하여 각 안티 백신 프로그램회사에서 가상 머신과 같은 어플라이언스 프로그램으로 제작하여 배포하게 된다. 사용자들이 그러한 가상 머신을 구매하여 웹을 통해 다운로드하여 ESX 서버 위에 설치하여 작동시킬 경우 일종의 백신 프로그램처럼 작동하면서 악성코드 등과 같은 바이러스 프로그램을 필터링해 주는 기능이다.

VMware Host Profile

여러분이 관리해야 하는 ESX 호스트가 한 두 대 정도라면 ESX 서버 운영체제를 설치하고 각종 설정 및 구성 작업을 완료하는 데 소요되는 시간은 얼마 걸리지 않을 것이다. 그런데 여러분이 설치해야 하고 구성작업을 해야 하는 ESX 서버가 10, 20대를 넘어간다면 이야기가 달라진다. NTP 서버의 IP 주소가 바뀌었거나, DNS IP 주소를 변경해야 하거나, 가상 스위치 보안 설정과 관련된 변경사항들을 똑같이 수십 대의 서버에 모두 적용해야 한다면 호스트 프로파일은 이러한 불편한 점을 해결해 줄 수 있다. 한 대의 ESX 호스트를 일종의 마스터 서버로 지정하여 마스터 호스트 서버의 구성 변경을 적용하게 되면, 다른 나머지 ESX 호스트들에게도 마스터 서버에서 변경된 구성 내용을 똑같이 적용시켜 주는 기능이다.

VMware의 기능 소개(VMotion, Storage VMotion, DRS, DPM)-①

OSMU-PIPELINE — Sat, 1 Oct 2022 22:54:59 +0900

VMware VMotion

VMware제품을 이용함에 있어 가장 많이 궁금해하고 또 가장 많이 직/간접적으로 접해본 기능이 바로 VMotion일 것이다.

VMotion은 VMware가 정식 등록한 트레이드 마크이며, ESX 서버 위에서 작동 중인 가상 머신을 무중단 상태로 Power OFF 하거나 Shutdown 하지 않은 채 다른 ESX 서버로 이동시키는 기술이다.

굳이 가상화 운영체제가 설치된 시스템을 예로 들 필요도 없다. 현재 일반적인 IT 관리자들이 운영하고 있는 서버 시스템들의 중요한 하드웨어 변경 작업을 실시해야 하는 경우를 예로 들어볼 수 있다.

CPU나 메모리를 추가하거나 시스템 메인보드를 교체해야 하는 상황 또는 중요한 하드웨어 펌웨어 업데이트를 적용해야 할 경우, IT 관리자들은 야간이나 새벽과 같이 일반 사용자들 이거의 접속하지 않는 시간에 이러한 변경 작업을 실시하는 것이 태반이다.

현실이 이러한데 여기에 ESX 서버 운영체제를 설치한 물리적인 시스템 위에 가상 머신이 여러 개 생성되어 동작하고 있는 상황에서 하드웨어 변경 작업을 해야 한다고 가정해 보자.

가상화 환경 이전과 비교하면, 변경 작업을 해야 하는 물리적인 시스템은 같겠지만, 중단되어야 하는 서비스는 오히려 가상 머신의 개수만큼 더 많기 때문에 서비스 가용성 측면에서 가상화는 단점일 수밖에 없다.

그러나, 이러한 단점들은 VMotion이라는 기술로 완벽하게 대체될 수 있다. 이제 IT 관리자들은 VMotion을 이용하여 운영 중인 가상 머신들을 실시간으로 서비스 중단 없이 다른 ESX 호스트로 이동시키고 하드웨어 변경 작업을 완료한 다음, VMotion을 통해 이동시켰던 가상 머신들을 다시 원래의 위치로 옮겨 놓으면 끝이다. 많은 사람들이 이러한 VMotion 기술에 감탄하기도 하고 또 실제 운영 효율성에 많은 의구심을 가지고 있는 것도 사실이다.

이 VMotion 기능이 단순히 비즈니스 영속성이라는 카테고리에만 속하는 기능으로 치부될지는 모르겠으나, 이 기술이 VMware가 꿈꾸는 미래의 데이터센터, 더 나아가서 클라우드 컴퓨팅 세상을 구현하기 위해 반드시 필요한 초석이 된다는 점을 이해할 필요가 있다.

VMware Storage VMotion

낡은 스토리지 장비를 교체하기 위해 겨우 어렵게 예산을 확보하여 훨씬 뛰어난 성능과 거대한 용량을 자랑하는 스토리지 장비를 구매하였지만, 이제 진짜 고생이 시작된다. 데이터 마이그레이션(Data Migration)은 누가, 언제까지, 어떻게, 얼마나 할 것인가? 게다가 끝도 예측할 수 없는 데이터 이동 때문에 서비스 다운타임은 언제까지 가져가야 할지 IT 관리자들은 고민의 연속이다.

Storage VMotion은 서비스 다운타임 없이 가상 머신을 power off 하거나 shutdown 하지 않은 채 기존 스토리지 장비에서 신규 스토리지 장비로 데이터를 이동해 주는 기술이다.

예를 들어, 용량 확장도 더 이상 불가능하며 성능도 뒤떨어지는 낡은 스토리지 장치에 VMFS 볼륨을 생성하여 그 위에 가상 머신의 가상 디스크를 생성하여 운영한다고 하자.

이때 새로운 신규 스토리지 장치를 구매하여 모든 가상 머신의 가상 디스크를 이동시키고자 할 경우 스토리지 VMotion 기능을 이용하게 되면 서비스 다운타임 없이 실시간으로 구기종의 스토리지 장치에 있는 가상 머신의 가상 디스크들을 신규 스토리지 장치로 이동시켜 준다.

VMware DRS

<DRS>

DRS(Distributed Resource Scheduler), 즉 분산 리소스 스케줄러 기능은 일종의 자동화된 VMotion 기능이라 할 수 있다. DRS를 작동시키기 위해서는 DRS 클러스터를 구성하여야 한다. DRS 클러스터 군에 포함된 ESX 호스트들은 vCenter 서버에 의해 모든 리소스 사용률이 모니터링된다. 전체 호스트들의 리소스 사용이 불균형적일 경우, 즉 어느 특정 ESX 호스트의 리소스 사용률이 과도하게 집중될 경우 DRS서비스에 의해 리소스 사용률이 과도하게 집중된 ESX 호스트들의 가상 머신들이 자동적으로 리소스 가용이 좀 더 여유로운 다른 ESX 호스트들로 실시간으로 이동(VMotion 기능에 의해)되어 전체 DRS 클러스터의 리소스 사용률이 균형을 갖출 수 있게 된다.

물론 이러한 DRS 기능은 자동, 반자동, 수동의 세 가지 형태의 정책을 통해 가상 머신의 이동과 배치를 어떻게 설정하고 관리할 것인지에 대해 관리자가 결정할 수 있다.

VMware DPM

<DPM>

주간 오전 9시부터 오후 6시까지 쉴 새 없이 사내 시스템이 작동 중이지만, 모든 직원이 퇴근한 이후 또는 새벽 2시 이후 현저히 사용률이 떨어지는 서비스를 위해 어쩔 수 없이 서버를 운영함으로써 발생하는 운영 비용 낭비를 줄여 줄 수 있는 기술이다. DPM(Distributed Power Management), 즉 분산 전원 관리 기능을 설정하게 되면 DRS 클러스터 내의 모든 ESX호스트들의 리소스 사용률과 전력 사용량은 DPM 기능에 의해 모니터링된다. 리소스 사용량이 적을 경우, DPM은 스스로 ESX 호스트 내에서 작동 중인 가상 머신들을 최소 가용한 ESX 호스트로 VMotion을 이용하여 전부 이동시키고 남은 ESX 호스트들의 전원을 대기 상태로 전환시켜 준다.

또한, 다시 리소스 사용량이 증가할 경우 DPM은 Wake-on LAN이나 또는 HP Proliant 서버의 iLO 포트 기능을 통해 서버를 다시 Power on 시키고 DRS에 의해 VM들은 적절하게 분산되어 클러스터 내의 전체 성능이 균형을 갖추게 된다.