일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- Compression
- C++
- Semiconductor
- sycl
- cloud
- quantum_computing
- convolution
- deep_learning
- flash_memory
- 클라우드
- jhVM
- SpMM
- GPU
- CuDNN
- Qubit
- 반도체기초
- 쿠버네티스
- HA
- dnn
- nvidia
- DRAM
- jhDNN
- FPGA
- stl
- 딥러닝
- kubernetes
- 양자역학의공준
- CUDA
- 반도체
- POD
- Today
- Total
목록Cloud (30)
Computing
이전글 - Pod 스토리지 (1): Volume, PersistentVolume, PersistentVolumeClaim 개념 PV (PersistentVolume) & PVC (PersistentVolumeClaim) 이전 글에서 정리하였지만, Volume 컴포넌트는 Pod에 외부 저장소(스토리지)를 제공하기 위한 Pod의 컴포넌트이다(emptyDir 타입 Volume은 제외). 따라서 Pod가 제거된다면 Volume 컴포넌트 또한 함께 제거된다. 다만 주의할 점은 외부 저장소 자체가 제거되는 것은 아니라 데이터는 보존 가능하다. 그에 비해 PersistentVolume(PV, 지속되는 볼륨)은 이름 그대로 Volume과는 다르게 지속된다. 즉 Pod와 제거되더라도 유지된다. PersistentVolu..
파드 스토리지의 특징 및 외부 스토리지의 필요성 쿠버네티스의 파드(Pod)는 쿠버네티스에서 생성 및 관리되는 가장 최소의 배포 단위이다[1]. 파드는 하나 이상의 리눅스 컨테이너(container)들로 구성된다. 이때 같은 파드 내에서 배포된 컨테이너들은 같은 네트워크 자원을 가지며 스토리지를 공유할 수 있다[1]. 또한 한 파드로 묶여서 배포되는 컨테이너들은 같은 서버에서 동시에 스케쥴링&실행된다. 쿠버네티스는 여러 컨테이너들로 구성된 파드를 최소 배포 단위(=애플리케이션)라고 정의한다. 이러한 구성은 하나의 애플리케이션을 여러 개의 컨테이너들로 구성할 수 있기에 유지보수 과정을 쉽게 만들어준다고 한다. 예를 들어, 웹사이트를 만들고자 할 때, 여러 기능을 하나의 컨테이너 이미지로 저장할 수도 있을 것..
이전글 - Kubernetes 고가용성(HA) (1): 고가용성과 Kube Master의 고가용성 - Kubernetes 고가용성(HA) (2): kubeadm을 통한 고가용성 배포 - Kubernetes 고가용성(HA) (3): Keepalived와 HAProxy 이전 글들에서 쿠버네티스의 고가용성을 위한 복수 개의 Control plane 노드 구성 방법에 대하여 정리하였다. 정리하면서 느꼈지만 쿠버네티스는 중단없는 (인터넷) 서비스 운영, 즉 고가용성을 위해 다양한 기법이 적용된 것 같다. 오늘은 각 노드(Control plane or Worker)가 살아있음을 쿠버네티스 시스템에 알리는 Heartbeats[1]라는 개념에 대하여 정리하고자 한다. 분산 시스템에서의 Heartbeats Heartbe..
이전글 - Kubernetes 고가용성(HA) (1): 고가용성과 Kube Master의 고가용성 - Kubernetes 고가용성(HA) (2): kubeadm을 통한 고가용성 배포 이전 글에서 쿠버네티스 클러스터의 고가용성을 위한 Control plane(Master, 마스터) 다중화에 대해서 정리하고 간단한 Control plane 다중화 배포 실습을 진행하였다. 이전 실습에서는 HAProxy[2]를 사용하여 마스터간 로드 밸런싱을 구현하였고 이를 통해 마스터들의 API 서버간의 로드 밸런싱을 달성하였다. 실습을 간단히 정리하자면 다음과 같다. 3대의 마스터 A, B, C를 사용하는 환경에서 HAProxy를 A에 설치하였다(A가 Load Balancer 역할). 그리고 A의 36443 포트로 들어오는..
이전글 - Pod 네트워크 (1) : Service 필요성과 개념, 종류 (ClusterIP, NodePort, LoadBalancer) - Pod 네트워크 (2) : Service 내부 구현 분석 (kube-proxy와 iptables) - Pod 네트워크 (3) : kube-proxy와 CNI plugin 차이 이전 포스터에서 Pod를 내, 외부 네트워크에 공개하는 Service 개념에 대해서 정리하였다. 이번 포스터에서는 Service들 중 LoadBalancer type Service의 개념과 이것을 사용하기 위해 필요한 MetalLB에 대해서 정리하고자 한다. Load Balancing과 Load Balancer Load Balancing, 부하 분산[2]은 여러 개의 프로세싱 유닛(CPU co..
이전 글 - [Ceph] 개요 및 특징 (1) (Object storage 특징, File 저장 예시) 이전 글에서 간단히 Ceph라는 Storage cluster에 대해서 정리하였다. 이번 포스터에서는 Ceph의 interface에 대해서 정리해보고자 한다. 공부하는 단계에서 정리하는 자료이기에 틀린 내용이 있을 수도 있다. Ceph Interface Fig 1.은 Ceph를 high-level interface 레벨에서 설명하는 그림으로, Ceph architecture를 검색하면 가장 먼저 나오는 그림 중 하나이다. 이 그림은 사용자(client, app 등)가 Ceph를 어떻게 사용할 수 있는 지 방법을 잘 보여준다. 이전 글에서도 정리하였지만, Ceph는 object-based software-..
Ceph는 단일 분산 클러스터 상에 구축되는 object-based 분산 스토리지 시스템(distributed storage system)으로, file-level, object-level, block-level 모든 레벨의 interface를 제공한다[2]. 이번 포스터에서는 이 Ceph라는 분산 스토리지 시스템에 대해서 정리해보고자 한다. 공부하는 수준에서 정리하는 자료이기에 틀린 내용이 있을 수도 있다. Ceph Overview Ceph는 단일 분산 클러스터 상에 구축되는 object-based 분산 스토리지 시스템이다. Fig 1.을 통해 일단 한번 간단히 정리해보자. Fig 1.은 Ceph 아키텍처를 표현한 그림이다. 그림의 오른쪽에 붙은 명칭들은 개인적으로 붙인 것으로 공식적인 용어가 아니다...
이전글 - Pod 네트워크 (1) : Service 필요성과 개념, 종류 (ClusterIP, NodePort, LoadBalancer) - Pod 네트워크 (2) : Service 내부 구현 분석 (kube-proxy와 iptables) 이전 글에서 쿠버네티스 클러스터 상에서 네트워킹을 지원하는 리소스인 Service(서비스), 그 서비스의 종류와 내부 구현에 대하여 정리하였다. 오늘은 서비스의 구현체인 Kube-proxy와, Container Network Interface (CNI)의 구현체인 CNI plugin의 차이에 대해서 정리해보고자 한다. 둘 다 쿠버네티스 운영 시 네트워크 관련된 개념이라는 것 때문에 혼동되는데 이번 기회에 정리를 한번 해보고자 한다. kube-proxy VS. CNI P..