아키텍트2009. 11. 27. 16:53

마이크로소프트 플랫폼에 대해 알고 싶으세요? 영문자료가 아닌 한글화된 자료를 찾고 계십니까? Wikipedia에 가서 찾아봐도 영문자료만 가득하고, 정작 원하는 내용은 구하기 어려우셨죠?

마이크로소프트의 플랫폼 전략가, 아키텍트 들이 모여서 “아키텍처 저널”을 만들었습니다.

www.architecturejournal.org/wiki

위 링크를 클릭하시면 Windows Azure Platform에 관련된 자료를 보실 수 있습니다. Wiki 사이트라 조금씩 내용이 충실해지고 있습니다. 가끔 찾아와 주셔도 좋을 것 같습니다.

아, 저도 당연히 저자 중의 한 명 입니다.

Posted by 조이트리
아키텍트2008. 12. 30. 10:57

MS 신현석 부장, "WOA + 클라우드 컴퓨팅 → IT 환경 최적화"

한국MS 개발자 및 플랫폼사업총괄 신현석 부장

삼성SDS 정보통신본부 유니텔사업부 빌링시스템개발팀(시스템 개발자), 삼성네트웍스 솔루션사업부 프로젝트 리더 및 프로젝트 매니저, 삼성네트웍스 그룹1사업부 전자그룹사업1팀 기술영업, 2006년 MS 아시아태평양 웹 플랫폼 아키텍트 리드, 2007년 6월~현재 한국마이크로소프트 개발자 및 플랫폼 사업총괄

클라우드 컴퓨팅의 등장으로 웹 지향 아키텍처(WOA)가 더욱 중요해지고 있다. 예를 들면 세계인이 많이 사용하는 사진 공유 사이트인 플리커(Flickr)와 같은 사이트를 국내 개발자가 개발하고 싶다면 어떤 장애 요인이 있을까. 전 세계인을 상대로 한 사진 공유 사이트를 개발하고자 하면 수억 명의 사용자를 대상으로 서비스하기 위해 엄청난 양의 네트워크 장비와 웹서버, 데이터베이스 서버, 스토리지를 구매 및 설치, 운영해야 한다. 즉 매출 및 수익이 발생하기도 전에 초기 투자 비용이 엄청나게 투입돼야 한다는 것이다. 아이디어가 빛을 볼 가능성이 굉장히 적다.

http://www.ittoday.co.kr/home/post/post_view.jsp?dseq_no=4711&menuId=AAAI&cateCode=AAAI 
(기사 전문)

Posted by 조이트리
아키텍트2008. 10. 24. 10:28
블로터닷넷 도안구 기자님이 아래와 같이 써 주셨습니다.

http://bloter.net/archives/7561

mmshsshin신현석 한국마이크로소프트 개발자와 플랫폼 사업총괄 부장은 “아마존의 아마존 웹서비스(Amazon Web Service)가 대표적이며 마이크로소프트의 버추얼어스를 부동산 정보와 결합해 제공하는 메시업, 다음커뮤니케이션과 NHN이 진행하고 있는 메시업, 오픈마루의 다양한 서비스 시도들이 WOA의 초기 모델이라고 볼 수 있습니다”라고 밝혔다.

야후의 교통정보라는 서비스를 마이크로소프트의 버추얼어스나 구글어스와 결합하거나 부동산 전문 업체들이 전세계 지도 서비스 업체들의 인프라를 활용해 3차원적인 정보 서비스를 별도로 만들어 내면서 이전과는 전혀 다른 서비스들이 속속 출현하고 있다. 이런 서비스를 제공하기 위해 자사의 서비스 아키텍처를 좀더 유연하게 만들어 내는 것이 WOA이다.

그렇다면 왜 WOA가 주목을 받을까?

신현석 부장은 “웹이 하나의 플랫폼이 됐기 때문입니다”라고 설명한다. 수 많은 웹 서비스 업체들은 자신들의 서비스를 네티즌들에게 제공하고 있지만 이와는 별개로 수많은 개발자들이 웹서비스 업체의 인프라를 활용해 또 다른 서비스를 만들어 낼 수 있도록 돕고 있다. 이런 서비스 인프라를 만들어 제공하지 않으면 경쟁 업체들이 선점하면서 생태계를 이끌어가기 때문에 웹서비스 업체들이 주목을 하고 있다.

그렇다고 해서 웹서비스 업체들만 관심을 가지는 것은 아니다. 일반 기업들도 인터넷뱅킹 서비스와 같은 다양한 인터넷 서비스를 제공하고 있는데 이런 사이트 구축을 할 때 WOA 형태로 진행할 수 있다. 다만 그동안 기업 내부적으로 SOA의 표준들이 다양하게 사용돼 왔기 때문에 웹 서비스 분야에서도 SOA 표준 중 하나인 SOAP를 사용할지 아니면 WOA의 REST를 사용할지의 선택을 해야 한다. 일장일단이 있기 때문에 어떤 아키텍처로 가져갈지에 대한 다각도의 검토 작업이 필수적이다.

공공 기관들의 경우, 통계정보나 지리정보, 기상정보 등 원천 데이터들을 보유하고 있고, 지속적으로 이를 담는 그릇을 서비스 형태로 만들어가기 위해 노력하고 있는만큼 WOA를 검토할 필요성은 기업이나 웹서비스 업체에 뒤쳐지지 않을 것으로 보인다.

신현석 부장은 “WOA가 SOA를 모두 대체할 수 있다고 보지는 않습니다. 어떤 서비스를 제공하기 위해 최적의 아키텍처는 무엇인지 검토가 필요한 상황이죠”라고 전하고 “SOA가 소개된지 오래됐지만 꾸준히 변화하고 있듯이 이제 막 소개되고 있는 WOA도 적용 가능한 분야를 찾아 진화, 진보해 나갈 것으로 봅니다”라고 밝혔다.

Posted by 조이트리
아키텍트2008. 10. 14. 11:35

ADS의 목적은 잠재적인 솔루션을 승인할 "Power Sponsor"를 확보하는 것 입니다.
 - 기본적인 샘플 아키텍처 청사진을 이용합니다. 이해 당사자들이 해당 솔루션을 이해하도록 하는 것이 가장 중요하고, 잠재적인 가치에 대해 정보를 제공해야 합니다.

. PT 형태일 필요는 없습니다. 보드에 그림을 그리거나, 대화를 통해 진행하는 것이 바람직한 경우도 많습니다.
. 솔루션 아키텍처 디자인을 개략적으로 그린 후 승인을 받습니다.
. POC까지 필요없다고 판단된다면, 의사결정을 이 단계에 받아 냅니다.
  - 가능하면 Deal을 Close 하는 것이 좋습니다.
     즉, 고객으로 High Level 테크니컬 디자인에 대한 승인을 받아내는 것이 목적 입니다. 
. 실제 구현을 위한 아키텍처가 아닙니다. 이 부분은 프로젝트팀 및 컨설턴트가 투입되어 진행합니다.
. 5-7명 정도를 대상으로 긴밀하게 진행하는 것이 효과적 입니다.
. Project Framework (Microsoft Project Framework)을 활용할 수 있습니다.
. 진행 중에는 자주 Summarize 가 필요합니다.
. 목적에 대해 종종 확인합니다.
. 요구사항과 실제 프로덕트 및 솔루션과 매핑하여 구현 가능함을 중간 중간 확인합니다.

산출물
 - 비전 및 범위 도큐먼트
 - 솔루션 아키텍처

이후의 글에서 MDOP(Microsoft Desktop Optimization Pack)에 대한 ADS 및 아키텍처 등을 적어 보겠습니다.
Posted by 조이트리
아키텍트2008. 9. 8. 16:47

과거에는 데이터센터 디자인을 할 때 물리적인 공간 비용, 즉 상면 비용이 핵심 고려사항 이었습니다. 하지만, 최근에는 전력 및 쿨링 비용의 급격한 상승으로 전력 및 쿨링의 효과적인 설계가 총 TCO를 줄일 가장 중요한 요인이라는 것이 밝혀졌죠.


※ 위의 그림에서 보듯 서버 숫자는 많이 늘었지만, 전체적인 전원 소비량은 그만큼 증가하지 않았음을 보실 수 있습니다.

비용 및 에너지 효율이 고려된 데이터센터 설계

마이크로소프트는 데이터센터를 24시간 구동되는 하나의 대형 컴퓨터로 보고 설계합니다. 컴퓨터는 사용자의 특정 목적에 맞게 설정되고 사용될 때 가장 잘 동작하는데, 똑같은 규칙이 데이터센터에도 그대로 적용됩니다. 데이터센터 사용자 및 특정 사이트의 조건에 가장 부합하는 리소스 효율적인 디자인이 요구되는 것인데, 마이크로소프트는 전력 배분, 쿨링 시스템, 서버 및 Rack/ 컨테이너 시스템 등 다양한 기술에 대해 분석 및 연구하고 있습니다.

여러 요소를 분석 및 평가하여 최적의 디자인 도출

최적의 환경을 만들기 위해 디자이너는 모든 비용 요소를 고려해야 합니다.
: 빌딩, 토지, 전력 장치, 쿨링 장치, 전기, 물, 네트웍 및 엔지니어 등

마이크로소프트는 데이터센터의 장소를 선정하기 위한 히트맵을 이용하기 위해 소프트웨어 를 사용합니다. 장소가 선택되면 시설의 전체 라이프사이클 동안의 총 소유비용을 낮추기 위한 빌딩 및 장치의 디자인에 대한 평가를 시작하죠. 조직의 여러 팀간에 Ownership을 분산시키기 보다는 장소 선택, 빌딩 디자인 및 운영에 대해서 하나의 단일 조직이 맡도록 합니다. 데이터 센터 및 TCO 절감에 대한 단일 책임을 부여하기 위해서 그렇습니다.

최대의 효율 및 성능을 위해 프로비저닝 최적화

잘 아시는 것처럼 대부분의 데이터센터는 처음 구축된 후 수년간 부분 가동됩니다. 데이터센터의 필요한 부분만 가동하는 것이 가능하다는 말이죠. 하지만, 정말 그렇게 되나요? Rack이 하나만 있어도 전체 데이터센터의 Cooling 시스템을 가동하고 있지는 않으신가요? 바로 이부분이 대부분의 데이터센터가 놓치고 있다고 생각합니다. 마이크로소프트는 데이터센터의 일부분만 가동이 가능하도록 데이터센터 인프라 설계를 모듈화 시켜 놨습니다. 아주 조금밖에 필요하지 않은데 100%의 인프라스트럭처를 모두 구동해야 한다면 비효율 적이겠죠?

또 다른 기술은 사용될 수 있는 지점의 전력을 다른 곳으로 보낼 수 있도록 전력 및 클링 시스템을 디자인한 것입니다. 고착된 전력은 사용되지 않고 낭비되어 결국 수십억원에 해당되는 비용이 사용되지 못하고 낭비되는 요인이 됩니다. 예를들면, 센터의 한 지점에서 특정양의 전력을 받아이도록 장치가 설치되어 있는데 그 장치가 해당 용량을 사용하지 않는 다면, 바로 이곳에서는 전기를 사용하지 않았지만, 다른 장치에서는 전기가 부족한 일이 벌어질 수 있다는 것입니다.

전기가 필요한 곳에서 사용할 수 있도록 하기 위해 마이크로소프트는 전력 및 쿨링 시스템에 재 설정되어 전력을 공유할 수 있는 유연한 디자인을 채택했습니다. 또 다른 방법은 가장 전기 및 전력 효율적인 곳에 하드웨어를 위치 시키는 것이죠. 때때로, 가장 이상적인 위치에 특정 장치를 위치하는 것이 불가능한 경우가 있지만 가능한 경우라면 물리적인 장벽을 제거하도록 설계되어 있습니다. 마이크로소프트의 비즈니스 유닛은 차지하고 있는 공간, 즉 상면 비용이 아니라 에너지(전기) 및 쿨링 비용을 포함한 운영 비용으로 과금을 합니다.

데이터 센터의 성능을 모니터링 및 제어

효율성을 높이기 위해 성능, 온도, 전력 사용량을 볼 수 있는 모니터링 시스템을 개발할 필요가 있습니다. 데이터센터 전체의 실시간 서버 온도, 쿨링 시스템의 정상 작동여부를 실시간으로 측정하는 것은 아주 중요합니다. 과도한 쿨링시스템 작동은 여러 데이터센터에서 에너지 낭비의 주요 원인입니다. 마이크로소프트는 쿨링 낭비를 줄이기 위해 아주 긴밀한 통제를 유지합니다. 게다가 데이터의 아카이브를 통해 운영 성능을 어떻게 향상 시킬것인지 포괄적인 이해를 할 수 있게 됩니다.

데이터센터 운영 Excellence를 조직 문화의 일부로 만듦

에너지 효율화 노력의 첫걸음은 Awareness(인지도)를 높이는 것이고, 모니터링, 리포팅, 데이터센터 효율화를 분석하는 것 등에 대한 책임감을 해당 팀에 부여하는 것입니다. 마이크로소프트는 데이터센터 지표를 만들어서 웹서비스를 통해 운영에 대한 값을 관련 주체들과 커뮤니케이션 하도록 되어 있습니다. 해당 의사결정권자들에게 보내져 향상 및 변화값등에 대해 공개되지 않게 에너지 효율화 및 데이터센터 성능 정보를 보내고 있습니다. 

Power Usage Effectiveness(PUE)를 측정

Power usage effectiveness (PUE)는 데이터센터 효율성을 향상하기 위해 사용되는 마이크로소프트의 지표 입니다. PUE는 외부 온도, 장비 변경, 서버의 부하 등의 값에 따라 지속적으로 변하는 값입니다. 모니터링 및 계측/관리가 없다면 PUE 값 변동에 대한 원인 및 효과를 판단하는 것이 불가능 합니다. PUE는 데이터센터 운영자가 다른 데이터센의 값과 비교하여 에너지 효율화를 위해 취해야 할 필요가 있는 것을 결정하여 빠르게 데이터센터의 효율성을 평가할 수 있도록 해줍니다.

온도 조절 및 공기흐름 분배를 위핸 최고의 기술 사용

온도 조절 및 공기흐름 분배를 향상시키기 위한 기술 목록

  • AC(교류) units을 뜨거운 통로에 연결하여 뜨거운 공기는뜨거운 통로로 흐르게 함
  • 0.8 ~ 1.0 미터 마루 위에 Uniform Static 공기 압력으로 디자인

뜨거운 공기와 찬 공기가 혼합되는 것 방지

뜨거운 공기와 찬 공기가 혼합되는 것은 비효율적입니다. 이런 비효율을 방지하면 쿨링 비용을 절감할 수 있게 되죠. 뜨거운 공기와 찬 공기의 혼합을 막는 기술로 구현 가능합니다.

  • 뜨거운 공기 및 찬 공기가 흐르는 통로를 각각 만듦

효과적인 절약 장치(Economizer) 사용

데이터센터의 장소 선정에 고려할 또 하나의 요소는 데이터센터를 쿨링, 즉 식히는데 절약 장치를 사용할 수 있는지 여부 입니다. 첫째는 물을 사용하는 방식, 둘째는 외부 공기를 사용하는 방식 입니다. 마이크로소프트는 2가지 방식 모두를 사용하고 있습니다.

산업계의 파트너들과 지식 공유 및 배움

마이크로소프트는 베스트프랙시트에 참여하고, 공유하고 있습니다.

  • The Green Grid
  • Climate Savers Computing
  • Environmental Protection Agency
  • Lawrence Berkeley National Labs
  • Society of Heating, Refrigeration, and Air-Conditioning Engineers
  • Association for Computer Operations Management.

위의 다양한 단체들은 산업계의 업체들이 지식을 공유하도록 촉진하고 있고, 다양한 데이터센터의 전략 및 베스트 프랙티스를 서로 교환하며 정보를 제공하고 있습니다.

에너지 효율적인 데이터센터 라이프 사이클로의 길

마이크로소프트는 산업계의 경험 및 많은 지식을 소유한 많은 분들을 통해 지식을 축적했고 이런 지식을 공유하는 것이 많은 분들에게 시간과 노력을 절감시킬 수 있다고 믿습니다.

마이크로소프트는 컴퓨터 사용자가 소프트웨어의 다양한 활용을 통해 환경을 향상시키기 위해 향상된 교육 및 가이드가 필요하다는 것을 알고 있습니다. 따라서, 정부 기관, 비 정부기관, 산업계 및 소비자등 환경에 직접, 간접으로 영향을 주는 모든 분들에게 베스트 프랙티스를 공유하는 노력을 지속하고 있습니다. 많이 활용하시기 바랍니

Posted by 조이트리
아키텍트2008. 7. 16. 11:39

클라우드 컴퓨팅에 대한 글, 기사는 계속 쏟아져 나오고 있습니다. 사용하는 용어도 참 다양하지요. 클라우드컴퓨팅, 유틸리티컴퓨팅, PaaS(Platform as a Service) 등의 용어가 주로 나오지요.
"마이크로소프트의 Gianpaolo의 블로그에서 가져왔습니다."

그런데 "클라우드 컴퓨팅"이 사용될 때 아키텍처 측면에서는 어떤 변화가 있을까요?

1. "직접 해라" vs "서비스로 쓰자"
 - "직접 해라"의 경우는 컨트롤을 할 수 있지만, 반면에 규모의 경제 효과는 볼 수 없겠지요. 모든 비용을 혼자 지 불해야 합니다.
 - "서비스로 쓰자"의 경우는 규모의 경제는 확실히 얻을 수 있지만, 직접 제어할 수는 없는 거죠

즉, "제어"와 "규모의 경제" 사이의 Trade Off이 있다는 거죠

blog1

2. "누가 구축할거냐"와 "누구의 장비에서 운영할 거냐"
 - "누가 구축할거냐" (직접 개발하는 방식 vs 구입); 기능의 컨트롤에 영향을 미치는 거죠. 직접 구축한다면
    기능을 넣고 빼는 것을 맘대로 할 수 있지만, 서비스 제공자로 부터 소프트웨어를 획득하는 거라면 제공자가
    부여하는 것밖에 사용 못하겠지요.
 - "누구의 장비에서 운영할 거냐"; SLA의 컨트롤에 영향을 미칩니다. "On Premise" 방식으로 직접 설치하고
    운영한다면 SLA에 대한 모든 제어가 가능하겠지요. 물론 SLA에 대한 제어가 가능하다고해서 높은 SLA를
    제공한다거나, 클라우드 방식보다 더 잘한다는 보장은 없지만요. ^^ 결국 SLA에 대한 조절은 가능하다는
    것이고, 클라우드 방식을 사용한다면 SLA를 서비스 제공자가 주는대로 사용해야 겠지요.

blog2

3. 가능성 맵 (map of possibilities)
위의 2가지 요소가 왜 중요할까요? 이 두가지의 요소를 통해 엔터프라이즈가 IT 자산을 사용할 수 있는 가능성 맵을 만들어볼 수 있기 때문이지요.
엔터프라이즈는 위의 2가지 요소에 비추어 "기능의 컨트롤", "SLA 컨트롤"을 규모의 경제를 활용하면서 얻기를 원하고 있다는 거죠. 맵 상의 하나의 선택이 다른 것보다 더 좋다는 것을 의미하는 것은 아니고 비즈니스 상황 및 규제 등에 따라 다르게 선택될 수 있는 것입니다.

아래의 그림을 통해 IT 자산의 몇 가지 유형을 볼 수 있습니다. 맨 왼쪽 위에 보면 '직접 설치된 패키지 소프트웨어'를 볼 수 있는데 직접 설치하고, SLA에 대한 모든 제어가 가능하지만 기능에 대해서는 제한적으로 선택이 가능하고, 규모의 경제를 통해 아쉬움을 달래는 것이죠. 소프트웨어 벤더의 경우 수백, 수천의 고객에게 패키지를 판매함을 통해 직접 고객이 개발하는 것보다 더 저렴한 금액으로 소프트웨어를 공급하게 됩니다. 맨 아래의 왼쪽 영역이 "직접 개발하고 직접 운영하는 소프트웨어" 영역 인데, 뱅킹 시스템을 예로 들어보지요. 제어권 및 기능을 모두 가지고 있지만 규모의 경제는 실현 못하죠. 개발 및 운영에 대한 모든 비용을 혼자 감당합니다 오른쪽 맨 위 영역이 바로 'SaaS' 입니다. 규모의 경제 효과가 높지만 기능 및 SLA에 대해서는 한계가 존재하는 거죠. 중간의 칼럼 (호스팅과 클라우드 컴퓨팅)은 직접 구축 및 운영에 비해 SLA 제어에 대해서는 제어권이 약화되지만 규모의 경제 효과는 증가되는 것을 볼 수 있죠.

blog3a
4. 가상의 시나리오
이 시나리오 에서는 몇 개의 IT 자산은 원하는 독자적인 시스템을 직접 구축 하고 몇 개는 시장에서 통용되는 되는 방식을 그대로 사용하는 것입니다. 다시 말하면, 차별화가 필요한 자산은 집중적인 투자를 하고 (의료 진단 소프트웨어 등), 아주 일반적인, 즉 차별화 되지 않는 자산 (CRM, 이메일 등)은 시장에서 구입하여 사용하는 것이죠. 게다가 IT 자산은 직접 운영하고 보유하여, IT 환경에 대한 SLA를 직접 통제하는 방식을 의미합니다.

blog3b

이런 형태의 그림이 아주 일반적이지요. 하지만 대부분의 CIO 분들은 이런 형태가 이상적이지만, 너무 많은 예산이 차별화 되지 않는 솔루션에 사용된다고 이야기 합니다.
결국 바라는 모습은 이런 겁니다.

blog4
이메일과 CRM은 차별화 되기 쉽지 않고, 규모의 경제를 보장 받으면서 SLA와 기능에 대해 Trade Off하는 거죠. 직접 개발된 리거시 HR 시스템의 경우 기능면에서 규모의 경제를 보장 받는 형태로 전환되면서 SLA에 대한 보장 및 데이터 보안이 필요하다면 내부에서 운영되도록 할 수 있습니다. 의료 진단 소프트웨어의 경우는 차별화되어 경쟁력을 보유할 필요가 있으므로 기존 보다 2배 정도의 예산을 투자하여 뛰어나게 개발하는 겁니다. (다른 쪽에서 비용을 절감했기에 여기에 더 많은 예산을 쓸 수 있다는 거죠)

목적은 분명합니다. 컨트롤을 유지하면서 규모의 경제를 보장 받는 형태로 자산을 배치시키는 방향을 취하면 됩니다.

케즘을 넘어서 ...
blog5

말이 쉽지 사실 직접 행동하는 건 쉽지 않죠.
Geoffrey A. Moore의 책에서 나온 말을 인용해보죠. 소프트웨어를 넘어서 클라우드로는 "케즘을 넘어서..."와 비슷합니다. 이 케즘은 아키텍트가 마스터해서 넘겨야 하는 거죠. 아키텍처가 당면한 도전과제는 다양합니다.

첫째, 아이덴티티
둘째, 관리
셋째, 데이터 입니다.

아이덴티티의 경우 크로스 바운더리상의 인증과 권한, 싱글 사인 온, 아이덴티티 라이프 사이클 등이며 관리는 방화벽을 넘어서 SLA 모니터링과 소프트웨어 액션 트리거링 (Halting, Pausing, Throttling) 할 것인지에 대한 것과 데이터의 소유권, 데이터의 이전 및 리포팅과 프라이버시 등입니다.

클라우드 컴퓨팅에 대해서 모든 답을 다 가지고 있는 사람은 없을 것입니다. 여러가지 방향으로 좋은 아키텍트 및 해결책을 찾으려고 노력하고 있다는 것이 적절한 표현일 것입니다. 앞으로는 위에 언급한 3가지 도전과제에 대해 좀 더 상세히 다루어 보려고 합니다. 그리고, 마이크로소프트가 공개한 S+S 어플리케이션 LitwareHR2에 대한 아키텍처 및 코드에 대한 부분을 다음 글에 다루어 보도록 하겠습니다.

"마이크로소프트 Gianpaolo의 블로그에서 가져왔습니다."

Posted by 조이트리
아키텍트2008. 5. 29. 18:57
 
사용자 삽입 이미지

그림 1. Mapping of technology into Core Infrastructure Model


마이크로소프트의 Core IO(Infrastructure Optimization) 모델에 대해 들어보셨나요? 프로세스와 기술을 종합해서 한 조직의 성숙도를 판단하는 방식을 의미합니다. (IO 모델)

IO 모델은 IT 산업의 애널리스트들, MIT의 정보시스템 연구센터, 마이크로소프트의 엔터프라이즈 고객과의 경험을 토대로 만들어졌습니다. IO 모델의 목적은 한 조직의 기술력, 비즈니스 가치를 평가할 수 있는 유연하고 쉬운 성숙도 프레임웍을 제공하는 것입니다. IO 모델은 3가지로 구성되어 있습니다. Core IO, Application Platform Optimization, Business Productivity IO 입니다. Core IO에 의하면, 한 조직이 지속적인 서버 통합을 통해 가상화 기술을 사용한 경우 Rationalized 단계에 도달했다고 평가합니다.

다음 글에서는 가상화를 위한 인프라스트럭처를 설계하고 디자인 하는 방법에 대해 적어보겠습니다.
Posted by 조이트리
IT Pro2008. 5. 29. 13:59

자, 이제 의사결정의 각 단계에 대해 상세하게 살펴보겠습니다.

1단계. 가상화가 적합한지 결정
   - 특정 상황에서 가상화를 사용해야할 지 고려 요소
      . 호환성: 어플리케이션이 가상화 환경에서 구동되는지 확인
      . 지원 가능 여부: 해당 어플리케이션 개발 업체가 가상화 환경을 지원하는 지 정책 확인 필요
      . 라이선싱: 어플리케이션이 가상화 환경에서 사용 가능하도록 라이선스 정책이 지원 가능한지 여부
      . 비즈니스 이점: 해당 어플리케이션을 가상화 해야하는 비즈니스 상의 이유 고려, 비용 절감, 배포시간 단축,
        운영 비용 절감 등의 잠재적 이익 등도 함께 고려

   만약 가상화가 적합하다고 판단되면 2단계로 이동

2단계. 어플리케이션 분류
   - 서버에서 구동되는 어플리케이션인지, 클라이언트 PC용 어플리케이션인지 구분
      . Windows Server에서 구동되는 어플리케이션이라면 3단계로 이동
      . 클라이언트 PC에서 구동되는 어플리케이션이라면 4단계로 이동

3단계. 서버 하드웨어 가상화 vs 서버 소프트웨어 가상화 선택
   - 기술적인 환경에 따라 선택이 가능함

표 2. Comparing Windows Server Hyper-V Products

Criteria

Windows Server 2008 Hyper-V

Virtual Server 2005 R2 SP1

32-bit host

 

ü

64-bit host

ü

ü

Multiple CPU support for guest OS

ü

 

Enhanced management tools

ü

 

Type 1 Hypervisor

(server hardware virtualization)

ü

 

Server software virtualization

 

ü


Hyper-V는 Intel VT, AMD-V CPU가 장착된 하드웨어 필요함

4단계. 클라이언트 연결 결정
 - 컴퓨터가 항상 네트웍에 연결되어 있는 상태인지, 때때로 연결이 끊어지는 상태인지에 따라 달라짐
   1) 항상 연결되어 있는 클라이언트
       전형적인 시나리오는 기업에서 사용되는 PC, 키오스크, 리모트 오피스, 홈 오피스 용도로 사용되는 컴퓨터
       의 경우이다.
       항상 연결되어 있다면, "어플리케이션의 위치를 결정"하는 5단계로 이동

    2) 연결이 끊어진 클라이언트
       때때로 네트웍이 끊어지는 클라이언트, 또 어플리케이션의 여러 버전을 동시에 사용할 필요가 있을 경우
       이다. 출장중이거나, 네트웍 연결이 되지 않는 동안 잠깐 사용하고자하는 용도에 가장 적합하다
       "어플리케이션 가아화, 데스크탑 가상화"를 선택하는 7단계로 이동

5단계. 어플리케이션 위치 결정
  1) 어플리케이션이 중앙에서 관리될 수 있고, 서버에서 운영하는 것이 효율적이라고 판단되면
     프리젠테이션 가상화 고려. 어플리케이션의 배포나 관리가 엄청 용이함
       6단계로 이동
   2) 중앙 서버에서 구동되기 어려운 상황이거나, 개별적인 설정이 필요할 때, 효율적으로 구동
       되기 위해 로컬 시스템 자원을 사용해야 할 때 등은 데스크탑 가상화를 고려함이 좋음
       7단계로 이동

6단계. 데스크탑 or 프리젠테이션 가상화 선택
    중앙에서 관리하는 것은 결정이 됨
   1)  데스크탑 가상화
        . VECD(Vista Enterprise Centralized Desktop)이 선택될 수 있음. 이 경우에는 클라이언트
           컴퓨터에 디스크가 없어도 되고, 데이터나 어플리케이션은 로컬에 저장되지 않음.
           클라이언트 컴퓨터가 안정적인 네트웍 커넥션을 가지고 있고, 리모트 데스크탑 프로토콜(RDP)를
           사용하여 가상머신에 접근하도록만 설정되면 됨. 가상화를 위해 클라이언트 이미지는 Virtual Server
           2005 R2 SP1이 가상 머신을 호스팅하면 되고, Windows Vista Enterprise 라이선스는 클라이언트가
           보유해야 함
    2) 프리젠테이션 가상화
        . 터미널서비스는 사용자가 RDP를 통해 원격 어플리케이션을 사용하도록 해줌. 모든 실행이 서버에서
          이루어지므로 클라이언트 컴퓨터는 최소의 하드웨어 사양을 요구함. 클라이언트 컴퓨터는 Windows XP,
          Vista 등이 사용될 수도 있고, RDP 클라이언트가 가능한 어떤 운영체제도 가능함. 만약, 호환성 이슈가
          발생한다면 소프트웨어 그리드 같은, 어플리케이션 가상화가 사용, 관리되어야 함

7단계. 어플리케이션 or 데스크탑 가상화 선택
  1) 어플리케이션 가상화
       . 가상화 환경에 어플리케이션을 설치하는 방법을 제공하고, 어플리케이션을 온디맨드로 스트리밍 형태로
          제공할 수 있음. 어플리케이션은 실제로 로컬에서 구동됨.
          어플리케이션이 실제로 로컬 컴퓨터에서 실행되므로 어플리케이션 구동을 위한 하드웨어 요구사항을
          갖춰야 하고, 가상화 어플리케이션을 지원하기 위해 완전한 클라이언트 운영체제를 필요로 함
  2) 데스크탑 가상화
       . 많은 운영체제들이 로컬 컴퓨터에서 구동되어야 하므로, 충분한 CPU, 메모리, 디스크가 필요로 함. Virtual
          PC를 사용하면 리거시 운영체제 및 어플리케이션을 함꼐 구동할 수 있음. 여러개의 가상머신을 시작하고
         멈출 수 있음. 소프트웨어 개발 및 테스트 환경에서 여러개의 플랫폼이 필요한 데, 이럴 때 유용하게 사용
         될 수 있음

여러개의 가상화 기술을 함께 사용

표 3. Additional Virtualization Characteristics

Characteristic

VECD

Terminal Services

Virtual PC

SoftGrid Application Virtualization

Supports Windows Terminal Client (thin client)

ü

ü

 

 

Desktop Virtualization (OS + applications)

ü1

 

ü

ü

 

Application virtualization

 

ü

 

ü

Centralized

ü

ü

 

 

Scalability

Low

High

 

 

Support for legacy OS

 

 

ü

 

1 = Vista Enterprise only

하나의 가상화로 원하는 모든 요구사항을 만족시키지 못할 때가 있죠. 이럴때는 여러개의 기술이 함께
사용될 수 있습니다.
 . 터미널서비스 세션은 소프트그리드 어플리케이션을 사용할 수 있음
 . Windows Vista 클라이언트가 중앙에서 구동되는 금융 어플리케이션(Financial)을 터미널 서비스로
   사용하고, 로컬에 설치된 소프트그리드 어플리케이션을 가질 수 있고, 이전 버전의 리거시 윈도우
   어플리케이션을 사용하기 위해 VIrtual PC를 사용할 수도 있는 거죠.

Posted by 조이트리
IT Pro2008. 5. 29. 11:32
내게 맞는 가상화 기술 선택하기에 대해 알려드립니다.
인프라스트럭처를 계획하고, 디자인할 때 어떤 구체적인 방법론을 사용하는 것이 아니고, 경험에 의해 이루어지는 경우가 참 많습니다. "잘되면 좋고, 안되면 다시 하지 뭐"라는 생각이 깔려 있는 것 같습니다.

좀 더 체계적으로 하면 좋겠죠. Infrastructure Planning & Design (IPD)는 그래서 생겼죠.
 . 플래닝 프로세스 동안 활용할 수 있는 의사결정 플로우를 활용할 수 있습니다.
 . 의사결정에 필요한 옵션을 제공하고, 결정된 내용에 대해 확인합니다.
 . 비용과 복잡도를 고려하여 비즈니스와 연계한 결정을 합니다
 . 비즈니스에 관계된 다양한 질문을 통해, 비즈니스에 핵심적인 내용을 포괄적으로 이해합니다.

비즈니스가 요구하는 사항을 충족하기 위해, IT가 구현을 하게 되는데 각 시나리오별로 어떤 가상화가 최적인지를 생각해보는 건 굉장히 중요합니다.

사용자 삽입 이미지
1. 서버 하드웨어 가상화
    - Hypervisor로 알려져 있습니다. 아주 가벼운 코어 OS라고 생각해도 됩니다. 가상화가 내장된 기능을 가진
      하드웨어면 됩니다.
2. 서버 소프트웨어 가상화
    - Windows Server 2003, 2008 같은 운영체제가 가상머신(VM)을 호스팅 할 수 있는 어플리케이션을 사용하여
      구현됩니다. 각 가상 머신들은 완전히 별도로 구분되어 운영체제와 어플리케이션을 운영할 수 있습니다.
3. 프리젠테이션 가상화
    - 많은 사용자 세션 유지, 모든 프로세싱이 중앙 호스트 시스템에서 이루어집니다. 사용자 세션은 각각 독립되
       어 있지요. 키보드, 마우스 입력, 비디오 정보 등만이 클라이언트와 중앙 시스템 사이에 전달됩니다.
4. 어플리케이션 가상화
    - 감싸주는 소프트웨어(Wrapper)가 어플리케이션을 격리시키는 역할을 합니다. 예를들면, 오피스 2003,
      오피스 2007을 한 대의 PC에서 모두 구동하려면 DLL(Dynamic Link Libraries) 충돌로 인해 사용하기 어렵겠
      죠. 또한, 호환성 부분에서도 문제가 생길 수 있습니다. 이런 경우 각 어플리케이션이 서로에 영향을 주지
      않도록 해주는 역할을 합니다.
5.  데스크탑 가상화
     - 서버 소프트웨어 가상화와 유사합니다. 다만, PC나 노트북에 가상화를 구현한다는 것이 다르지요.  
       Windows Vista를 사용하면서, WIndows XP에서만 구동되는 특화된 어플리케이션이 있다면 데스크탑
       가상화를 이용하여 2개의 운영체를 한대의 PC에서 사용할 수 있겠죠

각 가상화에 대한 자세한 내용은 다음 글에서 올리겠습니다.
Posted by 조이트리