NetApp Tech Blog에 갔다가 Trident 관련해서 흥미로운 주제의 글이 보여서 AI 번역(+약간 수정)의 힘을 빌려 읽어보았습니다.
출처: https://community.netapp.com/t5/Tech-ONTAP-Blogs/NetApp-ONTAP-doubles-up-as-storage-for-logs-in-Red-Hat-OpenShift-Container/ba-p/449280
로깅은 모든 소프트웨어 시스템에 필수적인 요소입니다. 소프트웨어 시스템뿐만 아니라 인프라의 로그도 영구 저장소에 저장하는 것이 중요합니다. 시스템이 예상대로 작동하지 않을 때 언제든지 문제 해결 도구로 사용할 수 있기 때문입니다.
OpenShift Container Platform에서 상태 저장 컨테이너 애플리케이션의 영구 저장소로 이미 ONTAP을 사용하고 있는 고객은 로그 저장소에도 동일한 ONTAP 시스템을 사용하는 것 외에 다른 방법은 없습니다. ONTAP 사용을 고려하고 있는 고객에게 ONTAP은 ONTAP 스토리지가 제공하는 또 다른 부가 가치입니다. 이 블로그에서는 OpenShift Container Platform의 로깅 하위 시스템에 ONTAP 스토리지를 사용하는 방법에 대해 자세히 설명합니다.
OpenShift Container Platform에서 실행되는 워크로드의 경우, 애플리케이션 로그는 애플리케이션 컨테이너에서 생성됩니다. 클러스터 관리자는 클러스터에 로깅 하위 시스템을 배포하고 이를 사용하여 노드 시스템 감사 로그, 애플리케이션 컨테이너 로그 및 인프라 로그를 수집하고 집계할 수 있습니다.
OpenShift Container Platform의 로깅 아키텍처에 대한 자세한 내용은 OpenShift 설명서를 참조하세요 . 기본적으로 수집기, 로그 저장소, 시각화라는 3가지 주요 구성 요소가 있습니다. 아래에 표시된 설정에서 Vector를 로그 수집기로 사용했습니다. Vector는 각 노드에서 로그를 수집하고, 데이터를 변환하고, 구성된 로그 저장소로 전달합니다. 제가 사용한 로그 저장소는 LokiStack입니다. 로그 전달기는 분석을 위해 로그 데이터를 전달하고 로그 저장소에 저장합니다. 저장소 클래스로 ontap-nas를 사용하는 로컬 파일 시스템과 로그를 저장하기 위한 ONTAP S3 버킷을 제공했습니다. 시각화를 위해 OpenShift Container Platform 웹 콘솔 UI를 선택했습니다. (수집기용 Fluentd는 로깅 버전 5.6부터, 로그 저장소용 OpenShift Elasticsearch Operator는 로깅 버전 5.4.3부터, 시각화용 Kibana 웹 콘솔은 OpenShift 버전 4.11부터 사용되지 않습니다.)
ONTAP 스토리지에 로그를 저장하기 위한 설정 세부 정보는 다음과 같습니다.
vSphere 기반 OpenShift Container Platform(4.13.13)에서 앱의 백엔드 영구 저장소로 NetApp Astra Trident(23.07)를 사용하는 ONTAP 시스템(9.12.1)을 구성했습니다. 그런 다음 동일한 ONTAP 시스템에 장기 로그 저장을 위한 객체 저장소를 생성했습니다. ONTAP에서 객체 저장소를 설정하는 방법은 ONTAP 설명서를 참조하십시오.
ONTAP에서 버킷을 생성하고 해당 버킷의 비밀 키를 획득했습니다. 그런 다음 이 비밀 키를 사용하여 로깅 하위 시스템을 설치할 OpenShift 클러스터에 비밀 키를 생성했습니다.
제 클러스터에는 NFS 및 iSCSI 스토리지를 제공할 수 있는 ONTAP 볼륨을 프로비저닝하기 위해 ontap-nas 및 ontap-san 백엔드가 이미 생성되어 있습니다. Trident 설치 및 백엔드 및 스토리지 클래스 구성 생성에 대한 자세한 내용은 Astra Trident 설명서를 참조하십시오 . 그런 다음 OpenShift 설명서에 따라 Loki Operator(5.8)와 OpenShift Logging Operator(5.8)를 설치했습니다.
다음으로, Loki Operator에서 LokiStack을 만들었습니다.
위에 표시된 대로 양식 보기를 작성한 다음 YAML 보기로 이동하여 다음과 같이 보이도록 수정합니다.
Loki 배포 크기에 대한 자세한 내용은 설명서를 참조하세요 .
다음 단계는 Red Hat OpenShift Logging Operator에서 클러스터 로깅 인스턴스를 생성하는 것입니다. Collector 구현에는 vector를, 로그 저장소에는 lokistack을 선택하고 이전 단계에서 생성한 lokistack의 이름을 입력했으며, 시각화에는 OCPconsole을 선택했습니다. 애플리케이션, 감사 및 인프라 로그에 대한 보존 정책을 설정했습니다. 이 정책은 임시 저장소에 대한 것이며, 객체 저장소의 로그 보존에는 영향을 미치지 않습니다.
‘생성’을 클릭하면 클러스터 로깅 인스턴스가 생성됩니다. 웹 콘솔 업데이트를 확인하려면 브라우저를 새로 고치라는 메시지가 표시됩니다. 페이지를 새로 고치면 왼쪽 탐색 메뉴의 ‘관찰’ 아래에 ‘로그’가 표시됩니다.
이제 LokiStack이 ONTAP에서 사용하도록 생성한 모든 리소스를 찾아보겠습니다. ONTAP 볼륨을 보려면 먼저 Trident가 생성한 볼륨 이름을 찾아야 합니다.
클러스터에 액세스할 수 있는 VM의 명령줄에서 LokiStack에서 생성된 PVC와 PV를 조회할 수 있습니다. 이러한 PV는 이전에 구성한 스토리지 클래스를 기반으로 생성됩니다.
다음 명령을 사용하여 각 영구 볼륨(pv)에 대해 ONTAP에서 해당 볼륨 이름을 찾을 수 있습니다. 이는 LokiStack에서 임시 저장소로 사용되는 볼륨입니다.
관리 LIF를 사용하여 ONTAP 시스템의 시스템 관리자에 로그인하고 LokiStack에서 사용되는 볼륨을 볼 수 있습니다.
로그를 저장하기 위해 구성한 Object Storage 버킷도 볼 수 있습니다.
또한 S3 브라우저를 사용하여 S3 버킷에 저장된 로그를 볼 수 있습니다.
요약
Red Hat OpenShift는 컨테이너 워크로드 플랫폼으로 널리 사용되고 있습니다. 고객들은 이미 OpenShift Containers에서 상태 저장 애플리케이션의 영구 스토리지 요구 사항을 충족하기 위해 NetApp ONTAP을 사용하고 있습니다. 이 블로그에서는 동일한 ONTAP 스토리지 시스템을 OpenShift Logging 하위 시스템과 통합하는 방법을 설명했습니다. 이러한 부가 가치를 통해 고객은 스토리지 시스템 활용도를 RedHat 생태계로 확장할 수 있습니다.
