Es irrt der Mench, solange er strebt.

서평 쓰기

■ AWS 서비스

AWS는 2022.08 기준 26개 기전과 84개의 가용 영역을 운영하고 있으면 우리나라는 서울 리전과 4개의 가용 영역이 있음.

※ 리전: 데이터센터가 집합된 물리적 위치

    가용영역(availability zone): 리전 내에 구성된 하나 이상의 개별 데이터 센터

▶ AWS 서비스 라인업

- 컴퓨팅, 스토리지, DB 등의 인프라부터 IoT, ML, 빅데이터 등 다양한 클라우드 서비스 제공.

1. AWS 컴퓨팅

가상 머신 생성, 비용 및 용량을 관리. Amazon EC2(Elastic Compute Cloud)

2. AWS 네트워킹 및 컨텐츠 전송

내/외부 통신을 하는 네트워크 서비스. VPC(Virtual Private Cloud), CloudFront, Route53 등

3. AWS 스토리지

Amazon S3(Simple Storage Service), Elastic File System(EFS), Elastic Block Store(EBS)

4. AWS 데이터베이스

Amazon RDS(Relational Database Service), Aurora, DynamoDB

5. AWS 보안 자격 증명 및 규격 준수

사용자 자격 증명과 접근 관리. 서비스와 자원에 대한 안전한 접근 관리.  AWS IAM(Identity & Access Management)

※ 과금: Pay per Use로 사용한 만큼 비용을 지불하는 형태로 서비스.

프리티어 관련 정책: https://aws.amazon.com/ko/free/ 

실습 - 단계별로 화면 캡쳐를 해 둬서 따라하기 쉽도록 되었습니다.

계정 생성 

■ AWS 컴퓨팅 서비스

주요 서비스

1. EC2

- 운영체제: 리눅스, 윈도우, macOS

- CPU옵션: Arm, x86

- 다양한 인스턴스 유형 제공: 범용 및 워크로드에 맞게 최적화 가능

- 구매옵션: 온디맨드, 예약 인스턴스, 스팟 인스턴스 등

1) EC2 인스턴스

EC2 인스턴스 유형 및 구조

인스턴스 유형 구조

t2.micro

t: 인스턴스 패밀리, 용도별 분류

2:  인스턴스 세대, 높을수록 최신 세대, 최신 세대는 성능 우수

micro: 인스턴스 크기, 크기가 커질수록 용량 및 가격 증가

인스턴스 상태, 수명 주기

'중지됨'과'종료됨'의 차이: '중지됨' 상태는 인스턴스를 유지한 채 일시적으로 중지한 상태이기 때문에다시 구동할 수 있으며 '종료됨'상태는 '인스턴스를 영구 삭제'하기 때문에 다시 사용이 어려움. '종료됨' 상태가 되어도 관리 콘솔상에서 바로 삭제되지는 않음.

2) AMI (Amazon Machine Image)

운영체제 + 소프트웨어 템플릿. 

새로 생성하거나 AWS Marketplace에서 제공하는 서드 파티용 AMI, AWS 자체적으로 정의된 기본 AMI 선택해서 사용.

3) Amazon EC2 스토리지

인스턴스 환경 설정후 어떤 저장소를 사용할 것인가 결정

- 인스턴스 스토어: EC2 인스턴스 기본 스토리지. 빠른 I/O, EC2 인스턴스를 중지하거나 종료하면 모두 손실됨.

- Amazon EBS: 외장하드와 비슷한 개념. 인스턴스가 직접 연결이 아닌 네트워킹을 통해 접근하여 연결되는 구조. 영구 보존 가능한 스토리지. 

4) EC2 네트워킹

- VPC: 퍼블릭 클라우드 안에서 논리적으로 격리된 가상의 클라우드 네트워크

- 네트워크 인터페이스: ENI(Elastic Network Interface)라는 논리적 네트워크 인터페이스가 VPC 내 생성되며 ENI를 EC2 인스턴스에 연결해서 네트워킹을 수행.

- IP주소: Private(사설) IP & Public(공인) IP

5) EC2 보안

- 보안 그룹: 인스턴스 송수신 트래픽을 제어하는 가상의 방화벽 역할

- 키페어: 인스턴스에 연결할 때 자격을 증명하는 보안 키. 퍼블릭키=EC2인스턴스에 저장, 프라이빗키=사용자컴퓨터

6) EC2 모니터링

목표, 대상자원, 빈도, 수행도구, 수행자, 경보 알림 대상 등 모니터링 계획을 정의해서 생성.

- 수동모니터링: 대시보드, Amazon CloudWatch 모니터링 서비스 이용.

- 자동모니터링: 대상 자원의 지표에 대해 임계값을 정하고, 임곗값을 초과하면 경보를 내리는 형태

※ 실습: EC2 인스턴스 배포 및 접근하기

01-4

파이썬 패키지 관리자 - pip

패키지 = 라이브러리

실행 - anaconda prompt

컴퓨터에 설치된 파이썬 라이브러리 확인

pip list

라이브러리 설치 및 제거

pip install (uninstall) 라이브러리 명

교재: 점프투파이썬

anaconda 설치 - 여러 패키지들을 포함하고 있는 파이썬 배포판?

설치 시 파이썬 프로그램도 같이 설치.

https://www.anaconda.com/products/individual#Downloads

파이썬 다운로드

https://www.python.org/downloads/

Python 소개

1990년 암스테르담의 귀도 반 로섬(Guido Van Rossum)이 개발한 인터프리터 언어.

● 반복문

○ 리스트와 반복문

파이썬의 리스트: 여러가지 자료를 자정할 수 있는 자료, 숫자나 문자, 수식 등이 개별적인 '자료'다면 리스트는 이러한                           자료들을 모아서 사용할 수 있게 해주는 형태의 자료를 말함.

리스트는 대괄호[ ] 내부에 여러 종류의 자료를 넣어 선언. 선언한 리스트를 출력하면 내부의 자료를 모두 출력.

- 리스트를 선언하고 요소에 접근

대괄호[ ] 안에 넣는 자료를 요소(element)라고 함. [요소, 요소, 요소 ...]

다음과 같이 리스트를 선언했다면

array = [35, 7, "문자열", True, False]

각 요소는 다음과 같은 형태로 저장됨

array

           [0]                    [1]                    [2]                     [3]                  [4]

[0], [1] ... = index

- 리트스 특정 요소 변경

- 대괄호 안에 음수를 넣어 뒤어서부터 요소를 선택할 수 있음

- 리스트 접근 연산자를 이중으로 사용하 수 있음.

array[2]를 지정하면 "문자열"을, array[2][0]을 지정하면 2번째서 가져온 문자열에서 다시 0번째를 가져와 출력

- 리스트 안에 리스트 사용

● Physical Storage

○ Data ONTAP Storage Architecture

○ Disk Type

○ Aggregate 생성 Workflow

1. aggregate auto-provision

auto-provisioning을 사용한 aggregate 생성은 ONTAP 9.2 이상에서 best practice 이지만 사용자 환경에서 지원되는지 여부를 확인해야 함. 지원하지 않는 경우 RAID 정책 및 디스크 구성에 대해 결정한 다음 수동으로 생성해야 함.

::>storage aggregate auto-provision 명령 사용

※ Default RAID policies

RAID-DP나 RAID-TEC가 새 aggregate에 대한 기본 RAID 정책.

RAID 정책은 디스크 오류 발생 시 사용하는 패리티 보호를 결정.

RAID-DP는 단일 또는 이중 디스크 오류 발생 시 이중 패리티(double-parity) 보호를 제공.

RAID-DP는 아래 aggregate type에 대한 기본 RAID 정책임.

1) All Flash Aggregates

2) Flash Pool Aggregates

3) Performance hard disk drive aggregates.

 - ONTAP 9.0부터는 RAID-TEC라는 새로운 RAID 정책을 사용할 수 있음

RAID-TEC는 AFF를 포함한 모든 디스크 유형과 모든 플랫폼에서 지원됨. 더 큰 디스크를 포함하는 Aggregate는 동시 디스크 오류 가능성이 더 높음. RAID-TEC은 3중 패리티 보호를 제공하여 데이터가 최대 3개의 디스크 오류가 발생하더라도 견딜 수 있도록 함.

RAID-TEC는 6TB 이상의 디스크를 사용하는 용량 HDD 집합에 대한 기본 RAID 정책임.

• Aggregate에 필요한 Disk나 Disk Partition 수를 결정하는 방법

- 시스템 요구 사항을 충족하려면 충분한 디스크 또는 디스크 파티션이 있어야 함.

- 데이터 손실 가능성을 최소화하려면 권장되는 수의 Hot Spare나 Hot Spare Disk Partition이 있어야 함.

- Root-data 파티셔닝은 특정 구성에서 기본적으로 활성화 됨. root-data 파티셔닝이 활성화 된 시스템은 디스크 파티션을 사용하여 Aggregate를 생성.

- root-data 파티셔닝이 활성화 되지 않은 시스템은 파티션 되지 않은 디스크?를 사용.

- RAID 정책에 필요한 최소 수를 충족하고 최소 용량 요구 사항을 충족하기에 충분한 디스크 또는 디스크 파티션이 있어야 함.

※ ONTAP에서 드라이브의 사용 가능한 공간은 드라이브의 물리적 용량보다 적음. 하드웨어 Universe에서 특정 드라이브의 사용 가능한 공간과 각 RAID 정책에 필요한 최소 디스크 또는 파티션을 찾을 수 있음.

::> storage aggregate show-spare-disks

- RAID Group를 만들고 용량 요구 사항을 충족하는데 필요한 디스크나 디스크 파티션의 수 외에도 Aggregate에 권장되는 최소 Hot Spare나 Hot Spare Disk partition이 있어야 함.

- 모든 Flash Aggregate는 최소 하나의 Hot Spare나 Hot Spare Disk partition이 있어야 함.

- non-flash Aggregate의 경우 최소 2개의 Hot Spare나 Hot Spare Disk partition이 있어야 함.

- Maintenance Center를 지원하고 여러 동시 디스크 장애로 인한 문제를 방지하려면 multi-disk carrier에 최소 4개의 Hot Spare가 있어야 함.

2. 수동으로 Aggregate 생성

- Aggregate에 필요한 디스크 수와 Hot Spare 수를 결정해야 함.

※ root-data-data 파티셔닝이 활성화 되고 구성에 SSD가 24개 이하인 경우 데이터 파티션을 다른 노드에 할당하는 것이 좋음.

root-data 파티셔밍 및 root-data-data 파티셔닝이 활성화 된 시스템에서 aggregate를 만드는 절차는 파티션 되지 않은 디스크를 사용하여 시스템에서 aggregate를 만드는 절차와 동일.

시스템에서 root-data 파티셔닝이 활서오하 된 경우 -diskcount 옵션에 디스크 파티션 수를 사용해야 함. root-data-data를 분할의 경우 -diskcount 옵션은 사용할 디스크 수를 지정.

※ FlexGroups 와 함께 사용하기 위해 여러 aggregate를 만들 때 aggregate는 가능한 한 크기가 비슷해야 함.

○  스토리지 aggregate 생성

1) spare disk 파티션 목록을 보고 aggregate를 생성하기에 충분한지 확인

::>storage aggregate show-spare-disk -original-owner node_name

=> 데이터 파이션은 사용 가능한 로컬데이터 아래에 표시됨. 루트 파티션은 spare로 사용할 수 없음.

2) Aggregate 생성 시 시뮬레이션:

::>storage aggregate create -aggregate [aggregate_name] -node [node_name] -raidtype raid_dp -diskcount [number of disks or partition] -simulate true

3) 시뮬레이션 된 명령에서 경고가 표시되면 명령을 조정하고 다시 시뮬레이션

4) aggregate 생성

::>storage aggregate create -aggregate [aggregate_name] -node [node_name] -raidtype raid_dp -diskcount [number of disks or partition]      

5) aggregate 생성 확인

::>storage aggregate show-status [aggregate_name]

3. Aggregate 확장 Workflow

4. Node나 Shelf에 Drives 추가

- 노드나 Shelf에 드라이브를 추가하여 Hot Spare 수를 늘리거나 Aggregate에 추가

- 추가하려는 Drives는 플랫폼에서 지원되어야 함.

- 단일 Procedure에서 추가해야 하는 최소 드라이브 수는 6개. 단일 드라이브를 추가하면 성능이 저하될 수 있음.

- Steps

1) 넷앱 지원 사이트에서 최신 드라이브 및 Shelf 펌웨어와 디스크 검증 패키지 파일을 확인.

노드나 Shelf에 최신 버전이 없는 경우 새 드라이브를 설치하기 전에 업데이트 진행.

드라이브 펌웨어는 최신 펌웨어 버전이 없는 새 드라이브에서 자동으로 업데이트 됨.

2) 바르게 접지(Properly ground yourself)

3) 플랫폼 전면에서 베젤을 제거

4) 새 드라이브의 올바른 슬롯을 확인

※ 드라이브 추가를 위한 올바른 슬롯은 플래솜 모델 및 ONTAP 버전에 따라 다름. 어떤 경우에는 특정 슬롯에 순서대로 드라이브를 추가해야 함.

5) 새 드라이브를 삽입

a. Cam handle 이 열린 위치에 있는 상태에서 양손으로 새 드라이브를 삽입

b. 드라이브가 멈출 때까지 밈.

c. Cam handle을 닫아 드라이브가 미드 플레인과 핸들에 완전히 안착되고 핸들이 제자리에 고정되도록 함. Cam handle을 천천히 닫아 드라이브 면과 올바르게 정렬되도록 함.  

6) 드라이브의 activity LED(녹색)가 켜져 있는지 학인. LED가 계속 켜져 있으면 드라이브에 전원이 있음을 의미. activity LED가 깜빡이면 드라이브에 전원이 있고 I/O가 진행 중임을 의미. 드라이브 펌웨어가 자동으로 업데이트되는 경우 LED가 깜빡임.

7) 다른 드라이브를 추가하려면 4) ~ 6)단계를 반복. 새 드라이브는 노드에 할당될 때까지 인식이 되지 않음. 새 드라이브를 수동으로 할당하거나 노드가 드라이브 자동 할당 규칙을 따르는 경우 ONTAP이 새 드라이브를 자동할당할 때까지 기다릴 수 있음.

8) 새 드라이브가 모두 인식 되면 추가 및 소유권 정보를 확인

::>storage aggregate show-spare-disks => 올바른 노드가 소유한 새 드라이브가 표시되어야 함

9) Options: 새로 추가된 드라이브를 제로화(::>storage disk zerospares)

※ Aggregate에서 이전에 사용된 드라이브는 다른 Aggregate에 추가하기 전에 0으로 설정해야 함. 드라이브를 0으로 설정하면 Aggregate 크기를 빠르게 늘려야 하는 경우 지연을 방지할 수 있음. 드라이브 제로화 명령은 백그라운드에서 실행되며 노드에서 제로화 되지 않은 드라이브의 크기에 따라 완료하는데 몇 시간이 걸릴 수 있음.

::>storage disk zerospares

디스크 초기화 후

- 새 드라이브를 aggregate에 추가하거나 Host Spare 목록에 배치 or 새 aggregate 생성 가능.

1) 디스크 검증 패키지를 업데이트 해야 하는 경우,

디스크 검증 패키지(Disk Qualification Package, DQP)는 새로 검증 된 드라이브에 대한 완전한 지원을 추가. 드라이브 펌웨어를 업데이트 하거나 새 드라이브 유형 또는 크기를 클러스터에 추가하기 전에 DQP를 업데이트 해야 함.

DQP를 분기 or 반기마다 정기적 업데이트 하는 것이 best practice

2) Hot Spare 디스크 동작

핫 스페어 디스크는 스토리지 시스템에 할당되고 사용할 준비가 되었지만 RAID 그룹에서 사용 중이 아니고 데이터를 보유하지 않는 디스크.

3) Aggregate 생성 플로우

aggregate를 생성하면 시스템의 볼륨에 스토리지가 제공됨. ONTAP 9.2부터는 ONTAP이 시스템에 대한 Aggregate 구성 권장하도록 할 수 있음(Auto Provisioning). Auto Provisioning을 사용할 수 없거나 적합하지 않은 경우 수동으로 구성할 수 있음.

5. 수동으로 디스크 ownership 할당

디스크는 Aggregate에 사용되지 전에 node가 소유해야 함. 클러스터가 자동 디스크 소유권 할당을 사용하도록 구성되지 않은 경우 소유권을 수동으로 할당해야 함.

Aggregate에서 사용중인 디스크의 소유권을 재 할당 할 수는 없음.

- 할당되지 않은 디스크 확인

::>storage disk show -container-type unassigned

- 디스크 할당

::>storage disk assign -disk disk_name -owner owner_name

6. 빠른 드라이브 zeroing

ONTAP 9.4부터는 긴 대기시간 없이 프로비저닝 하기 전에 드라이브(SSD 및 HDD)를 자동으로 빠르게 제로화 할 수 있음.

ONTAP 9.4이상으로 설치되거나 초기화 된 시스템의 경우 드라이브 제로화가 자동으로 수행되고 몇 초 만에 완료.

수동으로 드라이브를 제로화해야 할 경우 아래 방법을 사용

1) storage disk zerospares 명령 사용(관리자 권한 필요)

2) 부팅 메뉴에서 다음 옵션 중 하나를 선택

- (4) Clean configuration and initialize all disks

- (9a) Unpartition all disks and remove their ownership information

- (9b) Clean configuration and initialize node with whole disks

빠른 제로화 향상은 ONTAP 9.4 이전 릴리스에서 업그레이드 된 시스템을 지원하지 않음.

클러스터 노드에 빠르게 비워진 드라이브가 있는 Aggregate가 포함된 경우 클러스터를 ONTAP 9.2 또는 이전으로 되돌릴 수 없음.

7. Aggregate 확장

볼륨에 더 많은 공간을 제공할 수 있도록 Aggregate에 디스크를 추가할 수 있음.

partitioned disks나 unpartitioned disks 를 Aggregate에 추가하는 절차는 유사함.

스토리지를 추가하는 Aggregate RAID Group 크기를 아는 것이 중요.

- Aggregate를 확장할 때 Aggregate에 partitioned disks를 추가하는지 unpartitioned disks를 추가하는지를 알고 있어야 함. unpartitioned disk를 기존 Aggregate에 추가하면 기존 RAID Group 크기가 새 RAID Group 크기에 상속되어 필요한 Parity 디스크 수에 영향을 줄 수 있음.

unpartitioned disk가 Partitioned disk로 구성된 RAID Group에 추가되면 새 디스크가 분할되어 사용되지 않는 예비 분할 영역에 남음.

파티션을 프로비저닝 할 때 두 파티션을 예비로 사용하는 드라이브 없이 노드를 떠나지 않도록?해야 함. 그럴 경우 노드에서 컨트롤러 중단이 발생하면 문제에 대한 중요한 정보(the core file)를 기술 지원에 제공하지 못할 수 있음.

※ disklist 명령을 사용해서 Aggregate 디스크를 확장하지 말도록 하라.

   파티션 정렬이 잘못될 수 있음

-Steps

1) Aggregate를 소유하는 시스템에서 사용 가능한 spare storage를 표시.

::> show-spare-disk -original-owner [node_name] -is-disk-shared true 매개 변수를 사용하여 Partitioned 디스크나 unpartitioned 디스크만 표시할 수 있음.

2) 현재 Aggregate에 대한 RAID 그룹 표시

::>storage aggregate show-status [aggr_name]

3) Aggregate에 디스크 추가

::>storage aggregate add-disks -aggregate [Aggr_name] -diskcount [number_of_disk_or_partition] -simulate true  

실제 프로비저닝하지 않고 스토리지에 디스크 추가 결과를 볼 수 있음.

- Flash Pool Aggregate를 생성할 때, Aggregate와 다른 체크섬이 있는 디스크를 추가하거나 혼합.

체크섬 Aggregate에 디스크를 추가하는 경우 -checksumstyle 매개 변수를 사용해야 함.

- Flash Pool Aggregate에 디스크를 추가하는 경우 -disktype 매개 변수를 사용하여 지정

- disksize 매개 변수를 사용하여 추가 할 디스크의 크기를 지정할 수 있음. 지정된 크기의 디스크만 선택 됨.

::> storage aggregate add-disks -aggregate TEST_AGGR -raidgroup new -diskcount 5

5) 디스크 추가 확인

::>storage aggregate show-status -aggregate TEST_AGGR

- 새 raidgroup에 디스크 추가

6) 노드에 root partition과 data partition 이 모두 스페어인 디스크가 있는지 확인

::>storage aggregate show-spare-disks -original-owner NETAPPPAR_TEMP-N1

8. Managing Aggregates

디스크 RAID protection levels

- 3가지 RAID 지원. RAID 보호 수준에 따라 디스크 오류 발생 시 데이터 복구에 사용할 수 있는 Parity 디스크 수가 결정 됨.

- RAID Protection 기능을 사용하면 RAID 그룹 디스크 오류가 있는 경우, 오류가 발생한 디스크를 Spare 디스크로 교체하고 패리티 데이터를 사용하여 오류가 발생한 디스크의 데이터를 재구성 함.

1) RAID 4

하나의 Spare 디스크 사용. RAID 그룹 내 장애 발생 시 하나의 디스크에서 데이터를 교체 재구성.

2) RAID DP

RAID-DP 보호 기능을 통해 최대 2개의 Spare 디스크를 사용하여 RAID 그룹 내에서 동시에 오류가 발생한 최대 2개의 디스크에서 데이터를 교체하고 재구성.

3) RAID-TEC

RAID-TEC 보호 기능을 사용하면 최대 3개의 Spare 디스크를 사용하여 RAID 그룹 내에서 동시에 오류가 발생한 최대 3개의 디스크에서 데이터를 교체하고 재구성.

Aggregate에 필요한 디스크나 디스크 파티션 수를 결정하는 방법

- Aggregate에 충분한 디스크 또는 디스크 파티션이 있어야 함. 데이터 손실 가능성을 최소화하려면 권장되는 수의 hot spare 디스크나 hot spare 디스크 파티션이 있어야 함.

- Root-data partitioning은 특정 구성에서 기본적으로 활성화 됨. Root-data partitioning이 활성화 된 시스템은 디스크 파티션을 사용하여 Aggregate를 생성.  Root-data partitioning이 활성화되지 않은 시스템은 파티션되지 않은 디스크를 사용.

- RAID 정책에 필요한 최소 수를 충족하고 최소 용량 요구 사항을 충족하기에 충분한 디스크 도는 디스크 파티션이 있어야 함.

※ ONTAP에서 드라이브의 사용 가능한 공간은 드라이브이 물리적 용량보다 적음.

특정 드라이브의 사용 가능한 공간과 하드웨어 유니버스에서 각 RAID 정책에 필요한 최소 디스크나 디스크 파티션을 찾을 수 있음.

::>storage aggregate show-spare-disks

- RAID 그룹을 만들고 용량 요구 사항을 충족하는데 필요한 디스크 또는 디스크 파티션 수 외에도 Aggregate에 권장되는 최소 hot spare 디스크나 hot spare 디스크 파티션이 있어야 함.

1) 모든 Aggregate의 경우 최소 하나의 hot spare디스크나 hot spare 디스크 파티션이 있어야 함.

2) 비플래시 동종 Aggregate의 경우 최소 2개의 hot spare 디스크나 디스크 파티션이 있어야 함.

3) Flash Pool Aggregate의 경우 각 디스크 유형에 대해 최소 2개의 hot spare 디스크나 디스크 파티션이 있어야 함.

4) Management Center의 사용을 지원하고 여러 동시 디스크 오류로 인한 문제를 방지하려면 다중 디스크 캐리어에 최소 4개의 hot spare가 있어야 함.

● Boolean 자료형, if 조건문

비교 연산자

==: 같다, !=: 다르다, <: 작다, >: 크다, <=: 작거나 같다, >=: 크거나 같다.

- 문자열에도 비교 연산자 적용 가능

- 변수의 범위 등도 비교 가능

불연산: 논리연산자

1) not 연산자

- 단항 연산자, 참과 거짓을 반대로 바꿀 때 사용

2) and 연산자

- 양쪽 변의 값이 모두 참일 때만 True

3) or 연산자

- 둘 중 하나만 참이어도 True

○ if조건문

- 조건 분기

if 불 값이 나오는 표현식 -> if 조건문 뒤에는 반드시 콜론(:)을 붙여줘야 함.

- if문 다음 문장은 4칸 들여쓰기 후 입력

ex)

- if뒤에 있는 불 값이 거짓인 경우 들여쓰기 된 명령문이 있더라고 아무것도 실행되지 않음.

조건문 사용

○ 날짜/시간 활용

-날짜/시간 출력

- 모듈이라는 기능을 활용해서 datetime이라는 기능을 가져옴.

- datetime.datetime.now()라는 함수로 현재 시간을 구해 now라는 변수에 대입.

- format() 함수

- 오전/오후

- 계절

○ 조건문

※ \는 줄바꿈

- int_num[-1]에 의해 마지막 글자를 추출

※ in 연산자 사용

※ 나머지 연산자 사용

▶ boolean은 파이썬 기본 자료헝으로 true, false를 나타내는 값.

▶ 비교 연산자는 숫자 또는 문자열에 적용, 대소를 비교하는 연산자

▶ 논리 연산자는 not, and, or 연산자가 있으며 boolean 을 만들 때 사용

▶ if 조건문은 조건에 따라 코드를 실행하거나 실행하지 않게 만들고 싶을 때 사용하는 구문

○ if ~ else, elif

○ else 조건문 활용

if 조건: 

    조건이 참일 때 실행할 문장

else:

    조건이 거짓일 때 실행할 문장

ex) if, else로 구분

○  elif

if 조건A:

    조건A가 참일 때 실행할 문장

elif 조건B:

     조건B가 참일 때 실행할 문장

...

else:

    모든 조건이 거짓일 때 실행할 문장

○  False로 변환되는 값

if조건문의 매개변수에 boolean이 아닌 다른 값이 올 때는 자동으로 이를 불로 변환해서 처리.

False로 변환되는 값: None, 0, 0.0, 빈 컨테이너(빈 문자열, 빈 바이트열, 빈 리스트 등)

○ pass

pass 키워드를 만나면 "아무것도 암함" , "곧 개발하겠다"

○ raise NotImplementError

raise 키워드와 미구현 상태를 표현하는 NotImplementedError조합하여 '아직 규현하지 않은 부분' 강제 오류 발생 시킴.

CIFS SHARE

Volume mount

::>mount -vserver SVM01 -volume cifs_vol1 -junction-path /cifs_vol1

CIFS Share설정

::>cifs share create -vserver SVM01 -share-name CIFS_SHARE -path /cifs_vol1

Access 권한 설정

::>access-control remove -share CIFS_SHARE -user-or-group everyone 

::>access-control create -share CIFS_SHARE -user-or-group "Domain\Administartors" -permission full_control

CIFS Properties 설정

::>vserser cifs share properties add -vserver SVM01 -share-name CIFS_SHARE -share-properties showsnapshot, changnotfy

::>vserver cifs share properties remove

<properties>

1.  oplocks

share가 클라이언트 측 캐싱이라고도 하는 opportunistic locks(기회적잠금?) 사용하도록 지정. 일부 프로그램은 oplock이 활성화된 경우 정상 작동하지 않을 수 있음(MS Access는 oplock이 활성화 되면 손상되기 쉬움)
share의 장점은 단일 경로를 여러 번 공유할 수 있으며 각 공유는 서로 다른 속성을 가질 수 있음. 
cifs_vol1/vol1라는 경로에 DB와 다른 유형의 파일이 모두 포함된 경우 안전한 DB액세스를 위해 oplock이 비활성화된 것과 클라이언트 측 캐싱에 대해 oplock이 활성화된 두 개의 공유를 만들 수 있음. default 설정.

2. browsable: Windows 클라이언트가 공유를 찾아 볼 수 있음. default 설정

3. showsnapshot: 클라이언트가 스냅샷 복사본을 볼수 있도록 지정

4. changenotify: Change Notify 요청을 지원하도록 지정. default 설정

5. attributecache: SMB 1.0을 통해 속성에 대한 빠른 액세스를 제공하기 위해 CIFS 공유에서 파일 속성 캐싱을 활성화

6. continuously-available: 지원하는 SMB클라이언트가 파일을 영구적?으로 열 수 있음. 이러한 방식으로 열린 파일은 장애 조치 및 반환과 같은 중단 이벤트로부터 보호됨. FlexGroups나 WORKGROUP CIFS서버에 대해 지원하지 않음

7. branchcache: 공유를 통해 클라이언트가 이 공유 내의 파일에 대해 Branchcache 해시를 요청할 수 있도록 지정. CIFS branchcache 구성에서 운영 모드로 'per-share' 을 지정하고 'oplocks' 공유 속성도 지정하는 경우에만 유용

8. access-based-enumeration: 공유에서 ABE(액세스기반열거?)를 사용하도록 지정. ABE필터링 된 공유 폴더는 개별 사용자의 액세스 권한을 기반으로 사용자에게 표시되므로 사용자가 액세스 할 수 없는 폴더나 공유리소스가 표시되지 않도록 함

9. namespace-caching: 공유에 연결하는 SMB 클라이언트가 CIFS 서버에서 반환한 디렉터리 열거 결과를 캐시할 수 있음을 지정

10. encrypt-data: 공유에 액세스 할 때 SMB 암호화를 사용해야 함을 지정. 암호화를 지원하지 않는 클라이언트는 이 공유에 액세스 할 수 없음

11. show-previous-versions: 클라이언트에서 이전 버전을 보고 복원할 수 있도록 지정. default 설정

◇ 도커 실습

- Docker는 리눅스 기술(네이티브 설치)

- 윈도우/맥에서는 하이퍼바이저 기반 docker Toolbox/Docker Desktop

- Docker Toolbox는 VirtualBox 기반

- Docker Desktop (Hyper-V 기반): 윈도우 10 Pro/Enterprise 이상의 라이선스 필요.

- 맥 버전은 제약 없음

- http://docker.com (도커 hub에서 이미지 받아서 실행)

▶ 설치 주의 사항

- CPU 가상화 기능 요구(vt-x나 amd-v 요구), Pentium/Celeron CPU는 실행되지 않음

- 다른 가상화 기술 충돌: 버추얼박스와 Hyper-V/VMware들이 싱행되고 있느지 확인

▶ 실습 진행

- 윈도우 > 버추얼박스 > 우분투(서버) > 도커 > 우분투(컨테이너) 실행

① 버츄얼 박스 설치

② extension pack 설치

③ 버츄얼 박스 관리자 실행

④ 파일 > 가상시스템 가져오기 > 가상머신 파일 선택 (.ova)

⑤ 시작

⑥ ID: ubuntu / PW: ubuntu

⑦ $ 프롬프트 확인

⑧ $sudo apt update

⑨ $sudo apt install openssl-server

- 도커 설치

① $sudo apt install docker.io

② $sudo apt install docker-compose

$ sudo docker search ubuntu

* sudo를 매번 인력하기 귀찮다면?

$sudo usermod -aG docker ubuntu

▶ 실행 후 바로 접속 상태

- Docker container Ubuntu 

- 도커 명령어들은 $ 상태에서 입력해야 함

- 도커 이미지 검색(기본이 최신 버전): docker search ubuntu

- 우분투 이미지 다운로드: docker pull ubuntu

- 이미지 리스트 출력: docker images

- 컨테이너 생성(동시에 접속): docker run -it --name=ubuntu1 ubuntu

- 컨테이너 접속: docker exec -it ubuntu1 bash

- 컨테이너 탈출: control-P-Q 순서대로 입력 (컨테이너 정지하지 않고 나옴)

◈ 클라우드(서비스)

예전에는 하이퍼바이저 기반으로 구현(VMware ESXi + vCenter = vShpere) 등

◇ 구현 기술

 도커(컨테이너) + 오케스트레이션(스웜/쿠버네티스)

 -> 기존 하이퍼바이저 보다 가벼움

 -> vSphere7은 + Kubernetes 지원 (하이브리드 형태)

◇ 클라우드 현황 

- IT 공룡들의 경쟁

- 실리콘 밸리 핵심 기업: FAANG(Facebook/Amazon/Apple/Netflix/Google)

- 클라우드 4: AMIG(Amazon AWS/Microsoft Azure/IBM Bluemix/Google Cloud)

- 한국은? 규제, 기술 격차?

◇ 클라우드 기반 서비스

▶ Amazon AWS

   - EC2/EMR/RDS ...

   - Elastic Computing Cloud/Elastic MapReduce ...

   - Simple Storage Service, Relational Database Service ...

▶ MS Azure

▶ 구글 드라이브

   - 클라우드 디스크 + 오피스 + PDF viewer, ...

▶ 드랍박스, N드라이브, 다음 클라우드, U클라우드 ...

▶ 해외: Oracle 18"c", MSOffice.com, Dropbox, Adobe ...

▶ 국내: KT Cloud, Naver Cloud, NHN 토스트 ...

◇ 하이브리드 클라우드

▶ 여러개의 클라우드를 같이 사용

   - 줌(AWS/Azure/Oracle), iCloud(Bluemix/Google Cloud)

   - 하이브리드 형태를 가장 잘 지원하는 것이 Kubernetes 다?

◇ 클라우드 구현 기술

- 클라우드를 구축하기 위한 가능 기술(Enabling Technology)

  가상화 vs 컨테이너 기반 가상화

- 가상화

  Hypervisor로 통칭

  VMware ESXi(+vCenter), Hyper-V, Xen, VirtualBox ...

  서버 활용도가 높아짐 + 개별 VM은 느리짐(10~15%)

- 컨테이너 기반 가상화

  도커(Docker) + 쿠버네티스(Kubernetes)

  서버 활용도가 높음 + 개별 VM?이 가벼움

▶ 하이퍼바이저 기반 가상화의 특징

- 장점

  서버 Utilization 향상(80%)

  시스템 가상화로 인해 다양한 게스트 OS를 실행할 수 있음, 윈도우/리눅스/MacOS/NAS ...

- 단점

  물리시스템과 게스트 OS간의 가상화 기능으로 인한 성능 저하... 약 10~15% 정도의 오버헤드

  호스트 OS와 게스트 OS간의 기능 중복(스케줄링 등)

▶ 도커의 성능

- 오버헤드가 3% 이내, 가상화는 10% 내외?

- 현재 네트워크 오버헤드도 상당히 줄었음.

▶ 듀얼모드 vs 싱글모드

- vSphere(VM) + kubernetes (container) -Redhat/VMware

- Docker/Kubernetes only - google

◇ 컨테이너 기반 가상화

- 서버: 리눅스만 사용/ 컨테이너(VM)끼리 커널을 공유

- 현재 대부분의 서버가 유닉스/리눅스, 윈도우는 많지 않음...

- 기존 가상화와 다른 개념: 하드웨어 가상화가 아닌 실행 환경 분리, 각 컨테이너간 영향을 분리

▶ 기술적 특징

- 모든 컨테이너들이 동일 OS 커널을 공유

- 독립적인 스케줄링이나 CPU/메모리/디스크/네트워크를 가상화 하지 않음.

- 리눅스의 특수 기능(LXC)을 사용한 실행 환경 격리를 응용

- 리눅스에서만 사용

- 처음에는 우분투에서 현재 리눅스 배포판에서 사용 가능(Fedora, RHEL, ...)

- 현재는 LXC -> Libcontainer -> RunC(표준)을 사용해 우분투 의존도에서 해방

- 다른 OS(윈도우/OSX)에서 사용하려면 (도커와는 관련 없음?), 일반 하이퍼바이저(경량)가 있어야 함.

- Windows Container 

▶ 도커의 특징

- hub.docker.com 참고

- 가볍다? 똑똑하다?

- 많은 사람들이 자기가 구축한 이미지를 공유(도커허브): 구글, 오라클과 같은 회사에서 자사의 S/W 배포 방법으로 채택

- 에코 시스템? : 도커기반/활용 기술의 활성화, 도커 컴포즈, 스웜, 구버네티스

▶ 도커의 기술적 특징 (LXC) - Linux Container

- 시스템 레벨 가상화

- cgroup(Control groups): CPU/메모리/디스크/네트워크 자원을 할당

- Namespaces(Namespace Isolation): 프로세스트리, 사용자 계정, 파일시스템, IPC ... 호스트와 별개의 공간 설정

- chroot(change root) 명령어에서 발전: chroot jail, chroot 상의 폴더에서 외부 디렉토리 접근 안됨.

- 도커는 실행할 때 시스템 관리자 권한이 필요함(sudo~), 잠재적인 보안 취약점 있음(시큐어코딩)

▶ 도커의 기술적 특징 - Libcontainer

- 우분투 의존성을 해결하기 위해 LXC외에 Libcontainer 제작, 실행 드라이버(exec driver)라고 부름

- native(libcontainer), lxc(LXC)

▶ 도커의 기술적 특징 - containerd/runC

- 도커 1.11이후

- 기존 방식과 최신 방식의 차이: containerd/runC 기반의 도커

- containerd: 컨테이너를 실행하고 노드에서 이미지를 관리하는데 필요한

▶ 도커의 기술적 특징 - LXD

- 우분투를 만든 캐노니컬에서 만든 컨테이너 솔루션

- 기존의 LXC에 보안 개념까지 추가: Security by default, root가 아니어도 컨테이너 생성 가능

- 도커는 Application Container, LXD는 Machine Container

- LXD는 Contain "Hypervisor", 경쟁 기술이라기 보다는 보완 관계(도커와 병행 가능)