INTEL CPU 버그 -> 커널 스페이스 메모리가 유저 스페이스로 유출


https://lkml.org/lkml/2017/12/27/2

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/?id=a89f040fa34ec9cd682aed98b8f04e3c47d998bd

Xen : XSA-253 : https://xenbits.xen.org/xsa/advisory-253.html


Xen은 Paravirtual만 해당 된다는 얘기가 있다. AWS Korea는 전부 HVM이므로 해당이 없을지도..


Softlayer는 1월 6일 00시부터 이틀에 걸처 전체 Host를 리부팅 해서 패치 한다.


패치로 인해 성능이 5%~30% 저하된다는 벤치마크 결과가 있다. 특히 IO 쪽이 문제되는 듯.

http://www.phoronix.com/vr.php?view=25767


=======================================================================

지난 10 년 동안 생산 인텔 프로세서는 치명적인 칩 수준의 보안 버그를 가지고 있습니다.  OS 레벨에서 수정 사항이 나와야한다고보고하고, 수정본을 사용할 수있는 경우에도 주목할만한 성능 저하가있을 것입니다.

 

이 보고서는이 시점에서 버그에 대해 알려진 바가 크지 않다고 설명하지만, "지난 10 년 간 생산 된 최신 인텔 프로세서에 존재하는"근본적인 설계 결함 "이라고 지적했다.


이 버그로 인해 사용자 프로그램은 보호 된 커널 메모리의 내용을 식별 할 수있게되어 해커가 다른 보안 버그를보다 쉽게 ​​악용 할 수 있습니다. 등록 메모에 따르면, 실제로는 그보다 더 나쁠 수 있습니다. 커널 메모리에 대한 액세스를 제공하는이 버그는 "프로그램과 로그인 한 사용자가 커널 메모리의 내용을 읽을 때 악용 될 수 있습니다."


커널의 메모리 공간은 암호, 로그인 키, 디스크에서 캐시 된 파일 등과 같은 모든 종류의 비밀을 포함 할 수 있으므로 사용자 프로세스 및 프로그램에서 숨겨집니다. 브라우저에서 실행되는 JavaScript 또는 공유 된 공용 클라우드 서버에서 실행되는 악성 소프트웨어가 민감한 커널 보호 데이터를 스니핑 할 수 있다고 상상해보십시오.


이 칩 레벨 보안 버그에 대한 패치도 그리 좋지 않습니다. 이 보고서는이 시점에서 더 구체적인 정보가 명확하지 않더라도 수정으로 인해 5 % ~ 30 %의 속도 저하가 발생할 수 있다고 설명합니다. 속도 저하는 프로세서가 캐시 된 데이터를 덤프하고 메모리에서 정보를 다시로드해야하는 방식으로 인해 발생합니다.


현재 Microsoft 및 Linux 개발자는이 문제를 해결하기 위해 노력하고 있습니다. 이 결함은 인텔의 x86 하드웨어에 결함이 있기 때문에 인텔 기반 맥에도 영향을 미치지 만, 애플의 수정 작업은 불분명하다. 결함이 하드웨어 자체에 있기 때문에 정상적인 마이크로 코드 업데이트로 해결할 수는 없지만 오히려 OS 레벨의 수정이 필요합니다.


이러한 커널 페이지 테이블 격리 패치는 커널을 완전히 별도의 주소 공간으로 이동하므로 실행중인 프로세스에서 보이지 않을뿐 아니라 전혀 존재하지 않습니다. 실제로는 필요하지 않지만 Intel의 실리콘에는 커널 액세스 보호가 어떤 식 으로든 무시 될 수있는 결함이 있습니다.


이 분리의 단점은 모든 시스템 호출과 하드웨어의 모든 인터럽트에 대해 두 개의 개별 주소 공간을 전환하는 것은 비교적 비용이 많이들고, 시간이 많이 걸린다는 점입니다. 이러한 컨텍스트 스위치는 즉시 발생하지 않으며 프로세서가 캐시 된 데이터를 덤프하고 메모리에서 정보를 다시로드하도록합니다. 이렇게하면 커널의 오버 헤드가 증가하고 컴퓨터 속도가 느려집니다.


개발자가 패치 작업을 할 때 버그에 대한보다 구체적인 정보가 현재 금하고 있다고 추측합니다. 다음 주 곧 Intel에서 직접 더 많은 세부 정보를 얻을 수 있습니다.

AWS는 re:Invent 때 항상 깜짝 놀랄만한 서비스를 출시합니다.

아무도 예상 못해선... 설마했던... 그것을 아마존이 또 출시했네요.. 바로 VM이 아닌 물리서버인 베어메탈 서비스 입니다.

사실 VMware on AWS를 출시할 때 부터 가능성이 점쳐졌던 거긴 한데요...

설마 진짜 베어메탈 서비스를 출시 할지 몰랐네요. 사용자 입장에서의 사용성은 베어메탈도 VM과 동일 합니다.

서버의 순수한 성능을 다 확보 할수 있고, 라이센스 정책에서 좀 더 자유로울 수 있겠네요.

Softlayer(IBM Cloud)가 거의 베어메탈의 표준 처럼 잡고 있는 클라우드였는데요.... 이제 긴장해야겠습니다. 

아직 AWS가 프리뷰이긴하지만 언제 훅 치고 들어올지 모르니까요.


출처: https://aws.amazon.com/ko/blogs/aws/new-amazon-ec2-bare-metal-instances-with-direct-access-to-hardware/

Amazon EC2 Bare Metal Instances with Direct Access to Hardware

When customers come to us with new and unique requirements for AWS, we listen closely, ask lots of questions, and do our best to understand and address their needs. When we do this, we make the resulting service or feature generally available; we do not build one-offs or “snowflakes” for individual customers. That model is messy and hard to scale and is not the way we work.

Instead, every AWS customer has access to whatever it is that we build, and everyone benefits. VMware Cloud on AWS is a good example of this strategy in action. They told us that they wanted to run their virtualization stack directly on the hardware, within the AWS Cloud, giving their customers access to the elasticity, security, and reliability (not to mention the broad array of services) that AWS offers.

We knew that other customers also had interesting use cases for bare metal hardware and didn’t want to take the performance hit of nested virtualization. They wanted access to the physical resources for applications that take advantage of low-level hardware features such as performance counters and Intel® VT that are not always available or fully supported in virtualized environments, and also for applications intended to run directly on the hardware or licensed and supported for use in non-virtualized environments.

Our multi-year effort to move networking, storage, and other EC2 features out of our virtualization platform and into dedicated hardware was already well underway and provided the perfect foundation for a possible solution. This work, as I described in Now Available – Compute-Intensive C5 Instances for Amazon EC2, includes a set of dedicated hardware accelerators.

Now that we have provided VMware with the bare metal access that they requested, we are doing the same for all AWS customers. I’m really looking forward to seeing what you can do with them!

New Bare Metal Instances
Today we are launching a public preview the i3.metal instance, the first in a series of EC2 instances that offer the best of both worlds, allowing the operating system to run directly on the underlying hardware while still providing access to all of the benefits of the cloud. The instance gives you direct access to the processor and other hardware, and has the following specifications:

  • Processing – Two Intel Xeon E5-2686 v4 processors running at 2.3 GHz, with a total of 36 hyperthreaded cores (72 logical processors).
  • Memory – 512 GiB.
  • Storage – 15.2 terabytes of local, SSD-based NVMe storage.
  • Network – 25 Gbps of ENA-based enhanced networking.

Bare Metal instances are full-fledged members of the EC2 family and can take advantage of Elastic Load BalancingAuto ScalingAmazon CloudWatchAuto Recovery, and so forth. They can also access the full suite of AWS databaseIoTmobileanalyticsartificial intelligence, and security services.

Previewing Now
We are launching a public preview of the Bare Metal instances today; please sign up now if you want to try them out.

You can now bring your specialized applications or your own stack of virtualized components to AWS and run them on Bare Metal instances. If you are using or thinking about using containers, these instances make a great host for CoreOS.

An AMI that works on one of the new C5 instances should also work on an I3 Bare Metal Instance. It must have the ENA and NVMe drivers, and must be tagged for ENA.

— Jeff;

 



Polly 가 드디어 한국어를 합니다. 기계합성어 답지않게 정말 자연스럽습니다. 이제 음성합성은 구글보다 Polly를 이용할것 같습니다.

더 자연스럽고, 더 쉽게 쓸 수 있습니다. 아래 링크로 한번 들어 보시죠.

음성 파일

출처: https://aws.amazon.com/ko/blogs/korea/now-available-amazon-polly-in-seoul-region-and-korean-woman-voice-seoyeon

Amazon Polly 서울 리전 출시 및 한국어 여성 ‘서연(Seoyeon)’ 음성 공개

 Amazon Polly는 고급 딥 러닝 기술을 사용하여 실제 사람 목소리처럼 음성을 합성하는 텍스트 음성 변환 서비스입니다. 텍스트를 다양한 언어로 수십 개의 생생한 음성이 제공되므로 여러 국가에서 적합한 음성을 선택하여 음성 지원 애플리케이션을 개발할 수 있습니다.

오늘부터 Amazon Polly를 서울 리전에서 사용 가능합니다. 또한, 한국어 여성 ‘서연(Seoyeon)’음성을 공개합니다.

Amazon Polly의 종량 요금제, 변환 문자당 저렴한 비용, 무제한 재생은 거의 모든 애플리케이션에서 음성 합성을 구현하는 비용 효과적인 방법을 제공합니다. 이전에 재생된 오디오를 재생할 때마다 로열티를 요구하거나 요금을 부과하는 다른 솔루션과 달리, Amazon Polly는 추가 요금 없이 무제한 재생을 허용합니다. 이러한 무료 재생은 오프라인 사용까지 확대됩니다. MP3 및 OGG와 같은 다양한 표준 형식으로 음성 파일을 생성하여 오프라인 재생 전용으로 휴대폰 또는 사물 인터넷(IoT) 디바이스와 같은 디바이스에 저장할 수 있습니다.

실제 같은 음성과 대화 사용자 경험을 제공하기 위해서는 일관되게 빠른 응답 시간이 요구됩니다. Amazon Polly API로 긴 텍스트를 전송하더라도 Amazon Polly API가 오디오를 스트림으로 애플리케이션으로 반환하므로 즉시 음성을 재생할 수 있습니다.

아래 샘플 코드에 대한 음성 파일을 확인해 보실 수 있습니다.

Python

from boto3 import client
polly = client("polly", region_name="ap-northeast-2")
response = polly.synthesize_speech(
        Text="안녕하세요. 제 이름은 서연이에요! 저는 새내기 아마존 폴리 음성 비서입니다. 텍스트를 입력하시면 읽어드릴께요.",
        OutputFormat="mp3",
        VoiceId="Seoyeon")

특히, 음성 합성 애플리케이션을 위한 Speech Synthesis Markup Language(SSML), W3C 표준, XML 기반 마크업 언어를 지원하고 표현, 강조 및 억양을 위한 일반 SSML 태그를 지원합니다. 이러한 유연성은 청중의 관심을 끌 수 있는 생생한 음성을 생성하는 데 도움이 됩니다.

아래 샘플 코드에 대한 음성 파일을 확인해 보실 수 있습니다.

Html

<speak>
   오늘의 <prosody rate="x-slow">날씨를 전해 드리겠습니다</prosody>. 
   현재, 전국이 구름이 많은 가운데 일부 중부 지역과 전북에는 <prosody volume="x-loud">눈이 날리거나</prosody><break time="1s"/> <prosody pitch="x-high">빗방울이 떨어지는 곳이 있습니다.
   </prosody>. 서울의 경우 북부 지역을 중심으로 <amazon:effect name="whispered"><prosody rate="-10%">눈이 날리고 있으나,</prosody></amazon:effect> 공식적인 첫눈으로 기록되지는 않습니다.
</speak>

자세한 내용은 SSML 태그에 대한 Amazon Polly 설명서를 참조하십시오.

Amazon Polly는 월 5백만자 까지 무료로 제공됩니다. 그 이상의 경우, 한 자당 $0.000004 per 또는 제작된 오디오 분당 $0.004로 과금 됩니다.  일반적인 한국어 뉴스 기사 (2,500자)의 경우, $0.01 (11원) 정도로 매우 저렴합니다. 예를 들어, 영어로 된 Adventures of Huckleberry Finn이라는 책 원문 전체는 약$2.4 정도 됩니다. 더 자세한 것은 Polly 요금 정보를 참고하세요.

이제 Amazon Polly를 통해 뉴스 및 전자책 리더, 게임, 전자 학습 플랫폼, 시각 장애가 있는 사람을 위한 접근성 애플리케이션, 빠르게 성장하는 사물 인터넷(IoT) 세그먼트 등과 같은 모바일 애플리케이션이 등 다양한 한국어 지원에 활용하실 수 있습니다. Amazon Polly에 대한 더 자세한 사항은 제품 페이지나 기술 문서를 참고하시기 바랍니다.

– 윤석찬(Channy);


OpsWorks 가 원래 Chef 기반이죠.. 그런데 이제 Puppet도 지원하네요. (이제 Ansible만 하면 되겠습니다;;;)

Puppet에 익숙한 사용자들이 더욱 접근 하기 좋아졌네요...

출처: https://aws.amazon.com/ko/blogs/korea/new-aws-opsworks-for-puppet-enterprise/

AWS OpsWorks for Puppet Enterprise 지원

작년 AWS re:Invent에서 고객이 AWS가 관리하는 Chef Automate 서버를 갖도록 할 수 있는 AWS OpsWorks for Chef Automate를 출시했습니다. 고객 피드백을 기반으로 이제 Puppet Enterprise를 OpsWorks에 도입합니다.

Puppet Enterprise를 사용하면 각각의 관리하는 노드에 배포된 Puppet 에이전트를 통해 인스턴스 프로비저닝, 구성 및 관리를 자동화할 수 있습니다. 한 번 구성을 정의하면 자동 롤백 및 드리프트 감지를 통해 수천 개의 노드에 적용할 수 있습니다. AWS OpsWorks for Puppet Enterprise는 기존 Puppet 매니페스트를 사용하여 원활하게 작업하면서 고유한 Puppet 마스터를 유지 관리할 필요를 없앱니다.

OpsWorks for Puppet Enterprise는 Puppet 마스터 서버를 관리하고 설치, 업그레이드 및 백업과 같은 운영 작업을 처리합니다. 또한 노드 등록을 간소화하고 노드 부트스트래핑에 유용한 스타터 키트를 제공합니다. 추가 정보는 아래를 참조하십시오.

관리형 Puppet 마스터 생성

OpsWorks에서 Puppet 마스터 생성은 간단합니다. 우선 OpsWorks 콘솔의 Puppet 섹션으로 이동한 다음 “Create Puppet Enterprise Server”를 클릭합니다.

설정의 첫 번째 부분은 Puppet 마스터에 대한 리전 및 EC2 인스턴스 유형을 구성하는 것입니다. c4.large가 최대 450개의 노드를 지원하는 반면 c4.2xlarge는 1,600개 이상의 노드를 지원할 수 있습니다. Puppet Enterprise 서버는 최신 버전의 Amazon Linux(2017.09)와 Puppet Enterprise(2017.3.2)와 함께 프로비저닝됩니다.

설정의 다음 화면에서 Puppet 마스터에 연결할 SSH 키를 선택적으로 구성할 수 있습니다. 주요 사용자 지정을 할 때 유용하지만 인스턴스 자체에서보다 클라이언트 도구를 통해 Puppet과 상호 작용하는 것이 모범 사례입니다.

또한 이 페이지에서 r10k repo가 동적 구성을 가져오도록 설정할 수 있습니다.

고급 설정 페이지에서 VPC, 보안 그룹, IAM 역할 및 인스턴스 프로파일에 맞는 일반적인 배포 옵션을 선택할 수 있습니다. OpsWorks에서 인스턴스 보안 그룹을 생성하도록 선택한 경우 그룹이 기본적으로 열리기 때문에 이후에는 액세스를 제한하는 것이 중요합니다.

이 페이지에서 주목해야 하는 두 가지 구성 요소는 유지 관리 기간과 백업 구성입니다. Puppet 소프트웨어의 새 마이너 버전이 나오면 AWS 테스트를 통과하는 즉시 Puppet 마스터에서 Puppet Enterprise 마이너 버전을 자동으로 업데이트하도록 시스템 유지 관리가 설계됩니다. AWS는 철저한 테스트를 실시하여 Puppet 업그레이드가 프로덕션 지원이며 기존 고객 환경을 방해하지 않고 배포하는지 확인합니다. 자동 백업을 통해 Puppet 마스터의 내구성이 뛰어난 백업을 S3에 저장하고 언제든지 백업을 복원할 수 있습니다. 업무상 필요에 따라 백업 주기 및 보존을 조정할 수 있습니다.

AWS OpsWorks for Puppet Enterprise 사용하기

Puppet 마스터가 프로비저닝하는 동안 콘솔에 두 가지 유용한 정보 상자가 제공됩니다.

Windows 및 Linux 노드에 Puppet 에이전트를 설치하기 위한 샘플 사용자 데이터는 물론 로그인 자격 증명을 다운로드할 수 있습니다. 여기서 중요한 점은 Puppet 마스터 연결이 가능한 경우 온프레미스 노드 또한 관리할 수 있다는 점입니다.

Puppet 마스터가 완전히 프로비저닝되면 Puppet Enterprise http 콘솔에 액세스하여 사용하던 대로 Puppet을 사용할 수 있습니다.

유용한 세부 정보

AWS OpsWorks for Puppet Enterprise는 관리하는 노드의 노드 시간에 따라 요금이 책정됩니다. 요금은 노드 시간당 $0.017부터 시작하여 노드의 볼륨에 따라 감소합니다. 여기에서 전체 요금 페이지를 볼 수 있습니다. 또한 Puppet 마스터 실행에 필요한 기본 리소스에 대한 요금이 부과됩니다. 출시 시점에서 AWS OpsWorks for Puppet Enterprise는 미국 동부(버지니아 북부) 리전, 미국 서부(오레곤) 리전, EU(아일랜드) 리전에서 사용할 수 있습니다. 물론 콘솔에서 봤던 모든 것을 AWS SDK 및 CLI를 통해 수행할 수 있습니다. 시작 안내서에서 자세한 정보를 얻을 수 있습니다.

– Randall;

이 글은 New – AWS OpsWorks for Puppet Enterprise의 한국어 번역입니다.


Amazon Redshift Spectrum은 Athena만큼 기대되는 제품이 였는데 드디어 서울리전에도 사용이 가능해졌습니다.

Athena가 EMR을 공유인프라를 활용한 SaaS 형으로 제공서비스라면

Redshift Spectrum은 이름처럼 Redshift를 공유인프라를 통해 SaaS형으로 제공하는 서비스입니다. 구글 빅쿼리랑 대응 되겠네요.

둘다 S3 데이터를 직접 다룰 수 있습니다. 

세부 내용은 아래 AWS 블로그 내용 참고 하시 면 되겠습니다.


출처: https://aws.amazon.com/ko/blogs/korea/10-best-practices-for-amazon-redshift-spectrum/

Amazon Redshift Spectrum에 대한 10가지 모범 사례

Amazon Redshift Spectrum 을 사용하면 Amazon S3에 저장된 데이터에 대해 Amazon Redshif SQL 쿼리를 실행할 수 있습니다.  즉, Amazon Redshift의 분석 기능을 데이터웨어 하우스(DW) 내 로컬 디스크에 저장된 데이터 이상으로 확장 할 수 있습니다.  시간이 많이 걸리는 추출, 전송 및 로드 (ETL) 프로세스를 거치지 않고 Amazon S3내의 “데이터  레이크(Data Lake)”에서 방대한 양의 데이터를 바로 쿼리 할 수 있으며, 정교한 쿼리 최적화를 적용하고 수천 노드의 프로세싱을 확장하여 빠른 성능을 제공합니다.이 글에서는 Amazon Redshift Spectrum에 대한 중요한 모범 사례를 몇 가지 분류를 통해 알려 드리고자 하며, 주로 Amazon Redshift 고객과의 많은 대화와 직접 진행한 프로젝트에서 나온 것들입니다.

언제 Amazon Redshift를 선택하나요?

Amazon Athena와 Amazon Redshift Spectrum를 언제 사용하는지 궁금해 하는 고객들이 있습니다.

Amazon Athena는 SQL을 사용하여 Amazon S3에 저장된 데이터에 대해 대화 형 애드훅(Ad-hoc) 쿼리를 실행하는 경우에 유용합니다. Amazon Athena의 서버리스 아키텍처는 쿼리를 수행하기 위해 클러스터를 미리 프로비저닝하지 않아도 됩니다. 각 쿼리에서 스캔 한 S3 데이터의 양에 따라 요금이 부과됩니다. 데이터를 압축, 분할 또는 컬럼 형식으로 변환하여 비용을 크게 절감하고 성능을 향상시킬 수 있으므로 Amazon Athena가 쿼리를 실행하기 위해 스캔해야 하는 데이터 양이 줄어 듭니다. JDBC를 사용하는 모든 주요 BI 도구 및 SQL 클라이언트는 Amazon Athena에서 사용할 수 있습니다. 쉬운 시각화를 위해 Amazon QuickSight를 사용할 수도 있습니다.

만약, 대용량의 구조화 된 데이터 집합에 대해서는 Amazon Redshift를 사용하는 것이 좋습니다. Redshift Spectrum은 원하는 형식으로 원하는 위치에 자유롭게 데이터를 저장할 수 있게 해주며, 필요시 언제든지 처리 할 수 ​​있으며, 클러스터 확장에 대해 걱정할 필요가 없습니다. 이를 통해 스토리지를 분리하고 계산할 수 있으므로 각 스토리지를 독립적으로 확장 할 수 있습니다. 동일한 Amazon S3 데이터 레이크에 대해 여러 개의 Amazon Redshift 클러스터를 실행하여 대량으로 동시성을 구현할 수도 있습니다. 즉, 자동으로 수천 개의 인스턴스로 확장되기 때문에, 쿼리가 테라 바이트, 페타 바이트 또는 엑사 바이트를 처리하든 상관없이 신속하게 실행됩니다. 이를 염두하시고 판단하시면 됩니다.

모범 사례 테스트 환경 설정

Amazon Redshift Spectrum을 시작하기 위한 전제 조건 및 단계에 대한 정보는 Redshift Spectrum 시작하기 문서를 참조하십시오.

모든 데이터 세트를 사용하여 테스트를 수행하여, 이 글에서 설명한 모범 사례를 검증 할 수 있습니다. 한 가지 중요한 요구 사항은 가장 큰 테이블의 S3 파일이 CSV 형식, 분할 Parquet, 비분할 Parquet 형식 등 세 가지 데이터 형식이어야 합니다. 한 파일 형식에서 다른 파일 형식으로 변환하는 방법은 아래 방법을 참고하시기 바랍니다.

외부 스키마 만들기
Amazon Athena 데이터 카탈로그를 메타 데이터 저장소로 사용하고, 다음과 같이 “spectrum”이라는 외부 스키마를 만듭니다.

create external schema spectrum 
from data catalog 
database 'spectrumdb' 
iam_role 'arn:aws:iam::<AWS_ACCOUNT_ID>:role/aod-redshift-role'
create external database if not exists;

Redshift 클러스터와 Amazon S3의 데이터 파일은 동일한 AWS 리전에 있어야합니다. Redshift 클러스터에는 Amazon Athena의 외부 데이터 카탈로그 및 Amazon S3의 데이터 파일에 액세스 할 수 있는 권한이 필요합니다. 클러스터에 연결된 AWS Identity and Access Management (IAM) 역할 (예 : aod-redshift-role)을 참조하여 해당 권한을 제공합니다. 자세한 내용은 Amazon Redshift 용 IAM 역할 만들기를 참조하십시오.

외부 테이블 정의
Partwise Parquet 파일을 사용하는 Amazon Redshift Spectrum 외부 테이블과 CSV 파일을 사용하는 다른 외부 테이블은 다음과 같이 정의됩니다.

CREATE  external table spectrum.LINEITEM_PART_PARQ ( 
 L_ORDERKEY BIGINT,
 L_PARTKEY BIGINT,
 L_SUPPKEY BIGINT,
 L_LINENUMBER INT,
 L_QUANTITY DECIMAL(12,2),
 L_EXTENDEDPRICE DECIMAL(12,2),
 L_DISCOUNT DECIMAL(12,2),
 L_TAX DECIMAL(12,2),
 L_RETURNFLAG VARCHAR(128),
 L_LINESTATUS VARCHAR(128),
 L_COMMITDATE VARCHAR(128),
 L_RECEIPTDATE VARCHAR(128),
 L_SHIPINSTRUCT VARCHAR(128),
 L_SHIPMODE VARCHAR(128),
 L_COMMENT VARCHAR(128))
partitioned by (L_SHIPDATE VARCHAR(128))
stored as PARQUET
location 's3://<your-bucket>/<xyz>/lineitem_partition/'
;

CREATE  external table spectrum.LINEITEM_CSV ( 
 L_ORDERKEY BIGINT,
 L_PARTKEY INT,
 L_SUPPKEY INT,
 L_LINENUMBER INT,
 L_QUANTITY DECIMAL(12,2),
 L_EXTENDEDPRICE DECIMAL(12,2),
 L_DISCOUNT DECIMAL(12,2),
 L_TAX DECIMAL(12,2),
 L_RETURNFLAG VARCHAR(128),
 L_LINESTATUS VARCHAR(128),
 L_SHIPDATE VARCHAR(128) ,
 L_COMMITDATE VARCHAR(128),
 L_RECEIPTDATE VARCHAR(128),
 L_SHIPINSTRUCT VARCHAR(128),
 L_SHIPMODE VARCHAR(128),
 L_COMMENT VARCHAR(128))
row format delimited
fields terminated by '|'
stored as textfile
location 's3://<your-bucket>/<xyz>/lineitem_csv/'

데이터 쿼리
요약하면, Amazon Redshift Spectrum은 외부 테이블을 사용하여 Amazon S3에 저장된 데이터를 쿼리합니다. 다른 Amazon Redshift 테이블과 동일한 SELECT 구문을 사용하여 외부 테이블을 쿼리 할 수 있습니다. 다만, 읽기 전용이므로 외부 테이블에 쓸 수 없습니다.

먼저 외부 데이터베이스를 참조하는 외부 스키마를 작성합니다. 외부 스키마는 Amazon Athena 데이터 카탈로그 또는 Amazon EMR과 같은 Apache Hive 메타 스토어에 있을 수 있습니다. 그런 다음 외부 스키마를 사용하여 Amazon Redshift에서 외부 테이블을 생성합니다. 테이블을 생성하고 Amazon Redshift로 읽어 올 필요 없이 테이블 이름 앞에 스키마 이름을 붙임으로써 SELECT 문에서 외부 테이블을 참조하면 됩니다.

외부 스키마는 외부 데이터 카탈로그의 데이터베이스를 참조합니다. 이를 위해서는 클러스터를 대신하여 Amazon S3 및 Amazon Athena에 액세스 할 수 있는 권한을 부여하는 IAM 역할이 필요합니다.

Amazon Redshift Spectrum을 사용하여 테스트를 수행하려면, 다음 두 가지 쿼리를 시작하는 것이 좋습니다.

QUERY 1:

SELECT l_returnflag,
       l_linestatus,
       sum(l_quantity) as sum_qty,
       sum(l_extendedprice) as sum_base_price,
       sum(l_extendedprice*(1-l_discount)) as sum_disc_price,
       sum(l_extendedprice*(1-l_discount)*(1+l_tax)) as sum_charge,
       avg(l_quantity) as avg_qty,
       avg(l_extendedprice) as avg_price,
       avg(l_discount) as avg_disc,
       count(*) as count_order
FROM lineitem
WHERE l_shipdate <= '1998-09-01'
GROUP BY l_returnflag, l_linestatus
ORDER BY l_returnflag, l_linestatus;

이 쿼리에는 하나의 테이블 만 포함되며 Amazon Redshift Spectrum 레이어에서 제공하는 추가 처리 성능을 강조 표시하는 데 사용할 수 있습니다.

QUERY 2:

SELECT  l_orderkey,
       sum(l_extendedprice * (1 - l_discount)) as revenue,
       o_orderdate,
       o_shippriority
FROM	customer, orders, lineitem
WHERE	c_mktsegment = 'BUILDING'
       AND c_custkey = o_custkey
       AND l_orderkey = o_orderkey
       AND o_orderdate < date '1995-03-15'
       AND l_shipdate > date '1995-03-15'
GROUP BY l_orderkey, o_orderdate, o_shippriority
ORDER BY revenue desc, o_orderdate
LIMIT 20;

이 쿼리에는 3 개의 테이블이 결합되어 Amazon Redshift Spectrum의 성능과 기본 Amazon Redshift의 성능을 비교하는 데 매우 유용합니다.

동시성 모범 사례

아래 모범 사례는 Amazon Redshift Spectrum을 사용하여 동시 작업 부하 성능을 최적화하는 데 도움이됩니다.

1. 스캔 집약적인 동시 작업 부하 향상
Amazon Redshift Spectrum은 클러스터와 독립적 인 전용 Amazon Redshift 서버에 있습니다. 조건부 필터링 및 집계와 같은 많은 컴퓨팅 집약적인 작업을 Redshift Spectrum에서 처리하기 때문에, 쿼리를 위한 클러스터 처리 용량을 훨씬 적게 사용합니다. 또한 Amazon Redshift Spectrum은 지능적으로 확장되기 때문에 쿼리 요구를 기반으로 잠재적으로 수천 개의 인스턴스를 사용하여 대규모 병렬 처리 (MPP)를 활용할 수 있습니다. 동시 스캔 및 / 또는 집약적 인 작업 부하의 일부 사용 사례의 경우 Amazon Redshift Spectrum이 평균 Amazon Redshift보다 우수한 성능을 보입니다.

모든 MPP 시스템에서 가장 자원이 많이 드는 과정이 바로 데이터 로딩 프로세스입니다. 이는 컴퓨팅 뿐 아니라 MVCC (Multiversion Concurrency Control)를 통해 테이블을 잠그는 것과 같은 능동적인 분석 쿼리와 경쟁하기 때문입니다. 그러나, Amazon Redshift Spectrum을 사용하여 Amazon S3에 작성한 새 외부 파일에 파일을 추가 한 다음 메타 데이터를 새 파티션으로 포함하도록 업데이트하면 Amazon Redshift 클러스터에서 이러한 부하가 제거됩니다. 이것은 동시성에 즉각적이고 직접적인 긍정적 영향을 주게 됩니다.

2. 다수 Redshift 온 디멘드 클러스터를 통한 동시성 확장
Redshift Spectrum은 Amazon S3에 데이터를 저장합니다. Amazon S3에 여러 Amazon Redshift 클러스터에서 접근하여 동시 작업 로드 성능을 향상 시킵니다. 일반적인 Redshift 고객은 업무 패턴과 관련 없이 많은 동시적 쿼리 작업 부하를 가지게 되는데,  Redshift Spectrum 이 나오기 전에는 동시성을 처리하기 위해 스냅샷을 복원하여 여러 개의 “읽기 전용”  클러스터를 만들어 두어야 했습니다. 이 접근법의 문제점은 수 테라 바이트의 데이터가 있는 DW의 경우 복원 프로세스가 오래 걸릴 수 있어 데이터 대기 시간 문제가 발생한다는 것입니다.

Amazon Redshift Spectrum을 사용하면 가장 큰 테이블을 Amazon S3로 옮길 수 있으며, 각 Amazon Redshift 클러스터는 로컬 디스크에 적은 양의 데이터만 보관합니다. 데이터 양이 줄어들기 때문에 까다로운 쿼리 작업 부하를 처리하기 위한 “읽기 전용” 클러스터를 생성 및 복원하는 것이 훨씬 빠릅니다 (그림 1 참조). 비용을 줄이려면 이러한 “온-디멘드” 클러스터를 작업후 바로 종료하면 됩니다.

그림 1:  다중 읽기 전용 Amazon Redshift 클러스터에서 Redshift Spectrum 공유하기

Amazon Redshift 고객은 pgbouncer-rr을 사용하여, 여러 Redshift 클러스터를 배포 할 때 클라이언트 쿼리 라우팅을 단순화하고 제어하여 동시성을 확장할 수 있습니다. 자세한 내용은 Amazon Redshift 및 PostgreSQL을위한 pgbouncer-rr 소개 : Query Routing and Rewrite (영문)를 참조하십시오.

스토리지 모범 사례

스토리지 최적화 고려 사항에서는 모든 단계에서 I/O 워크로드를 줄이는 것이 좋습니다. 이는 각 스토리지 블록에 더 많은 레코드를 맞추기 위해 압축을 사용하고 데이터 파티셔닝을 지원하는 형식을 사용하여 컬럼 기반 파일 형식을 사용해야 합니다. Amazon Redshift Spectrum에서 지원되는 파일 형식으로는 CSV, TSV, Parquet, Sequence 및 RCFile이 있습니다.

추가적인 최적화 방법은 압축을 사용하는 것입니다. 현재 Amazon Redshift Spectrum은 Gzip, Snappy 및 BZ2를 지원합니다.

3. 성능 향상과 비용 절감을 위해 Apache Parquet 파일 사용

Apache Parquet은 데이터 처리 프레임 워크, 데이터 모델 또는 프로그래밍 언어의 선택 여부와 상관없이 Apache Hadoop의 모든 프로젝트에서 사용할 수 있는 컬럼 형식 저장소 형식입니다. 자세한 내용은 Apache Parquet 정보 페이지를 참조하십시오.

Redshift Spectrum은 S3에서 쿼리에 필요한 파일의 컬럼(Column)만을 읽으며, 쿼리 당 S3에서 스캔되는 데이터의 양에 따라 요금을 부과합니다. 따라서, Parquet 형식의 데이터는 컬럼 형식으로만 저장하므로,  스캔 중에 불필요한 데이터를 제거 할 수 있습니다. 예를 들어, CSV 텍스트 파일과 Parquet 파티션 파일 간의 쿼리 성능 차이를 비교하면 바로 알 수 있습니다. 여러 가지 테스트 결과에 따르면 파티션 된 Parquet 파일은 성능이 빠르고 비용 효율적입니다.

SVL_S3QUERY_SUMMARY를 사용하면 분할 된 Parquet 파일을 사용하는 쿼리에 대한 흥미로운 S3 측정값에 대한 통찰력을 얻을 수 있습니다.

select * from SVL_S3QUERY_SUMMARY where query=<Query-ID>;

s3_scanned_rows 및 s3query_returned_rows 등 두 가지 측정 항목에  주의하십시오. CSV 파일과 비교할 때 최종 처리를 위해 Redshift Spectrum에서 Redshift 네이티브로 반환 되는 데이터의 양이 엄청나게 줄어들 것입니다.

4. 자주 사용하는 칼럼에 대한 Parquet 파일 분할

최적의 파티션 칼럼을 정할 때는 아래 사항을 고려하시기 바랍니다.

  • 공통 필터로 사용되는 칼럼을 선택합니다.
  • 과도하게 세분화 된 파티션은 스캔 시간이 증가될 수 있으나, 파티션 정리에 도움이 되고 S3에서 스캔 한 데이터의 양을 줄일 수 있습니다.
  • 실제 성능은 파일 배치, 쿼리 패턴, 파일 크기 분포, 파티션에 있는 파일 수, 적합한 파티션 수 등에 따라 달라질 수 있습니다.
  • 칼럼을 분할 할 때, 데이터가 잘 분할되고 있는지 모니터링하시기 바랍니다.
  • 파일 크기 분포가 가능한 한 균일해야 합니다. 즉, 한 개의 1GB 파일과 6 개의 256MB 파일보다는 256MB Parquet 파일 10 개로 처리하는 것이 좋습니다.

파티션 정리 (partition pruning)의 이점을 살펴보려면, Parquet 형식을 사용하여 두 개의 외부 테이블을 작성하는 것을 고려해야 합니다. 하나의 테이블은 파티션하지 않고, 다른 파티션은 일별로 분할합니다.

파티션한 테이블 스캔은 파티션 하지 않은 테이블보다 2~4 배 빠릅니다.

“파티션 정리”가 유효한 지 알아보려면, SQL을 사용하여 파티션 정리의 효율성을 분석 할 수 있습니다. 쿼리가 몇 개의 파티션에만 적용하여, 실제 예상대로 작동하는지 확인할 수 있습니다.

SELECT query,
	segment,
	max(assigned_partitions) as total_partitions,
	max(qualified_partitions) as qualified_partitions 
FROM svl_s3partition 
WHERE query=<Query-ID>
GROUP BY 1,2;

클러스터 설정 모범 사례

5. 올바른 클러스터 구성으로 Redshift Spectrum 성능 최적화

Amazon Redshift Spectrum 쿼리에는 두 가지의 Amazon S3 요청 병렬 처리 방식이 있습니다.

  • 쿼리 수준 (슬라이스 쿼리 당 최대 10 개) 숫자는 실행 중인 동시 쿼리 수에 따라 상이함
  • S3 스캔에 사용되는 스레드 수에 따른 작업

노드 수준 (노드에서 실행되는 모든 S3 쿼리, 노드 유형에 따라 상이함)노드 인스턴스 타입에 따라 상이함
간단한 계산 방법은 다음과 같습니다. “총 파일 수 <= 쿼리당 병렬 처리 수 (예 : 10) * 총 슬라이스 수” 일 때, 더 많은 노드를 가진 클러스터를 만들어도 성능이 향상되지 않을 수 있습니다. 좋은 방법은 Amazon Redshift Spectrum 테이블에 있는 파일 수를 확인하는 것입니다. 그리고, 특정 클러스터 크기 (슬라이스 관점에서)까지 추세를 측정하여 클러스터 노드 수가 증가하는 경우에도 성능이 더 이상 올라가지 않을 때를 확인합니다. Amazon Redshift 클러스터의 최적의 크기 (주어진 노드 유형에 대한)는 더 이상의 성능 향상을 얻을 수 없는 지점입니다.

쿼리 성능 모범 사례

몇 가지 간단한 기술을 사용하여 Amazon S3에서의 쿼리 성능을 향상시킬 수 있습니다.

6.  신속하게 스캔 및 집계가 필요한 쿼리에 주로 활용하기
Query 1과 같은 조인(Join)이 없는 특정 쿼리에서 성능은 일반적으로 검색 속도와 같은 물리적 I/O 비용에 의해 좌우됩니다. 이러한 쿼리의 경우, Redshift Spectrum이 Redshift보다 빠를 수 있습니다. 반면에 쿼리 2와 같이 여러 테이블 조인이 포함될 경우, 로컬 스토리지를 사용하는 매우 최적화 된 네이티브 Redshift 테이블이 훨씬 성능이 좋습니다.

7.  조건절(Predicate) 푸시 다운으로 S3 쿼리 성능 향상
Amazon Redshift Spectrum 수준 (S3 스캔, 프로젝션, 필터링 및 집계)에서 수행되는 처리는 개별 Amazon Redshift 클러스터와는 독립적이고, Redshift 클러스터의 리소스를 사용하지 않습니다.

따라서, Redshift Spectrum 에서 푸시 다운 할 수 있는 특정 SQL 작업이 있습니다. 가능한 한 이를 활용하고 싶다면, 다음 몇 가지 예를 참고하시기 바랍니다.

  • GROUP BY 절 및 일부 문자열 함수
  • LIKE와 같은 조건부 조건 및 패턴 일치 조건
  • COUNTSUMAVGMINMAX 및 기타 많은 공통 집계 함수
  • regex_replace 및 기타 많은 함수

DISTINCT 및 ORDER BY와 같은 특정 SQL 작업은Redshift Spectrum으로 푸시 다운 될 수 없기 때문에 Redshift에서 수행해야 합니다. 가능한 경우 사용을 최소화하거나 사용하지 않아야 합니다.

다음 두 가지 쿼리를 사용하여 테스트를 수행하면 큰 차이가 있음을 알 수 있습니다.

Select MIN(L_SHIPDATE), MAX(L_SHIPDATE), count(*)
	from spectrum.LINEITEM_NPART_PARQ;
Select MIN(DATE(L_SHIPDATE)), MAX(DATE(L_SHIPDATE)), count(*)
        from spectrum.LINEITEM_NPART_PARQ;

자연 스럽게 왜 그런지 의문이 듭니다.첫 번째 쿼리에서는 S3 Aggregate가 Redshift Spectrum으로 푸시되고, 집계 된 결과만 최종 처리를 위해 Amazon Redshift로 반환됩니다.

반면에 두 번째 쿼리를 면밀히 살펴보면 Redshift Spectrum이 DATE를 일반 데이터 형식 또는 DATE 변환 함수로 지원하지 않았기 때문에 Redshift Spectrum 계층에서 S3 집계가 없음을 알 수 있습니다. 결과적으로 이 쿼리는 S3에서 대용량 데이터를 Redshift로 직접 가져와 변환 및 처리를 해야합니다.

또 다른 대안적인 방법은 두 SQL 문에 대한 SVL_S3QUERY_SUMMARY 시스템 뷰 (s3query_returned_rows 컬럼)에 대해 쿼리하는 것입니다. Redshift Spectrum에서 Redshift로 반환되는 행(row)수에서 큰 차이가 있다는 점을 알게 될 것입니다.

8. DISTINCT를 GROUP BY로 바꾸기

GROUP BYMIN/MAX/COUNT 등과 같은 특정 SQL 연산자는 Redshift Spectrum 계층으로 푸시 다운 할 수 있습니다. 다만, DISTINCT 및  ORDER BY와 같은 다른 SQL 연산자는 푸시 다운 할 수 없습니다. 일반적으로 Redshift Spectrum을 지원하는 강력한 인프라 때문에 푸시 다운 할 수 있는 모든 작업의 성능이 Redshift 대비 향상됩니다.

예를 들어, 다음 두 기능적으로 동일한 SQL 문을 테스트해보시기 바랍니다.

SELECT DISTINCT l_returnflag,
        l_linestatus 
FROM 	spectrum.LINEITEM_PART_PARQ 
WHERE 	EXTRACT(YEAR from l_shipdate::DATE) BETWEEN '1995' AND  '1998' 
ORDER BY l_returnflag, l_linestatus
;

SELECT l_returnflag,l_linestatus 
FROM 	spectrum.LINEITEM_PART_PARQ 
WHERE EXTRACT(YEAR from l_shipdate::DATE) BETWEEN '1995' AND  '1998' 
GROUP BY l_returnflag, l_linestatus 
ORDER BY l_returnflag, l_linestatus
;

DISTINCT로 인해 첫 번째 쿼리에 푸시 다운은 없습니다. 대신 Amazon Redshift에 다량의 행(row)이 반환 및 정렬됨으로서 중복을 제거합니다. 두 번째 쿼리에서 S3 HashAggregate 는 Redshift Spectrum으로 푸시됩니다. 여기서는 대부분 무거운 작업 및 집계를 수행합니다. SVL_S3QUERY_SUMMARY에 대한 질의 계획상 차이점을 확인할수 있습니다.

여기서 우리는 가능하면 SQL 문에서 “DISTINCT“를 “GROUP BY“로 대체하면 좋다는 사실을 알 수 있습니다.

테이블 대체에 대한 모범 사례

아래 간단한 지침은 최고의 성능을 위해 테이블을 저장할 최적의 위치를 결정하는 데 도움을 줄 것입니다.

9. S3에 큰 팩트 테이블을 넣고 Redshift에 다른 팩트 테이블 두기

3 개의 테이블 조인이 있는 Query 2를 생각해 보겠습니다. 자연스럽게 세개의 테이블 모두가 S3에서 분할 된 Parquet 파일로 되어 있는 경우 어떻게 될까요? 일반적으로 Amazon Redshift에서 세 개의 테이블 모두 사용하는 것보다 성능이 좋을까요 아니면 나쁠까요?

조인(Join) 최적화 된 Amazon Redshift 테이블 세트 (적절한 분배 및 정렬 키 포함)가  Redshift Spectrum보다 성능면에서 뛰어 납니다. Redshift Spectrum 외부 테이블은 통계를 지원하지 않습니다. 데이터베이스 엔진은 추론 또는 간단한 행 수를 사용하여 조인 순서를 결정합니다. 어떤 경우에는 이것이 최적의 방법이 아닐 수 있습니다. AWS의 권장 사항은 Amazon S3에 가장 큰 팩트 테이블만 넣고,  중간 혹은 작은 크기의 테이블은 edshift에 남겨 두는 것입니다. 이렇게 하면 최적화 프로그램을 가장 효과적으로 활용할 수 있습니다.

최근에 CREATE EXTERNAL TABLE 및 ALTER TABLE 명령에서 TABLE PROPERTIES 절을 사용하여 테이블 통계 (numRows)를 설정하는 지원을 추가했습니다. 이를 활용하여 테이블의 정확한 행 번호를 설정하고, 최적의 쿼리 실행 계획을 생성하도록 프로그램에 지시 할 수 있습니다. 자세한 내용은 Amazon Redshift 설명서의 CREATE EXTERNAL TABLE을 참조하십시오.

적어도 세 개의 외부 테이블을 포함하는 추가 쿼리를 정의하고, 올바른 조인 순서 (Explain을 활용 가능)를 사용하여 실행하도록 요청합니다. Amazon Redshift Spectrum을 사용하여 여러 개의 외부 테이블을 절대 결합해서는 안된다는 결론을 성급히 내리지 않도록 하기 위함입니다.

10. 자주 조인하는 대형 테이블을 S3에 넣을 때 조심하기

Amazon Redshift는 Query 2처럼 보이는 질의에 대해서 Redshift Spectrum에서는 많은 동시성 레벨에서 거의 3 배 이상 높은 성능을 보일 수 있습니다. Query 1과 Query 2의 차이점은 Query 1에서 하나의 테이블에 대한 집계 연산만, Query2에서는 비교적 큰 세 개의 테이블 조인 된다는 점입니다.

좀 더 명확하게 말하자면, 성능 차이의 주요 원인은 Amazon Redshift에서 조인이 실행 되기 때문입니다. 조인하는 모든 데이터는 먼저 S3에서 로드되어 Amazon Redshift 클러스터의 개별 슬라이스로 즉시 배포되어야 합니다. 따라서 Amazon Redshift 로컬 스토리지에 접근할 때 보다 Redshift Spectrum을 사용하면 지연 시간이 현저하게 길어집니다.

따라서 조인을 자주하는 서 너개의 테이블이 Amazon Redshift에 있고, 이들 쿼리 작업 부하가 엄격한 SLA의 영향을 받는 경우, 이들은 Amazon S3에 두지 않는 것이 나을 수 있습니다.

마무리

이 글은 Amazon Redshift Spectrum의 성능을 향상시키는 몇 가지 중요한 모범 사례를 설명하였습니다. 각 경우는 특이하기 때문에 모범 사례에 맞는 권장되는 특정 상황에 적용에 대한 테스트를 직접해야 합니다. 질문이나 제안 사항이 있으시거나, Amazon Redshift 클러스터 최적화에 대한 추가 지원이 필요하면 AWS  기술팀에 문의하십시오.

이 글은 AWS 프로페셔널 서비스팀의 빅데이터 컨설턴트로 있는 Po Hong 박사와 Peter Dalton 컨설턴트가 작성하였으며, AWS 빅데이터 블로그의 10 Best Practices for Amazon Redshift Spectrum의 한국어 번역입니다.




Alibaba는 원래 KVM을 쓰고 있었는데... 선견지명인가;;;;


어째든 AWS덕분에 HyperVisor도 오픈소스 KVM이 탄력을 받을 듯하다.


http://www.ddaily.co.kr/news/article.html?no=162267

[디지털데일리 백지영기자] 세계 최대 클라우드 서비스 업체인 아마존웹서비스(AWS)가 C5 인스턴스를 새롭게 발표하면서 젠(Xen) 대신 KVM 기반 하이퍼바이저를 사용했다고 밝혀 주목된다.

그동안 AWS은 가상머신(VM) 제공을 위한 하이퍼바이저로 오픈소스인 젠을 활용해왔다. 하지만 이번 KVM 채택을 시작으로 향후 이를 다른 제품까지 확장할 계획이어서 귀추가 주목된다.

최근 AWS가 발표한 새 인스턴스는 배치 처리와 같은 컴퓨트 집약적인 워크로드나 분산 분석, 고성능컴퓨팅(HPC), 비디오 인코딩 등을 위해 디자인됐다. 기존 C4 인스턴스에 비해 가격 대비 성능이 25% 향상됐다. 총 6가지 형태로 출시됐다.

AWS 측은 “네트워킹과 스토리지, 컴퓨팅이 최대의 성능을 낼 수 있도록 오랜기간 동안 AWS 자체적으로 디자인한 하드웨어에 집중해 왔다”며 “C5가 이같은 연구의 결과물이며, 이번 새 하이퍼바이저를 추가하며 이를 극대화했다”고 설명했다.

또 각 vCPU는 3.0GHZ 속도의 인텔 제온 플래티넘 8000시리즈를 기반으로 했다. 인털 터보부스트 기술을 활용할 경우 하나의 코어에서 3.5GHz까지 구동이 가능하다.

이번 AWS의 KVM 하이퍼바이저 채택으로 ‘젠’ 진영의 위축이 예상된다. 젠은 AWS 덕분에 퍼블릭 클라우드 서비스 시장에서 가장 많이 사용되는 하이퍼바이저로 위상을 누려왔다. AWS 측은 관련 내용을 이달 말 열리는 AWS 리인벤트 행사에서 발표할 예정이다.

한편 새 C5 인스턴스는 현재 미국 동부(북부 버지니아)와 서부(오레곤), EU(아일랜드)에사 사용 가능하다.

<백지영 기자>jyp@ddaily.co.kr

포털에서 파일 스토리지 주문 후 

주문된 파일 스토리지 세부 내용으로 들어가서 

"호스트 권한 부여" 메뉴 선택 후 접근할 서버들을 추가함


또는 아래 커맨드로 생성 후 호스트 권한 부여

slcli file volume-order --storage-type endurance --size 100 --tier 4 --location seo01 --snapshot-size 100 --billing hourly

slcli file access-authorize -v 51497695 40209179

(slcli file access-authorize -v VMID VID


아래 커맨드

#nfs프로그램 설치

yum -y install nfs-utils nfs-utils-lib


#마운트할 디렉토리 생성

mkdir /data


#/etc/fstab 파일을 열고 마지막에 아래 내용 추가 후 저장 (앞쪽 nfs서버주소는 포털에서 확인) , nfs4.1로 바뀌면서 sec=sys를 안하면 write가 안되므로 꼭 쓰도록 하자.

vi /etc/fstab

nfsseo0101c-fz.adn.networklayer.com:/IBM01SEV1511949_1   /data    nfs4    hard,intr,rw,sec=sys    0 0


#/etc/fstab 내용을 실제로 마운트 시킴

mount -a


IBM Bluemix Load Balancer

  • 애플리케이션 서버 팜 앞에 로드 밸런서를 배치하여 애플리케이션의 가용성과 성능을 향상시킵니다. 
  • 애플리케이션 서버의 상태를 모니터링하고 개별 서버 장애로부터 보호합니다. 
  • 관리는 직관적인 그래픽 인터페이스와 API를 사용하여 쉽게 사용할 수 있습니다. 
  • 무엇보다도 사용하는 것에 대해서만 지불하면 됩니다.

특징들

종량제 가격 책정

로드 밸런서 사용 시간 및 처리 된 데이터를 기준으로 매월 사용한 양에 대해서 만 비용을 지불하면 됩니다.

Offload SSL handshake

SSL 오프로드를 사용하면 서버 자원을 실제 애플리케이션 처리하는 데만 집중할 수 있습니다.
암호화로 인한 서버 자원을 낭비할 필요가 없습니다.

프리미엄 Layer-4

최종 사용자 데이터 트래픽을 여러 응용 프로그램 서버에 지능적으로 배포하고 최종 사용자 환경을 향상시킵니다. 가상 및 베어 메탈 서버을 모두 지원하며,  HTTP, HTTPS 및 TCP 기반 애플리케이션을 위한 Layer-4 스위칭을 수행합니다.

지능형 트래픽 분산

라운드 로빈 (round-robin), 가중 라운드 로빈 (weighted round-robin) 및 최소 연결(least connections)을 사용하여 트래픽을 균형있게 조정할 수 있습니다.

신속한 서버 장애 감지

서버 상태를 정기적으로 모니터링하여 다운된 서버로의 트래픽 전송을 방지합니다.

고급 트래픽 관리

애플리케이션 트래픽 흐름에 맞게 세션 지속성(Session Persistence, 소스 IP 기반)을 설정하거나 VIP포트당 최대 연결 한도를 설정 할 수 있습니다.


비용

다음 메트릭의 실제 소비량에 대해 청구합니다. (아래 SEO01 기준)

MetricDescription

단가*

Service usage (in hours)

이 서비스가 한 달에 몇 시간 동안 사용됩니까?

$0.028 per hour
Data processed (in Gigabytes GB)

해당 월에 LB가 처리 한 총 데이터 량은 얼마입니까?

$0.009 per GB

아웃 바운드 인터넷/공용 대역폭에는 표준 데이터 전송 요금이 부과됩니다. (SEO01 : $0.12 per GB)


SoftLayer 네트워크에는 
퍼블릭 네트워크(인터넷망)과 프라이빗 네트워크(사설망) (10.0.0.0/8)가 있습니다. 
퍼블릭 네트워크를 통해 통신 과금이 발생하는 경우가 있습니다. 
서버에 데이터를 업로드하는 분은 무료입니다만 
서버에서 데이터를 다운로드 (아웃 바운드) 통신 과금 대상이됩니다. 
간단하게 생각하면 Public Interface에서 나가는 트래픽은 과금 대상입니다. (VM 및 Baremetal)

아웃 바운드 통신은 서버 1 대 1 달 다음 무료 프레임이 있습니다.

  • 물리적 서버는 500GB
  • 가상 서버는 250GB
  • 네트워크 어플라이언스 (Vyatta / Citrix NetScaler VPX)은 20TB
    • ※ 어플라이언스는 만약을 위해, 구입 전에 티켓에 확인하는 것이 좋습니다. VPX는 무제한 이라는 얘기도 있습니다.

※ 방화벽은 Bandwidth 의한 청구하지 않습니다. 

즉, Hardware Firewall (Shared,Dedicated), Fortigate Security Appliance 모두 트래픽을 과금 하지 않습니다.
단, 트래픽의 양을 제한하는 기능을 사용할 수 있습니다. 
http://knowledgelayer.softlayer.com/faq/does-softlayer-charge-firewall-bandwidth

그것을 넘은만큼의 트래픽에 대해서는 DC에 대해 다음 요금이 발생합니다. 
서울 PoD는 $ 0.12/GB입니다. 
※ 다음의 값은 1TB의 Bandwidth를 구입할 때 까지의 단가와 동일합니다.

  • USA / Amsterdam / London / Frankfurt - $ 0.09 /GB
  • Canada / Paris / Milan / Singapore / Seoul - $ 0.12 /GB
  • Hong Kong / Tokyo / Australia - $ 0.14 /GB
  • Mexico - $ 0.18 /GB
  • Brazil / India - $ 0.25 /GB

통신량이 무료 범위를 크게 초과 할 이미 예상된다 있다면, 
사전에 데이터 통신량을 구입할 수 할인됩니다. 물리적 서버의 경우 5T 이상에서 거래 ) 
(1000GB을 구입 및 500GB 무료 + 500GB 종량 과금 동일한 금액)

무제한 Unlimited Bandwidth (100 Mbps Uplink)의 가격은 다음과 같습니다.  100Mbps만 제공합니다.
- USA / Amsterdam / London / Frankfurt - $ 2000 
- Canada / Paris / Milan / Singapore / Seoul - $ 2660 
- Hong Kong / Tokyo / Australia - $ 3120
- Mexico - $ 4000 
- Brazil / India - $ 5560

추가 Bandwidth 용량이 필요하신 분은 1TB로 구분하여 티켓을 통해 주문 가능합니다. 
http://knowledgelayer.softlayer.com/faqs/56#671

How can I get additional bandwidth for my server 
The best way to purchase additional bandwidth for your server is to open a "Sales"ticket, requesting additional bandwidth. Please specify the amount of additional bandwidth and the server you are requesting the bandwidth for 
Note : Bandwidth is only available in 1000GB increments or as an unmetered service .

또한 무상 프레임의 2 배를 초과하면 즉시 종량 과금하고 무상 프레임의 2 배 이내이면 추가 분은 다음달에 청구됩니다.
http://knowledgelayer.softlayer.com/faq/how-much-do-you-charge-bandwidth-overages

If you exceed twice the amount of bandwidth you are allotted, we will automatically charge you for excess bandwidth used at the time. If you exceed your allotment by less than twice the allowance, the overages will be added to your next monthly invoice.

Bandwidth는 풀링 할 수 있습니다. 즉 각 서버들의 트래픽을 모아서 하나의 풀 안에서 꺼내어 쓸 수 있습니다.
다만, Pooling하려면 서버마다 $ 25 필요합니다. 
Unlimited Bandwidth를 포함 할 수는 없습니다.


다음은 vRouter 5400과 vRouter 5600의 차이점을 설명하고 있습니다. 
앞서 언급 한 바와 같이, 불행히도 공식 마이그레이션 가이드 같은 것은 존재하지 않기 때문에 전반적인 포괄적인 가이드를 하기에는 어려운 상황입니다.

5. 인터페이스

vRouter 5600에서는 컨트롤 플레인과 데이터 플레인이 분리된 DPDK를 이용하기 때문에 인터페이스가 아래처럼 각각 변경되었습니다.

  • eth0, eth1, eth2, eth3 -> dp0s0, dp0s1, dp0s2, dp0s3
  • bond0, bond1 -> dp0bond0, dp0bond1

그리고 vRouter 5400에서 eth0과 eth2이 bond0으로 eth1과 eth3가 bond1으로 각각 LACP로 구성하고 있던 것처럼,
vRouter 5600에서는 dp0s0와 dp0s2이 dp0bond0으로 dp0s1과 dp0s3이 dp0bond1으로 각각 LACP 구성하고 다음과 같이 옵션이 변경되었습니다.

  • hash-policy -> vRouter 5600에서는 폐지
  • mode 802.3ad -> mode lacp

또한 VRRP는 다음과 같이 변경됩니다.

  • rfc3768-compatibility -> rfc-compatibility
  • VRRP 광고 간격을 나타내는 advertisement 값은 vRouter 5400에서는 bond0/bond1에 주문 후 생성된 초기 구성에서 명시적으로 1 초에 설정되어 있습니다.
    vRouter 5600에서는 dp0bond0/dp0bond1에 주문 직후의 초기 구성은 설정되어 있지 않지만, 기본값은 1 초이므로 동작은 동일합니다.
    하지만 명시적으로 설정해 줄 것을 권장합니다.
5400의 구성 예
# show interfaces bonding bond0 
 address 10.132.50.92/26
 hash-policy layer3+4
 mode 802.3ad
 vif 1449 {
     address 192.168.0.1/24
     vrrp {
         vrrp-group 1 {
             advertise-interval 1
             preempt false
             priority 254
             sync-group vgroup1
             virtual-address 10.132.14.145/28
             virtual-address 10.133.101.113/28
             virtual-address 10.132.176.1/26
         }
     }
 }
 vrrp {
     vrrp-group 1 {
         advertise-interval 1
         preempt false
         priority 254
         rfc3768-compatibility
         sync-group vgroup1
         virtual-address 10.132.50.84/26
     }
 }
5600의 구성 예
# show interfaces bonding dp0bond0
 bonding dp0bond0 {
        address 10.132.50.92/26
        mode lacp
        vif 1449 {
                address 192.168.0.1/24
                vrrp {
                        vrrp-group 1 {
                                advertise-interval 1
                                preempt false
                                priority 254
                                sync-group vgroup1
                                virtual-address 10.132.14.145/28
                                virtual-address 10.133.101.113/28
                                virtual-address 10.132.176.1/26
                        }
                }
        }
        vrrp {
                vrrp-group 1 {
                        advertise-interval 1
                        preempt false
                        priority 254
                        rfc-compatibility
                        sync-group vgroup1
                        virtual-address 10.132.50.84/26
                }
        }
 }

또한 VRRP인터페이스는 RFC 규격에 따라 bondXvX 에서 dp0vrrpX 로 변경되어 있습니다. 이것은 show vrrp명령을 실행하는 것으로 확인할 수 있습니다.

5400
show vrrp
                                 RFC        Addr   Last        Sync
Interface         Group  State   Compliant  Owner  Transition  Group
---------         -----  -----   ---------  -----  ----------  -----
bond0             1      MASTER  yes        no     5s          vgroup1
bond0.1449        1      MASTER  no         no     5s          vgroup1
bond1             1      MASTER  yes        no     5s          vgroup1
bond1.1438        1      MASTER  no         no     7s          vgroup1

$ show vrrp detail | grep interface
  Virtual MAC interface:    bond0v1
  Virtual MAC interface:    bond1v1
5600
show vrrp
                                 RFC        Addr   Last        Sync
Interface         Group  State   Compliant  Owner  Transition  Group
---------         -----  -----   ---------  -----  ----------  -----
dp0bond0          1      MASTER  dp0vrrp2   no     5h2m59s     vgroup1
dp0bond0.1449     1      MASTER  no         no     5h2m59s     vgroup1
dp0bond1          1      MASTER  dp0vrrp1   no     5h2m59s     vgroup1
dp0bond1.1438     1      MASTER  no         no     5h2m59s     vgroup1

$ show vrrp detail|grep interface
  Virtual MAC interface:    dp0vrrp2
  Virtual MAC interface:    dp0vrrp1
  • VIF의 설정 방법은 기존과 동일합니다. rfc-compatibility는 native interface에만 설정하고 VIF는 TAG VLAN이므로 설정하지 않는다는것도 vRouter 5400 때와 동일합니다. (설정하면 VIP의 Arp Resolution이 실패합니다)
  • Vyatta의 vrrp-group 번호와 sync-group 번호도 vRouter 5400 때와 동일하게, IBM Cloud에서 할당 해 준 것을 최대한 이용해야 합니다. 사용자가 변경 했을 때, 만약 Vyatta의 HA 구성이 여러 세트로 준비 된 경우 나중에 도입 된 다른 세트의 vRouter에 할당 된 vrrp-group 번호가 중복되어 vrrp의 flapping이 발생하여 통신 불가에 빠질 수 있습니다. 만약 사용자가 독자적으로 할당할 경우 중복이 일어나지 않도록 주의해야 합니다.
5400
set interfaces bonding bond0 vif 1449 address 192.168.0.1/24
set interfaces bonding bond0 vif 1449 vrrp vrrp-group 1 advertise-interval 1
set interfaces bonding bond0 vif 1449 vrrp vrrp-group 1 preempt false
set interfaces bonding bond0 vif 1449 vrrp vrrp-group 1 priority 254 
set interfaces bonding bond0 vif 1449 vrrp vrrp-group 1 sync-group vgroup1
set interfaces bonding bond0 vif 1449 vrrp vrrp-group 1 virtual-address 10.132.14.145/28
set interfaces bonding bond0 vif 1449 vrrp vrrp-group 1 virtual-address 10.133.101.113/28
set interfaces bonding bond0 vif 1449 vrrp vrrp-group 1 virtual-address 10.132.176.1/26
5600
set interfaces bonding dp0bond0 vif 1449 address 192.168.0.1/24
set interfaces bonding dp0bond0 vif 1449 vrrp vrrp-group 1 advertise-interval 1
set interfaces bonding dp0bond0 vif 1449 vrrp vrrp-group 1 preempt false
set interfaces bonding dp0bond0 vif 1449 vrrp vrrp-group 1 priority 254 
set interfaces bonding dp0bond0 vif 1449 vrrp vrrp-group 1 sync-group vgroup1
set interfaces bonding dp0bond0 vif 1449 vrrp vrrp-group 1 virtual-address 10.132.14.145/28
set interfaces bonding dp0bond0 vif 1449 vrrp vrrp-group 1 virtual-address 10.133.101.113/28
set interfaces bonding dp0bond0 vif 1449 vrrp vrrp-group 1 virtual-address 10.132.176.1/26

 

6. SSH 서비스

vRouter 5400에서는 SSH 포트는 하나만 설정 가능했습니다. 그러나 vRouter 5600에서는 여러개의 포트를 설정 가능합니다. 만약 하나만 사용한다면 사용하지 않는 포트는 명시적으로 제거해야 합니다.

5400에서는 1개의 포트만 설정가능하기 때문에 최종적으로 20022 포트 하나만 사용 가능.
# set service ssh port 22
# set service ssh port 20022
# commit
# show service ssh                  
 port 20022
5600에서는 포트를 여러개 설정 가능하기 때문에 최종적으로 22와 20022 포트 둘다 사용 가능.
# set service ssh port 22
# set service ssh port 20022
# commit
# show service ssh
 ssh {
        port 20022
        port 22
 }

 

7. Firewall

vRouter 5400에서는 iptables 기반 (커널 기반) 이었지만, vRouter 5600에서는 사용자 영역(User Space)에서 제어하도록 구현되어 있습니다. 따라서 규칙의 설정 방법과 해석이 vRouter 5400과는 크게 변경되어 있습니다. 
Vyatta에서 Firewall은 반드시 사용하는 기능이므로 여기가 마이그레이션중 제일 어려운 곳이라고 생각됩니다.

7.1 설정 방법

vRouter 5400에서 set firewall로 설정하고 있었지만, vRouter 5600에서 set security firewall설정합니다.

5400
# set firewall 
Possible completions:
   all-ping     Policy for handling of all IPv4 ICMP echo requests
   broadcast-ping
                Policy for handling broadcast IPv4 ICMP echo and timestamp requests
   config-trap  SNMP trap generation on firewall configuration changes
 > group        Firewall group
   ip-src-route Policy for handling IPv4 packets with source route option
+> ipv6-name    IPv6 firewall rule-set name
   ipv6-receive-redirects
                Policy for handling received ICMPv6 redirect messages
   ipv6-src-route
                Policy for handling IPv6 packets with routing extension header
   log-martians Policy for logging IPv4 packets with invalid addresses
+> name         IPv4 firewall rule-set name
   receive-redirects
                Policy for handling received IPv4 ICMP redirect messages
   send-redirects
                Policy for sending IPv4 ICMP redirect messages
   source-validation
                Policy for source validation by reversed path, as specified in RFC3704
 > state-policy Global firewall state-policy
   syn-cookies  Policy for using TCP SYN cookies with IPv4
5600
vyatta@vga02# set security firewall 
Possible Completions:
   all-ping            Policy for handling of all IPv4 ICMP echo requests
   broadcast-ping      Policy for handling broadcast IPv4 ICMP echo requests
   config-trap         SNMP trap generation on firewall configuration changes
 > global-state-policy Configure global state parameters for firewall
+> name                Firewall ruleset
 > session-log         Session logging
   syn-cookies         Policy for using TCP SYN cookies with IPv4
   tcp-strict          Enable tcp strict stateful firewall rule


그리고 vRouter 5400는 하나의 인터페이스에 대한 in/out/local을 하나씩만 firewall을 설정할 수 있었지만, vRouter 5600에서는 다음 처럼 여러 개 지정할 수있게 되었습니다.

5400에서는 인터페이스마다 in/out/local에 대해 각각 1개씩만 firewall을 설정할 수 있다
# set interfaces bonding bond1 firewall in INTERNET-TO-LOCAL
# set interfaces bonding bond1 firewall in INTERNET
# set interfaces bonding bond1 firewall in SERVICE-ALLOW
# commit
# show interfaces bonding bond1 firewall 
 local {
     name SERVICE-ALLOW
 }
5600에서는 여러개를 설정 가능하다
# set interfaces bonding dp0bond1 firewall in INTERNET-TO-LOCAL
# set interfaces bonding dp0bond1 firewall in INTERNET
# set interfaces bonding dp0bond1 firewall in SERVICE-ALLOW
# commit
# show interfaces bonding dp0bond1 firewall 
 firewall {
        in INTERNET-TO-LOCAL
        in INTERNET
        in SERVICE-ALLOW
 }

7.2 인터페이스 기반 규칙 해석 순서

vRouter는 인터페이스 기반의 방화벽(Firewall)과 영역기반(zone-based) 방화벽이 있습니다. 인터페이스 기반의 방화벽은 vRouter 5400에서는 아래와 같이 iptable의 CHAIN과 동일하게 DNAT -> 방화벽(IN/OUT) -> SNAT 순서로 패킷이 처리되고 있습니다.


하지만, vRouter 5600에서는 다음과 같이 DNAT 전에 IN-방화벽이 먼저 평가됩니다.
Vyatta(로컬프로세스)에 대상 패킷이 도달하기 위해 IN-방화벽과 LOCAL-방화벽을 모두 통과해야만 한다는 것을 주의해야 합니다.
따라서 LOCAL로 접근하기 위해서는, vRouter 5400에서 기존 LOCAL-방화벽 설정을 IN-방화벽에 반영시킬 필요가 있습니다.
※ 앞서 얘기한 바와 같이 하나의 인터페이스에 여러개의 설정을 반영시킬 수 있기 때문에 vRouter 5400에서 LOCAL-방화벽으로 지정했던 정책을 vRouter 5600에서 IN-방화벽으로 지정하고 LOCAL-방화벽은 사용하지 않도록 해도 충분할 수 있습니다.


 

7.3 state policy의 global 옵션 설정

vRouter 5400에서는 iptables에서 사용하던 established/related 상태에 대한 설정을 global 수준에서만 지정 가능했습니다.
vRouter 5600에서는 TCP/UDP/ICMP 마다 stateful할지 여부를 지정할 수 있습니다.

5400
# set firewall state-policy 
Possible completions:
 > established  Global firewall policy for packets part of an established connection
 > invalid      Global firewall policy for packets part of an invalid connection
 > related      Global firewall policy for packets part of a related connection
# set firewall state-policy established action accept
# set firewall state-policy related action accept 
# set firewall state-policy invalid action drop
5600
# set security firewall global-state-policy 
Possible Completions:
   icmp enable icmp state monitoring for firewall
   tcp  enable tcp state monitoring for firewall
   udp  enable udp state monitoring for firewall
# set security firewall global-state-policy tcp 
# set security firewall global-state-policy udp
# set security firewall global-state-policy icmp

7.4 stateful firewall

vRouter 5400에서는 iptables에서 사용하던 established/related 상태에 대한 설정을 지정할 수 있었습니다. 또한 새 세션의 지정에 대해서는 new라는 상태를 이용했습니다.
vRouter 5600에서는 stateful하기 위해 단순히 state enable을 지정합니다. 새 세션의 지정에 관해서는 TCP에 관해서는 TCP Flag를 이용합니다.

vRouter5400의 방화벽 설정 예
# set firewall name INTERNET-TO-LOCAL default-action drop
# set firewall name INTERNET-TO-LOCAL rule 10 action accept
# set firewall name INTERNET-TO-LOCAL rule 10 state established enable
# set firewall name INTERNET-TO-LOCAL rule 10 state related enable
# set firewall name INTERNET-TO-LOCAL rule 20 action accept
# set firewall name INTERNET-TO-LOCAL rule 20 protocol vrrp
# set firewall name INTERNET-TO-LOCAL rule 30 action accept
# set firewall name INTERNET-TO-LOCAL rule 30 destination port 20022
# set firewall name INTERNET-TO-LOCAL rule 30 protocol tcp
# set firewall name INTERNET-TO-LOCAL rule 30 state new enable
# set interfaces bonding bond1 firewall local name INTERNET-TO-LOCAL
vRouter5600의 방화벽 설정 예
# set security firewall name INTERNET-TO-LOCAL default-action drop
# set security firewall name INTERNET-TO-LOCAL rule 10 action accept
# set security firewall name INTERNET-TO-LOCAL rule 10 state enable
# set security firewall name INTERNET-TO-LOCAL rule 10 protocol tcp
# set security firewall name INTERNET-TO-LOCAL rule 20 action accept
# set security firewall name INTERNET-TO-LOCAL rule 20 protocol vrrp
# set security firewall name INTERNET-TO-LOCAL rule 30 action accept
# set security firewall name INTERNET-TO-LOCAL rule 30 destination port 20022
# set security firewall name INTERNET-TO-LOCAL rule 30 protocol tcp
# set security firewall name INTERNET-TO-LOCAL rule 30 tcp flags SYN,!ACK,!FIN,!RST
# set interfaces bonding dp0bond1 firewall in INTERNET-TO-LOCAL

7.5 여러개의 port를 설정 하는 방법

vRouter 5400에서는 destination port를 직접 쓸 수 있습니다. (iptables의 multiport 옵션에 해당)
vRouter 5600에서는 명시적으로 port-group을 작성해서 사용 해야합니다.

5400
# set firewall name INTERNET-TO-LOCAL rule 30 destination port 80,443,10000-10010
5600
# set resources group port-group HTTPGROUP port 80
# set resources group port-group HTTPGROUP port 443
# set resources group port-group HTTPGROUP port 10000-10010
# set security firewall name INTERNET-TO-LOCAL rule 30 destination port HTTPGROUP

7.6 QOS / Traffic policy

5400에서는 QOS / Traffic policy 설정시 set traffic-policy를 사용했습니다.
5600에서는 set policy qos를 사용하거나 firewall rule에서 설정할 수 있습니다.

5400
set traffic-policy 
Possible completions:
+> drop-tail    Drop tail queue (FIFO) policy
+> fair-queue   Fair queuing policy
+> limiter      Traffic input limiting policy
+> network-emulator
                Network emulator policy
+> priority-queue
                Priority queuing based policy
+> random-detect
                Weighted Random Early Detect policy
+> rate-control Rate limiting policy
+> round-robin  Deficit round robin based policy
+> shaper       Traffic shaping based policy
5600
set policy qos name xxx shaper 
Possible Completions:
   bandwidth      Bandwidth limit
   burst          Burst size in bytes
+> class          Class number
   default        Qos profile for default traffic
   description    Description for this QoS policy
   frame-overhead Framing overhead
   period         Enforcement period (ms)
+> profile        QoS traffic profile
+> traffic-class  Traffic Class

# set security firewall name INTERNET-TO-LOCAL rule 40 police 
Possible Completions:
   bandwidth Bandwidth limit
   burst     Burst size in bytes
   ratelimit Ratelimit in packets/second.
 > then      Result for packets over police limit

8. NAT

예전에는 NAT는 set nat xxx로 설정했지만 앞으로는 set service nat xxx로 설정합니다.

5400
# set nat 
Possible completions:
 > destination  Destination NAT settings
 > source       Source NAT settings
5600
# set service nat 
Possible Completions:
   <Enter>      Execute the current command
 > destination  Destination NAT settings
 > ipv6-to-ipv4 IPv6 to IPv4 NAT settings
 > source       Source NAT settings

9. IPsec VPN

  • vRouter 5400에서 set vpn로 설정했던 것을 vRouter 5600에서는 set security vpn로 설정합니다.
  • IKEv2를 지원합니다. set security vpn ipsec ike-group IKEGROUP1 ike-version 2
  • IKE 실행 모드는 Main mode와 Aggressive mode의 2가지가 있습니다만, vRouter 5600에서도 Aggressive mode는 지원하지 않는 것 같습니다. 따라서 vRouter 5400 때와 마찬가지로 상대 기종에서는 Aggressive mode를 비활성화해야 합니다.
  • vRouter 5400에서는 ipsec-interfaces 의 지정이 필요했지만, vRouter 5600에서는 필요없습니다.
  • Site-to-Site VPN을 이용할 때는 prefix 지정으로 터널을 설정하는 방법과, VTI인터페이스를 설정하고 별도 라우팅을 설정하는 방법이 있습니다.
    • zone-based firewall을 이용하고있는 경우에는 prefix 지정 터널은 잘 동작하지 않는 것 같습니다. 만약 zone-based firewall을 이용하고있는 경우에는 VTI를 사용합시다.
    • prefix지정 VPN터널에서 흐르는 트래픽은 송신 원본 인터페이스가 불분명 하기 때문에 zone-based firewall에 의해 drop될 가능성이 있습니다.
5400
# set vpn ipsec                             
Possible completions:
   auto-update  Set auto-update interval for IPsec daemon.
   disable-uniqreqids
                Option to disable requirement for unique IDs in the Security Database
+> esp-group    Name of Encapsulating Security Payload (ESP) group
+> ike-group    Name of Internet Key Exchange (IKE) group
 > ipsec-interfaces
                Interface to use for VPN [REQUIRED]
 > logging      IPsec logging
 > nat-networks Network Address Translation (NAT) networks
   nat-traversal
                Network Address Translation (NAT) traversal
+> profile      VPN IPSec Profile
 > site-to-site Site to site VPN
5600
# set security vpn ipsec 
Possible Completions:
   <Enter>            Execute the current command
   auto-update        Set auto-update interval for IPsec daemon. [Deprecated]
   disable-uniqreqids <No help text available> [Deprecated]
+> esp-group          Name of Encapsulating Security Payload (ESP) group
+> ike-group          Name of Internet Key Exchange (IKE) group
 > logging            IPsec logging
 > nat-networks       Network Address Translation (NAT) networks
   nat-traversal      Network Address Translation (NAT) traversal [Deprecated]
+> profile            VPN IPSec Profile
 > site-to-site       Site to site VPN

 

10. OpenVPN

OpenVPN에 대한 설정 방법은 기본적으로 변경이 없습니다.

5400
# set interfaces openvpn vtun0
Possible completions:
 > auth         OpenVPN authentication method
 > bridge-group Interface to be added to a bridge group
 > client-bundle
                Generate SSL-VPN Client Bundles
   client-cert-not-required
                Client certificates not required
   description  Description for the interface
   device-type  OpenVPN interface device-type
   disable      Interface to be disabled
   encryption   Data encryption algorithm option
 > firewall     Firewall options
   hash         Hashing algorithm option
 > ip           IPv4 routing parameters
 > ipv6         IPv6 routing parameters
+> local-address
                Local IP address of tunnel
   local-host   Local IP address to accept connections (all if not set)
   local-port   Local port number to accept connections
   mode         OpenVPN mode of operation
+  openvpn-option
                Additional OpenVPN options
 > policy       Policy route options
   protocol     OpenVPN communication protocol
   redirect     Incoming packet redirection destination
   remote-address
                IP address of remote end of tunnel
 > remote-configuration
                Configure openvpn remote configuration
+  remote-host  Remote host to connect to (dynamic if not set)
   remote-port  Remote port number to connect to
 > replace-default-route
                OpenVPN tunnel to be used as the default route
 > server       Server-mode options
   shared-secret-key-file
                File containing the secret key shared with remote end of tunnel
 > tls          Transport Layer Security (TLS) options
 > traffic-policy
                Traffic-policy for interface
5600
 set interfaces openvpn vtun0
Possible Completions:
   <Enter>                  Execute the current command
 > auth                     OpenVPN authentication method
 > client-bundle            Generate SSL-VPN Client Bundles
   client-cert-not-required Client certificates not required
   description              Description for the interface
   device-type              OpenVPN interface device-type
   disable                  Interface to be disabled
   encryption               Data encryption algorithm option
 > firewall                 Firewall options
   hash                     Hashing algorithm option
 > ip                       IPv4 parameters
 > ipv6                     IPv6 parameters
   local-address            Local IP address or network address
   local-host               Local IP address to accept connections (all if not set)
   local-port               Local port number to accept connections
   mode                     OpenVPN mode of operation
+  openvpn-option           Additional OpenVPN options
   protocol                 OpenVPN communication protocol
   remote-address           IP address of remote end of tunnel
 > remote-configuration     Configure openvpn remote configuration
+  remote-host              Remote host to connect to (dynamic if not set)
   remote-port              Remote port number to connect to
 > replace-default-route    OpenVPN tunnel to be used as the default route
 > server                   Server-mode options
   shared-secret-key-file   File containing the secret key shared with remote end of tunnel
 > tls                      Transport Layer Security (TLS) options

 

11. conntrack module

vRouter 5400에서는 다음과 같이 conntrak모듈을 사용합니다.

5400
# set system conntrack expect-table-size xxx
# set system conntrack hash-size xxxx
# set system conntrack table-size xxx

 

12. root가되는 방법 / sudo 대해

vRouter 5400에서는 sudo -s 로 암호없이 root 사용자 수있었습니다. 그러나 vRouter 5600에서는 vyatta 사용자가 sudo를 실행할 권한이 없습니다. 이것은 vRouetr5600에 admin보다 더 상위의 권한 수준으로 superuser가 만들어졌기 때문입니다. vRouter 5400 처럼 vyatta 사용자가 sudo를 실행하기 위해서는 superuser로 변경해야 합니다.

5400에서는 admin/operator만 존재함
# set system login user vyatta level 
Possible completions:
   admin        Administrators
   operator     Operators
5600에서는 superuser가 추가됨
# set system login user vyatta level 
Possible Completions:
   admin    
   operator 
   superuser
5600에서 sudo실패 사례(level이 admin일 때)
$ sudo ls -l
[sudo] password for vyatta: 
Sorry, user vyatta is not allowed to execute '/bin/ls -l' as root on vga02.ibm.com.
5600에서 sudo실행 방법
# set system login user vyatta level superuser 
# commit

(ssh의 로그아웃/로그인을 해서 세션을 새로 맺음)
$ show login
login     : vyatta
level     : Superuser
user      : vyatta
groups    :  users adm systemd-journal vyattacfg vyattaadm wireshark
$ sudo ls -l
[sudo] password for vyatta: 
total 4
-rw-r----- 1 vyatta users 402 Jul 21 17:09 id_rsa.pub

그러나 sudo 실행시 비밀번호 입력을 요구하게됩니다. 비밀번호 입력없이 sudo를 실행하기 위해서는 /etc/sudoers를 편집해야 합니다.
시스템 설정을 직접 편집 하는 것은 vRouter의 지원 범위를 벗어나지 만, 아무래도 비밀번호 입력없이 sudo를 실행해야 한다면 다음 단계를 수행하면 됩니다.
(반복하지만 vRouter의 지원 대상에서 제외 되므로 이 변경 작업으로 인한 어떤 문제가 발생하더라도 책임 지지 않습니다!).
재부팅시 설정이 사라지지 않겠지만, 버전 업 등을 행한 경우 이 정보는 유실 되어 재구성이 필요할 수 있습니다.

sudo를 패스워드 없이 실행하는 설정
$ su -
Password:

# visudo
(下記を追記して保存)
vyatta  ALL=(ALL:ALL) NOPASSWD:ALL

# cat /etc/sudoers|grep vyatta
vyatta  ALL=(ALL:ALL) NOPASSWD:ALL

참고 : 버그

  • Version 5.2R5S3 에서 # set system login user vyatta level superuser를 한 번 설정 한 후 다시 # set system login user vyatta level superuser로 admin을 복원해도 $ show login 명령의 출력 결과는 Superuser 상태가되어 버리는 표시 버그가 있습니다.  "Bug ID : VRVDR-37958"로 등록되어 있으며 vRouter 5600 17.2 이상 (Yountville)에서 수정 예정입니다.

 

13. SSL/TLS의 버전

vRouter 5400에서는 TLS1.0 만을 지원하고 있으며, SSLv3, TLS1.1, TLS1.2은 지원하지 않습니다.
vRouter 5600에서는 TLS1.0, TLS1.1, TLS1.2을 지원하고 있으며, SSLv3는 지원하지 않습니다.

 

14. tcpdump

tcpdump를 캡처 할 때 어떤 인터페이스의 통신인지를 확인하는 것이 귀찮을 때 -i any를 사용하는 일이 자주 있습니다.vRouter 5400에서는 그렇게 해도 문제가 없었습니다만,
vRouter 5600에서 -i any 사용은 vRouter가 보낸 패킷은 캡처하고 주는데, vRouter를 통한 패킷(dataplane 이용)은 캡처를 하지 않으므로, 명시적으로 인터페이스를 지정할 필요가 있습니다.

5600에서 vRouter의 끝에 있는 서버에 ping을 쏘고 있어도 로그에 출력되지 않는다.
# tcpdump -D
1..spathintf [Up, Running]
2.dp0s0 [Up, Running]
3.dp0bond0 [Up, Running]
4.dp0s1 [Up, Running]
5.dp0bond1 [Up, Running]
6.dp0vrrp1 [Up, Running]
7.dp0s2 [Up, Running]
8.dp0vrrp2 [Up, Running]
9.dp0s3 [Up, Running]
10.dp0bond1.1438 [Up, Running]
11.dp0bond0.1449 [Up, Running]
12.any (Pseudo-device that captures on all interfaces) [Up, Running]
13.lo [Up, Running, Loopback]
14.nflog (Linux netfilter log (NFLOG) interface)
15.nfqueue (Linux netfilter queue (NFQUEUE) interface)
16.usbmon1 (USB bus number 1)
17.usbmon2 (USB bus number 2)

# tcpdump -i any icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

# tcpdump -i dp0s1 icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on dp0s1, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

# tcpdump -i dp0s3 icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on dp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

5600에서 똑같은 상황에서 인터페이스를 명시적으로 지정한 경우
# tcpdump -i dp0bond1 icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on dp0bond1, link-type EN10MB (Ethernet), capture size 262144 bytes
19:06:01.1499973371 IP 126.211.xx.xx > 161.202.121.202: ICMP echo request, id 25179, seq 837, length 64
19:06:01.1499973660 IP 126.211.xx.xx > 161.202.xx.xx: ICMP echo request, id 25179, seq 837, length 64
19:06:01.1499974001 IP 161.202.xx.xx > 126.211.xx.xx: ICMP echo reply, id 25179, seq 837, length 64
19:06:01.1499974034 IP 161.202.xx.xx > 126.211.xx.xx: ICMP echo reply, id 25179, seq 837, length 64
19:06:02.1500013612 IP 126.211.xx.xx > 161.202.xx.xx: ICMP echo request, id 25540, seq 838, length 64
19:06:02.1500013922 IP 126.211.xx.xx > 161.202.xx.xx: ICMP echo request, id 25540, seq 838, length 64
19:06:02.1500014498 IP 161.202.xx.xx > 126.211.xx.xx: ICMP echo reply, id 25540, seq 838, length 64
19:06:02.1500014539 IP 161.202.xx.xx > 126.211.xx.xx: ICMP echo reply, id 25540, seq 838, length 64
19:06:03.1500013463 IP 126.211.xx.xx > 161.202.xx.xx: ICMP echo request, id 25540, seq 839, length 64
19:06:03.1500013483 IP 126.211.xx.xx > 161.202.xx.xx: ICMP echo request, id 25540, seq 839, length 64
19:06:03.1500013870 IP 161.202.xx.xx > 126.211.xx.xx: ICMP echo reply, id 25540, seq 839, length 64
19:06:03.1500014086 IP 161.202.xx.xx > 126.211.xx.xx: ICMP echo reply, id 25540, seq 839, length 64
^C
12 packets captured
0 packets received by filter
0 packets dropped by kernel

# tcpdump -i dp0bond1.1438 icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on dp0bond1.1438, link-type EN10MB (Ethernet), capture size 262144 bytes
17:08:07.1500209525 IP 126.211.xx.xx > 161.202.xx.xx: ICMP echo request, id 43428, seq 184, length 64
17:08:07.1500210181 IP 161.202.xx.xx > 126.211.xx.xx: ICMP echo reply, id 43428, seq 184, length 64
17:08:08.1500213757 IP 126.211.xx.xx > 161.202.xx.xx: ICMP echo request, id 43428, seq 185, length 64
17:08:08.1500214394 IP 161.202.xx.xx > 126.211.xx.xx: ICMP echo reply, id 43428, seq 185, length 64
17:08:09.1500224574 IP 126.211.xx.xx > 161.202.xx.xx: ICMP echo request, id 43428, seq 186, length 64
17:08:09.1500225213 IP 161.202.xx.xx > 126.211.xx.xx: ICMP echo reply, id 43428, seq 186, length 64
17:08:10.1500219418 IP 126.211.xx.xx > 161.202.xx.xx: ICMP echo request, id 43428, seq 187, length 64
17:08:10.1500219745 IP 161.202.xx.xx > 126.211.xx.xx: ICMP echo reply, id 43428, seq 187, length 64
^C
8 packets captured
0 packets received by filter
0 packets dropped by kernel


+ Recent posts