Today Keys : VPC, AWS, Endpoint, Gateway, Interface, services, cloud, 아마존, public


이번 포스팅은 지난 포스팅에 이어서 VPC Endpoint에 대해서 알아봅니다.

VPC Endpoint 중에서 Interface 타입의 Endpoint를 생성해서 어떻게 Endpoint를 이용해서

서비스를 접근 할 수 있는지를 알아 볼 수 있는 간단한 예제 포스팅입니다.

* 관련 포스팅 : VPC Endpoint 알아보기

                        Gateway Endpoint 만들어보기 - 포스팅 준비 중
                       
 


이번 포스팅에서는 Interface 타입의 Endpoint인 CloudFormation을 생성해 보겠습니다.

먼저 Endpoint를 생성하기 위해서 '엔드포인트 생성' 메뉴를 선택하여 Endpoint를 만드는 메뉴로 들어갑니다.

 

EndPoint를 만들 때에는 서비스 유형에 따라서 Interface로 만들지 Gateway로 만들지 다음과 같이 나옵니다.

각 서비스 별로 유형이 정해져 있는 것이며, 서비스를 Interface 혹은 Gateway 유형을 선택하는 것은 아닙니다.

 

Endpoint 생성의 전체 메뉴는 다음과 같습니다.

서비스를 고르고, 어느 VPC에 적용할지를 선택하면 해당 VPC의 AZ 정보가 나오고

각 AZ 별로 어떤 Subnet에 생성할지 나옵니다.

그리고 'Private DNS 이름 활성화' 라는 메뉴가 기본적으로 체크되어 있습니다.

이 부분은 아래에서 다시 설명합니다.

보안 그룹은 우선 기본으로 설정합니다.

 

여기까지하면, 손쉽게 Endpoint를 만들 수 있습니다.

 

생성이후, '사용가능' 상태로는 약 1~2분정도 소요 될 수 있습니다.

정상적으로 생성되면 다음과 같이 생성된 Endpoint 정보를 확인 할 수 있습니다.

 

하단의 서브넷 탭을 보면 실제 생성 시에 선택한 AZ 별로 서브넷에 속하는 IP 주소를 갖고 있는 것을 확인 할 수 있습니다.

 

Endpoint를 생성하기 전에는 해당 VPC 내에서 CloudFormation 서비스에 대한 URL을 확인하면

AWS의 리전 내의 공인 IP 주소를 받아오는 것을 확인 할 수 있습니다.

 

하지만, Endpoint 생성 이후에 동일한 URL에 대한 질의를 하면 Endpoint가 갖고 있는 IP 주소를

도메인에 질의에 대한 결과로 받게 되는 것을 확인 할 수 있습니다.

앞에서  'Private DNS 이름 활성화' 을 뒤에서 알아보겠다고 하였는 데, Endpoint 생성 시에

'Private DNS 이름 활성화' 옵션을 활성화하면(default 값이 활성화) 서비스 별 기본 도메인 값을 VPC 내의 Private DNS에

자동으로 등록이 되어서 해당 값을 응답 받을 수 있게 됩니다.

일반 URL이 아닌 별도 URL을 사용하여 접근하고자 할 경우에는 해당 옵션에 대한 체크를 해제하고

별도 도메인으로 Endpoint IP 주소를 관리 할 수도 있습니다.

 

 

Posted by 네떡지기

Today Keys : VPC, AWS, Endpoint, Gateway, Interface, Private, links, services, cloud, 아마존, public


 

 이번 포스팅은 VPC 네트워크에서 AWS 서비스를 AWS 네트워크를 통해서 직접 접근하기 위한 Endpoint에 대해서 알아보는 포스팅입니다. Endpoint는 접근하는 서비스에 따라서 Gateway와 Interface 타입으로 나뉩니다. 이번 포스팅에서는 Endpoint에 대한 간략한 소개를 하고, 다음 포스팅에서는 Endpoint를 생성해서 접근하는 방법에 대해서 알아 볼 예정입니다.

* 관련 포스팅 : Gateway Endpoint 만들어보기 - 포스팅 준비 중
                       
 Interface Endpoint 만들어보기


 VPC Endpoints

Endpoints

  ▪ VPC 네트워크 내에서 VPC 외부에 위치한 Public한 서비스를 IGW를 거치지 않고 VPC내부에서 직접 접근하도록 지원
  ▪ VPC의 내부의 인스턴스가 AWS 서비스와 통신하기 위해 공인 IP를 가지지 않아도 됨.
  ▪ Endpoint는 Gateway 타입 Interface 타입 으로 구분
  ▪ Endpoint는 VPC에서 접근하고자 하는 AWS Public 서비스 별로 개별 생성하며, Gateway타입 지원하는 서비스와
    인터페이스 타입을 지원하는 서비스가 나누어져 있음. 
       - 타입 별 지원 서비시는 아래에 참고
  ▪ VPC와 AWS 서비스 사이의 트래픽이 AWS 네트워크에서 처리하며, IAM 정책을 사용하여 액세스 제어 가능.


Gateway Endpoint 
  ▪ Endpoint가 Gateway 타입으로 지원하여 AWS 서비스 접근 시, 라우팅으로 접근
  ▪ 라우팅 테이블에서 S3나 DynamoDB의 목적지 네트워크에 대한 Target(Next Hop)으로 Gateway Endpoint를 지정
  ▪ S3와 DynamoDB 접근을 지원


Interface Endpoint
  ▪ Endpoint가 AZ 내의 Elastic Network Interface(ENI)로 생성하고, 해당 서비스에 대한 도메인 Lookup을 해당 ENI 응답
  ▪ Kinesis, Service Catalog, Amazon EC2, EC2 Systems Manager(SSM), Elastic Load Balancing(ELB) API 등을 지원
  ▪ Interface Endpoint 생성 시에는 어느 VPC의 어떤 AZ의 어떤 Subnet을 사용할지 선택
  ▪ Interface Endpoint 는 생성 시에 지정한
 각 서브넷의 IP를 각각 할당 받음.
  ▪ Interface Endpoint 를 이용해서 서비스를 호출하는 경우에는, AWS에서 기본으로 사용하는 도메인을 사용하거나, 
    별도의 서비스 도메인을 지정하여 VPC 내에서 서비스 도메인 Lookup 시에  Interface Endpoint 의  IP로 응답하여
    접근하도록 할 수 있음.
  ▪ 기존에 AWS Public 서비스를 사용하도록 어플리케이션이 만들어진 경우에 기본 도메인으로 Interface Endpoint 
   사용하게 되면  어플리케이션에서 AWS 서비스 호출 시에 별도의 변경 과정없이 Endpoint를 이용한 서비시 호출이 가능.

  

Endpoint 타입별 지원 서비스
  ▪ Gateway
    - Amazon S3
    - DynamoDB
 
  ▪ Interface
    - Amazon API Gateway
    - AWS CloudFormation
    - Amazon CloudWatch
    - Amazon CloudWatch Events
    - Amazon CloudWatch Logs
    - AWS CodeBuild
    - AWS Config
    - Amazon EC2 API
    - Elastic Load Balancing API
    - AWS Key Management Service
    - Amazon Kinesis Data Streams
    - Amazon SageMaker and Amazon SageMaker Runtime
    - Amazon SageMaker Notebook Instance
    - AWS Secrets Manager
    - AWS Security Token Service
    - AWS Service Catalog
    - Amazon SNS
    - AWS Systems Manager
    - Endpoint services hosted by other AWS accounts
    - Supported AWS Marketplace partner services

 

 

 

 

 

Posted by 네떡지기

Today Key :  AWS, VPC, Cloud, Network, Peering, region, 접속, 피어링


 이번 포스팅은 VPC 간의 연동을 해주는 VPC Peering에 대한 정리입니다.

 실제 VPC Peering을 연동하는 예제는 포스팅용으로 이미지를 정리해야해서.. 다음 포스팅에서 다뤄집니다. ^^

 혹시 수정이 필요한 내용이나, 보완해야 될 내용이 있으면 덧글로 남겨주세요! 



VPC Peering 

 · VPC 간의 인터넷을 통하지 않고 직접 통신 할 수 있도록 연결하는 기술

 · AWS 내에서 정의하는 정의하는 가상의 네트워크인 VPC는 논리적으로 독립적인 네트워크 망을 선언한 것이기 때문에

   기본적으로 VPC 간에는 서로 통신이 불가하여 VPC 간에 서로 영향을 미치지 않음.

 · VPC 간에 서로 통신을 하기 위해서는 VPC 내에서 인터넷을 통해서 다른 VPC로의 통신을 하는 구조였음.

 · 2014년에 VPC Peering 이라는 기술을 통해서 같은 리전 간의 VPC 네트워크를 서로 연결 할 수 있게 됨.

 · 2017년에 멀리 Region 간의 VPC Peering을 지원하도록 함.

 · 서울 Region에서의 VPC Peering은 2018년 중반부터 지원

 

 

VPC Peering 구성

 · 동일 Region 간의 Peering 예

 

 

  · 멀리 Region 간의 Peering 예

 

 

   · 공유 서비스를 이용하는 VPC Peering 예

 

 

VPC Peering 구성 관련

 · VPC Peering으로 연결 시에 VPC 간의 네트워크 대역이 겹치지 않도록 설계해야 함.

  · VPC Peering을 이용하면 Peering 된 VPC 네트워크은 AWS 백본을 통해서 통신하여 Pulbic 인터넷 망을 통과하지

   않기 때문에   보안적으로 보다 우수함.

   또한 내부 백본 네트워크를 통하기 때문에 이중화나 네트워크 병목에 대한 이슈도 없음.

 · VPC Peering은 단일 계정으로도 가능하며, 서로 다른 계정 간의 VPC Peering 구성도 가능

 

 VPC Peering 제한

· 멀티 Region 간의 VPC Peering 시에는 security group 참조 지원 안 함.

· 멀티 Region 간의 VPC Peering 시에는 DNS resolution 지원 안 함.

· IPv6와 Jumbo 프레임 지원 안 함.

·  VPC Peering을 통해서 외부 혹은 다른 VPC에서 VPC를 통해서 또 다른 VPC로 접근하는 Transit 기능은 지원하지 않음.

 

 

 

 

Posted by 네떡지기
분류없음2016.01.14 13:12

Today Key : Cloud Native App, CNA, Microsoft, Service, MSA, Immutable Infrastructure

 

이번 포스팅은 Cloud Native App에 관한 포스팅입니다.

이 포스팅은 2번에 걸쳐서 나눠서 올려지며, 이번에는 간단한 발표용으로 만든 프레젠테이션 이미지를 포스팅하며

이번 주말 전까지는 일반 포스팅 형식으로 같은 내용을 포스팅 할 예정입니다.

본 자료는 슬라이스쉐어로도 업로드되어 있으니, 다운로드는 아래 링크에서 받으시면 됩니다.
( 슬라이드쉐어 : http://www.slideshare.net/ssuserc08d76/cloud-native-app )


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Posted by 네떡지기
분류없음2016.01.08 09:57

AWS 한국 리전

1 7(어제) AWS Cloud 세미나에서 AWS Seoul Region 정식 오픈 발표와  한국 Region 서비스를 시작.

   -  전세계 12번째, 아시아 태평양 지역의 5번째 리전

서울 리전은 2개의 Availability Zone(AZ)으로 구성

  - AZ 2곳이지만, 실제 국내 IDC 3(KT[목동], SKB[일산], 롯데정보통신+현대정보기술[용인]) 임차.

 

 

 

                                                                                  < AWS 전체 Region >

 

 

 

AWS 한국 리전 가용한 서비스 목록(1 7 오픈 기준)

 

 

 

 

AWS 한국 서비스 속도

한국 Region 경우 10ms 응답 속도 (EC2 기본 서버 테스트)

     - 일본 Region 경우 30~50ms 응답 속도

 

 

 

 

서비스 비용 (EC2)

한국 Region 경우에는 일본 Region 거의 비슷하거나 조금 낮은 수준의 비용.

      - 물론, 미국의 버지니아 동부 Region 비해서는 높은 수준. (미국 Region 중에서도 버지니아 Region이 가장 저렴)

       ※ ap-northeast-2 : 한국 Region

 

 

 

 

Etc..

AWS 한국 Region 아니라, 올해 MS Azure 한국(부산[LG CNS]) 상륙하게 되면 앞으로 국내 클라우드 시장은 치열해질 듯…

 

Posted by 네떡지기
분류없음2015.10.07 09:12

Microservice, 마이크로서비스, Cloud, MSA, Architectures, 아키텍처, Monolithic, 클라우드 :Today keys.

 

이번 포스팅은 마이크로 서비스에 대한 포스팅입니다.

'안' 개발자로서, 이런저런 자료를 찾아보며 정리해 보았습니다.

새로운 내용들을 보다보면, 역시나 IT 분야내에서는 이런 저런 다양하게 알아야 할 것들이 많다는 것을 느끼게 됩니다.

아마도 이번달까지는 관련 내용을 정리해서, 좀 더 포스팅을 하게되지 않을까 싶습니다. (혹은... 정리만.. 포스팅은 다음달?..)

 


 

 

마이크로 서비스 아키텍처(MSA : Micro Service Architectures)

 

 

 

 

 

마이크로 서비스 아키텍처란?

   독립적이고 단순한 개별 서비스들로 전체의 서비스를 구성

   단일 Application 나누어서 작은 서비스들의 조합으로 구성

   기존의 Monolithic Architecture 대비되는 개념

   2012년 ThoughtWorks James Lewis Java the Unix way라는 제목의 발표에서 언급.

     2014 3 James Lewis Martin Flowler Microservices 라는 타이틀로 패러다임을 정립한 기사 발표

 

마이크로 서비스 아키텍처의 배경

   Cloud 서비스 환경에서의 기존의 Monolithic Architectures 적용의 어려움

        - Monolithic Architectures에서는 코드의 크기가 크기 때문에 배포에 대한 부담

        - 서비스 변화의 속도에 따른 배포 주기가 짧아지는 것에 대한 부담

   갈수록 복잡해지는 비즈니스에 따른 거대한 서비스 생성

   OpenSource Internet 등으로 인해 짧아지는 기술 수명 주기

   서비스 연계성으로 인한 문제

       - 일부 서비스 부분에 변경 시에도 연계 시스템에 대한 Re-Build 필요

 

 

Micro Service Architectures vs Monolithic Architecture

 

 

 

 

마이크로 서비스 아키텍처 구성 방식

   마이크로 서비스 간에는 HTTP 기반 API 등을 통해서 통신.

 

 

 

   각 서비스는 개별 서비스로 동작하기 때문에 서로 다른 독립적인 언어로 개발 가능. (Polyglot Programming)

 

   서비스가 복잡할 경우에는 서비스 간의 연결을 직접 구성하게 경우에 복잡도가 증가하므로, 중간에 API 관리하는 서비스 오케스트레이션 계층으로서의 API Gateway를 구성 가능.

 

 

 

마이크로 서비스 아키텍처의 특징

   Decoupled : 서비스 간의 종속성 배제

   Well Defined Interface : 서비스 간의 통신을 위해서 정의된 API 필요

   Independent : 서비스 별로 독립적으로 개발 운영할 있음

   Conway's Law 적용 :  "Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure." / 결국 서비스의 구성 디자인은 서비스를 구현하는 조직의 모습에 기반한다.

 

 

 

 

마이크로 서비스 아키텍처의 장점/단점

     장점

         - 서비스에 대한 확장성이 좋고, 개발 배포 사이클 관리 용이

         - 서비스 파트에서 제공하는 서비스에 최적하는 방법/언어 사용 가능(Polyglot Programming)

         - 작은 서비스로 구성되기 때문에 서비스에 대한 민첩성 확보.

         - 컴포넌트와의 종속성이 배제되어 서비스 변경이 쉬움

        

    단점

         - 서비스 간의 연계성 다양한 기술 사용으로 인한 운영 테스트 복잡도 증가

         - 서비스 간의 외부 호출로 인한 성능 비용 증가(Latency)

         - 설계 시의 고려해야 사항이 많아짐

         - 서비스의 세분화됨에 따라, 서비스 간의 코디네이션(Chief Architect) 필요.

         - 배포와 운영에 자동화를 사용하지 않으면, 오히려 기존 방식보다 어려움(개별 서비스이기 때문에 수량이 많아짐)

 

 

마이크로서비스 설계시 고려사항들

    개별 서비스에 대한 기능 적합성 성능에 대한 효율성

    서비스 간의 호환성

    서비스에 대한 신뢰성 서비스 간의 통신 시의 보안

    개별 서비스에 대한 유지보수성 이식성

 

Posted by 네떡지기
분류없음2015.10.02 17:52

 

Cloud, Security,Hypervisor, Private, Public,Hybrid, Computing, CloudLink, SecureVM, Virtual, Machine    : Today Key

오랜만에 포스팅 해 봅니다.  

오늘은 클라우드 환경에서의 VM에 대한 보안을 위한 SecureVM이라는 솔루션에 대해서 간략하게 소개해보는 포스팅입니다. 

기존의 VM간의 통신 보안을 위한 가상 방화벽과는 조금은 다른 측면에서의 보안 솔루션입니다.

 


 

 

CloudLink SecureVM

  CloudLInk SecureVM 클라우드 환경에서 VM 암호화하여 관리할 있는 솔루션

  Multi-tenant 인프라환경에서 VM 암호화를 통한 보안 강화

  Windows, Linux 지원

  Private Public Cloud 지원

 

 

 

SecureVM 보안 영역

  Data 볼륨 암호화

  Boot 볼륨 암호화

  VM Pre-Boot 인증

 

기존 Native OS 암호화 방식 사용

  Windows에서는 BitLocker, Linux에서는 eCryptfs 사용

  장점

       -  배포가 빠름

       -  Application 수정이 필요가 없음

       -  데이터 암호화 성능에 대한 오버헤드가 없음

 

eCryptfs

       - Linux File system 암호화 기술

       - User Login 시에 복호화 데이터로 Mount 되고, Log-out시에 자동으로 UnMount되면서 데이터는 암호화

       - 정상적인 접근 이외에는 암호화된 데이터에서 복호화 되지 않았기 때문에 데이터를 없음.

 

BitLocker

       -  Windows 데이터 보호 기술

       -  TPM 사용한 시스템 무결성 확인

        TPM 버전 1.2 또는 2.0  / TPM이 BitLocker를 사용하는 데 필요하지는 않지만,

             TPM은 설치된 컴퓨터에서만 추가 보안 기능인 시작 전 시스템 무결성 확인 및 다단계 인증을 제공할 수 있습니다.

            (TPM 변경되면 운영체제 무결성 검사에 실패)

           * CloudLink Center Software TPM 방식

BitLocker 참조 : https://technet.microsoft.com/ko-kr/library/cc732774.aspx

TPM 참조 :  https://technet.microsoft.com/ko-kr/library/hh831507.aspx

 

            

 

 

 

 

 SecureVM 컴포넌트

  1. CloudLInk Center Virtual appliance

        - VM Deploly, Key management,Security policy 정의,  Security monitoring,

  2. SercureVM agent

        - CloudLink Center 통신하여 Native OS 암호화를 사용하기 위한 Key 요청하고, 수신.

        - Guest OS Level에서 동작하기 때문에 Cloud Platform 적함. 이미 다양한 클라우드 플랫폼에서 테스트 완료

 

Key 관리

  Agent와의 인증을 위한 Key 관리를 Cloudlink Center 자체적으로 하거나 혹은 외부 관리(Windows AD, RSA ) 가능.

  Key 관리를 하는 Cloudlink Center 혹은 외부 관리를 경우에 해당 시스템은 Private Cloud 있는 것이 보안상 유리

 

SecureVM Agent 배포

  배포 대상

      1. 신규 생성되는 VM

      2. 현재 운영 중인 VM

 

  배포절차

    1. 필요한 Components 설치

     2. 인증서 생성

     3. Pre-Boot 인증 추가

     4. CloudLink Appliance 등록

     5. Disk 암호화

 

  배포 방법

    1. VM 관리자에 의한 Manual 배포

    2. 자동화 배포

           - Active Directory Group Policy

           - Configuration Management Tools (Chef, Puppet, etc..)

 

SecureVM Boot Process

   1. VM에서 OS Load되고, 암호화된 데이터에 접근하기 시작할 ,

          SecureVM 동작하면서 IP/Cloud platform/무결성 값을 확인하여, Cloudlink Center 전송하여, 해당 값을 확인 요청.

   2. CloudLink Center에서는 값과 VM Identity 확인

   3. 확인된 사항을 통해 Cloudlink에서는 지정된 정책을 선택한 후에, Agent 요청을 허가하면서 Decryption key 전송

   4. 암호화된 VM 해제되고, 동작하기 시작

   5. Physical Storage Data  암호화 상태

 

 

 

 

 

기타

CloudLink Center 이중화하여 High Availability 구성 가능

Windows Linux에서의 지원되는 보안 범위가 다름. (기존 Native OS 보안 이용 때문)

Boot 과정에 대한 제어 ,  해당 VM Hypervisor에서 전원을 On하더라도 Cloudlink Center에서 인가를 해줘야

  정상적으로 해당 VM 가동 .

     - Access-List 사용하여 사전 인가 List 정의하여 자동으로 인가되도록 수도 있음.

         사전 인가 List 항목 : IP , CIDR, IP Range(Start/End)

           CIDR : IP주소/서브넷Bit 형식     ex) 192.168.0.0/24  

  CloudLink에는 VM 암호화 솔루션인, SecureVM이외에 File Storage 암호화인 SecureFILE, SucureVSA 있음.

 

Posted by 네떡지기

NFV에 대해서 간략하게나마 정리를 시작합니다.

잘못된 부분이나, 추가/보완할 내용이 있으시면 덧글 부탁드리겠습니다.

추가/보완되는 내용이 있으면 업데이트 하도록 하겠습니다.

 

 - 초기작성 : 2013. 09.21

 - Last Update : 2013. 09.21

 


 

NFV (Network Function Virtualization)

   - 기존 Hardware Appliances들로 구현된 Route, NAT, Firewall, IDS, IPS, DNS, Caching등의 다양한 기능을 Software 형태의

     Virtual Applicances로 구현하여 운용하는 가상화 기술.

   - 2012년 10월 독일 SDN & OpenFlow World Congress 에서 BT와 도이치텔레콤이 NFV 단체 설립 발표.

   - ETSI(European Telecommunications Standards Institue)의 ISG(Industry Specification Group)에서 NFV 표준화 시작

   - 서비스 사업자 주도로 NFV 표준화 진행 중.

 

 

NFV의 목적

   - 표준 IT 가상화 기술을 활용하여 기존의 단일 Appliance로 동작하던 장비들을 Software형식으로 Virtual Appliance로 구현.

   - Virtual Appliance로 구현된 S/W는 표준 대용량 서버/스위치/스토리지를 활용하여 하나의 서비스 자원으로 운용 

   - 기능적인 구현을 Virtual Appliance에서 구현함으로써, 표준화된 대용량 장비 개발 장려.

   - 서비스 기능 구현을 위해 보다 민첩한 소프트웨어 기반 프레임워크를 사용하여 서비스 유연성을 향상.

 

 

NFV 특징

   - 기존의 고정된 인프라와 모바일 인프라 모두에서 어떠한 Data Plane 처리 / Control Plane 기능 적용 가능.

   - 기존의 독립된 Hardware Applicane의 경우에 단독형 장비이므로 물리적인 확장만 가능하지만,

      Virtual Appliance로 구현된 경우, CPU/Memory와 같은 추가적인 자원 할당만으로 유연한 확장이 가능하다.

      [On-Demand 시에 Scale-Out을 쉽게 할 수 있음]

   - 필요에 따라, 새로운 장비에 별도의 설치가 필요없이 기존의 Virtual Appliance의 이동 및 인스턴스화가 가능하다.

 

 

NFV vs SDN

   - NFV은 SDN과의 보완을 통해서 상호 이익을 가져갈 수 있지만, 서로의 종속되어 구현되지는 않을 것이다.

   - SDN는 네트워크를 보다 쉽게 설정/관리할 수 있게 해주며,
     NFV 네트워크를 보다 쉽게 Deploy하고, 확장할 수 있게 해준다.

     SDN과 NFV에서 이를 가능하게 해주는 주요 Key테마는 바로 "Software"이다.

 

 

 

  

SDN

NFV

탄 생 배 경

 • Control Plane과 Data Plane을 분리
 • 중앙 집중식 제어와 Network의 프로그램화

 • 네트워크 기능 이동(독립 Appliance → 일반 서버

적 용 위 치 

 • Campus / Datacenter / Cloud  • Service Provider Network

적 용 장 비

 • 범용 서버와 스위치  • 범용 서버와 스위치

초기

어플리케이션

 • Cloud orchestration and networking

 • Routers, firewalls, gateways, CDN,

   WAN accelerators, SLA assurance

프로토콜

 • OpenFlow  • 현재 없음

표준화 기구

 • Open Networking Forum (ONF)

 • ETSI NFV Working

 

NFV 구현 시

  - CAPEX(설비투자비) / OPEX(운용비) / 상면 / 에너지 소비량 의 절감 효과

  - 네트워크 사업자의 성숙주기 감소


CloudNFV 

  - 다수의 벤더로 구성된 NFV에 대한 Prototype을 만드는 컨소시엄 단체

  - OpenDaylight과 같은 OpenSource Protect는 아니며, 각 벤더들은 자신들의 지적 재산권을 유지하여 생산한다.

    하지만, 서로 다른 NFV Components간의 Open Interface를 통해서 Multi 벤더 NFV를 구성할 수 있다.

 

   • Dell : NFV 기능이 있는 데이터센터 인프라

   • 6WIND :  Cloud 환경에서의 성능 가속화 기능

   • EnterpriseWeb : 가상 네트워크 기능을 구성하는 리소스들을 통합하고 최적화를 위한 데이터모델에 대한 소프트웨어

   • Overture Network : Orchestration 소프트웨어 / SDN 컨트롤러

                              클라우드에 배포된 가상 네트워크와 연결되는 Metro Edge Switch

   • Qosmos : 네트워크 모니터링 소프트웨어 (NFV가 어떻게 네트워크를 운영을 하는지에 대한 모니터링)

 

 

 

Posted by 네떡지기

티스토리 툴바