조대협의 블로그

Auto Scale Out을 고민할 일이 있어서.. Amazon EC2를 봤는데.. 역시나.. EC2는 기본적으로 IaaS이기 때문에, CPU나 어느 조건 이상이 되면 Config 된데로, Scale out이 되는데, AMI 이미지 똑같은 것을 하나 더 띄우고, Load Balancer에서 연결해주는 형태.. 즉, 일반적인 웹서버나 클러스터가 안되어 있는 Tomcat등은 그럭저럭 먹힐거 같은데.. WebLogic,JBoss 등은 어렵다는 이야기, 결국 API로 WLS등 모니터링해서 Scale out할 수 있게 해주고, AMI 이미지도 Instance별로 별도 고려가 되야 하는 형태.. Scale out은 아무래도 PaaS가 유리한듯.. 그리고, DB Auto Scale out 이야기 하시는분들 있는데, ..

IaaS 구축용 - Hypervisor : XenServer, Oracle XenServer가 가격 대비 Support 가능 - Cloud Management : Cloud stack (cloud.com) - Software ISCSI : Nexentar (고속 IO에는 적합하지 않음) PaaS 구축용 - Storage : OpenStack - Column DB : Cassandra - Simple DB : MySQL or VoltDB Hadoop은 아니라고 보고

Scale out unit provisioning Bare metal provisioning Reporting Life cycle management Charge back model IO Segregation Self Service Portal Multitenancy Fabric Management Live Migration Automated Patch (Customer requirement is required. 보안 패치를 8시간 내에 모든 서버에 제공한다던지..) Resource Pool Management Asset (VLAN,IP,MAC,LUN) management Scale out unit design 가상화만 고민하는데, 대충 이넘들은 고민해야 할듯..

아키텍쳐는 간단, 결국 Workflow 설계랑 PI를 어떻게 할것인가가.. 문제. ITIL이랑 접속 시키는 것도 필요하고.~~

결국 이거지 머.. VM,Resource Pool, Fabric Management.

비용 대비해서, 클라우드의 물리 노드를 어떻게 설계할까가 고민이었는데... 오늘 이런 저런 이야기를 들어보고 사례를 보니.. 결론 은 생각보다 간단하다. 1. 블레이드 사용 공간이나, 전력면에서 블레이드가 유리하기 때문에 블레이드 사용 2. 10G NIC * 2 LAN으로 나가는 것은 10G 를 사용하되 Redundancy 구성을 위해서 2개 사용 VNIC는 관리,클러스터링,Fail Over(Live Migration),ISCSI,그리고 VM용으로 가상으로 나눠서 구성 3. FC * 2 Storage는 모라고 해도.. 결국 FC가 안정적. Redundancy 구성을 위해서 두개 사용 LAN과 SAN은 각각 2개 이상의 스위치로 이중화 비용 절감 방법은 1. Bulk Buy (Rack 단위)를 하는 방법 ..

아마존 EC2는 아마존 클라우드 서비스의 가장 대표적인 Iaas 서비스 컴포넌트이다. 아마존은 하드웨어 서버를 가상화해 그 하드웨어 자원을 사용자에게 제공하고, 사용자는 그 위에 운영체제와 소프트웨어를 설치해 클라우드 서비스를 이용한다는 개념이다. 아마존 EC2 아마존에서는 사전에 Pre configure 된 운영체제 이미지를 제공해, 사용자로 하여금 원하는 이미지와 소프트웨어를 직접 선택할 수 있게 하거나 또는 사용자가 직접 시스템에 대한 이미지를 AMI(Amazon Machine Image)라는 형태로 올려서 사용할 수 있도록 한다. 아마존에서 제공하는 Pre configure 된 이미지들은 과 같다. Database • IBM DB2 • IBM Informix Dynamic Server • Micr..

Hardware Configuration Consideration Point Private Cloud는 집적된 하드웨어 서버에 다수의 VM을 기동 시켜서 수많은 업무와 트래픽을 감당해내는 구조로 일반적인 애플리케이션 구동이나 DBMS를 위한 하드웨어 구성과는 다른 형태의 구성이 필요하다. 대용량의 IO와 대용량의 네트워크 트래픽을 지원할 수 있어야 하며, 장애에 대한 높은 대응 능력을 요구로 한다. 본 문서에서는 Private Cloud를 구축하는 데 있어서 고려 해야 하는 하드웨어에 대한 검토 사항에 대해서 설명 한다. Storage Architecture 저장소 즉, 디스크는 Private Cloud에서 호스팅 되는 VM의 성능에 가장 큰 영향을 미치는 요인중의 하나로, 드라이버의 타입, 인터페이스,..

DB를 VM에 올릴 때 첫번째로 고려할 사항은 수직적 확장성이다. 수평적인 확장성은 DBMS 자체가 제공하는 클러스터 기능을 이용해야 한다. (MS SQL의 경우 수평 확장 불가, ORACLE의 경우 RAC를 이용하여 수평확장 가능). 만약에 DBMS 자체 클러스터링에 대한 확장이 불가능하다면 애플리케이션 단에서 Database Sharding등을 이용하여 확장을 하는 안을 고려할 수 있다. 수직적 확장의 경우 현재까지 Hyper-V가 최대 CPU 4 코어까지만 지원하기 때문에, 더 이상의 용량이 필요한 경우 분리된 Physical Machine을 사용하는 방법을 사용해야 한다. DBMS를 VM에 올릴 경우 가상화에 대한 Cost로 인하여 성능이 떨어지는데, 그 중에서 성능에 가장 큰 영향을 미치는 것이..

장애 대응 단계별 하드웨어 설계 방안 클라우드를 구축하는데 비용상의 문제점은 SAN을 구축하는데 소요되는 비용이다. SAN Controller와 Switch에 많은 비용이 소요되는데, 서버별 사용 시나리오별로 SAN 사용 여부를 판단함으로써 전체 하드웨어 구축 비용을 절약할 수 있다. 소프트웨어를 이용한 장애 대응 Tuxedo와 같은 TP Monitor나 Tomcat과 같은 Web Application Server 등은 소프트웨어 자체적으로 Cluster 구축을 통해서 Fail Over를 지원하거나 장애가 났을 때 일시적으로 Transaction이 중단되는 것을 허용하는 경우가 많다. 이런 경우에는 SAN을 구성하지 않고 Server에 직접 연결된 DAS를 이용해서 서비스를 제공한다. 권장 시나리오 : ..