Rancher Kubernetes Engine 2 기반 SAP Data Intelligence 3.1
설치 설명서
SAP Data Intelligence 3는 대량의 데이터를 제어할 수 있는 도구 세트입니다. Rancher Kubernetes Engine(RKE) 2는 Kubernetes 기반이어서 SAP Data Intelligence 3을 손쉽게 배포할 수 있습니다. 본 문서에서는 SUSE와 SAP Data Intelligence 3에서 RKE 2를 설치하고 구성하는 것에 관해 설명합니다.
부인: SUSE 모범 사례 시리즈에 게시되는 문서(개별 문서 포함)는 SUSE 직원과 제3자가 자발적으로 기여하여 작성한 것입니다. 문서에서 별도로 설명하는 경우를 제외하고, 문서의 목적은 특정 작업을 수행하는 방법의 한 가지 예만을 제공하는 것입니다. 또한, SUSE는 문서에서 설명되는 작업이 해당 기능을 수행하는지 또는 의도하지 않은 결과가 제공되지 않는지를 확인할 수 없습니다. 본 문서의 모든 정보는 최대한 주의를 기울여 작성되었습니다. 그러나 이것이 문서의 정확성을 보장하지는 않습니다. 따라서 SUSE LLC, 그 계열사, 저자, 번역자 중 어느 누구도 있을 수 있는 오류나 그에 따른 결과에 책임을 지지 않는다고 명확히 진술할 필요가 있습니다.
1 소개 #
본 안내서에서는 Rancher Kubernetes Engine(RKE) 2를 기반으로 SAP Data Intelligence 3.1(SAP DI 3.1)을 온프레미스 설치하는 방법에 관해 설명합니다. 간단히 말씀드리면 SAP DI 3.1은 다음 단계에 따라 설치할 수 있습니다.
SUSE Linux Enterprise Server 15 SP2 설치
전용 노드에 RKE 2 Kubernetes 클러스터 설치
RKE 2 Kubernetes 클러스터에 SAP DI 3.1 배포
SAP DI 3.1에 대해 설치 후 단계 수행
SAP DI 3.1 설치 테스트
2 전제 조건 #
2.1 하드웨어 요구사항 #
이 장에서는 SUSE Linux Enterprise Server 15 SP2를 기반으로 RKE 2에 SAP DI 3.1을 설치할 때 필요한 하드웨어에 관해 설명합니다. 이 사용 사례에는 AMD64/Intel 64 아키텍처만 적용됩니다.
2.1.1 하드웨어 규모 조정 #
RKE 2에 SAP DI 3.1을 설정할 때는 하드웨어 규모를 적절히 조정하는 것이 매우 중요합니다.
일반 SAP DI 3 배포를 위한 최소한의 하드웨어 요구사항:
Kubernetes 클러스터에 최소 일곱 개의 노드가 필요합니다.
노드의 최소 규모는 다음과 같아야 합니다.
서버 역할 카운트 RAM CPU 디스크 공간 관리 워크스테이션
1
16GiB
4
>100GiB
마스터 노드
3
16GiB
4
>120GiB
작업자 노드
4
32GiB
8
>120GiB
프로덕션용 SAP DI 3 배포를 위한 최소 하드웨어 요구사항:
Kubernetes 클러스터에 최소 일곱 개의 노드가 필요합니다.
노드의 최소 규모는 다음과 같아야 합니다.
서버 역할 카운트 RAM CPU 디스크 공간 관리 워크스테이션
1
16GiB
4
>100GiB
마스터 노드
3
16GiB
4
>120GiB
작업자 노드
4
64GiB
16
>120GiB
RKE에 대한 요구사항이 무엇인지 자세히 알아보려면 다음 주소에 있는 설명서를 참조하십시오.
SAP DI 3 규모 조정에 관해 자세히 알아보려면 다음 주소에 있는 “SAP Data Intelligence 규모 조정 안내서”를 참조하십시오.
2.2 소프트웨어 요구사항 #
다음 목록에는 RKE에 SAP DI 3.1을 설치하는 데 필요한 소프트웨어 구성 요소가 포함되어 있습니다.
SUSE Linux Enterprise Server 15 SP2
Rancher Kubernetes Engine 2
SAP Software Lifecycle Bridge
SAP Data Intelligence 3.1
컨테이너 이미지용 보안 개인 레지스트리(예: https://documentation.suse.com/sbp/all/single-html/SBP-Private-Registry/index.html)
동적 물리적 볼륨을 제공하는 저장 솔루션에 대한 액세스 권한
Vora의 스트리밍 테이블 체크포인트 저장소를 사용할 계획이라면 S3 버킷과 유사한 객체 저장소가 필요합니다.
설치 중에 SAP DI 3.1 백업을 활성화할 계획이라면 S3와 호환되는 객체 저장소에 대한 액세스 권한이 필요합니다.
3 준비 #
SUSE Linux Enterprise Server를 구독합니다.
SUSE Linux Enterprise Server 15 SP2 설치 프로그램을 다운로드합니다.
RKE 2 설치 프로그램을 다운로드합니다.
저장 요구사항을 확인합니다.
개인 컨테이너 레지스트리를 만들거나 이 레지스트리에 대한 액세스 권한을 확보합니다.
SAP S 사용자가 SAP 소프트웨어와 문서에 액세스할 수 있게 합니다.
다음과 같은 관련 SAP 문서를 읽습니다.
4 Rancher Kubernetes Engine 2 클러스터 설치 #
Rancher Kubernetes Engine 2 클러스터는 설치는 간단합니다. 운영 체제를 설치하고 기본 구성을 마치고 나면 관리 호스트에 Kubernetes 클러스터 구성이 생성됩니다. 그다음에 Kubernetes 클러스터가 배포됩니다.
아래 섹션에서는 설치 단계를 더 자세히 설명합니다.
4.1 관리 호스트와 Kubernetes 클러스터 노드 준비 #
이 시나리오에서는 모든 서버가 AMD64/Intel 64 아키텍처에 기반을 둔 SUSE Linux Enterprise 15 SP2(SLES 15 SP2)를 사용합니다. SUSE Linux Enterprise Server 설명서는 다음 주소에서 보실 수 있습니다.
4.1.1 SUSE Linux Enterprise Server 15 SP2 설치 #
SAP Data Intelligence 3.1용 환경 내 각 서버에서 SUSE Linux Enterprise Server 15 SP2를 운영 체제로 설치합니다. 이 장에서는 권장되는 모든 설치 단계에 대해 설명합니다.
정적 네트워크 구성을 사용하는 것이 좋습니다. 이 구성을 처음으로 조정하는 시점은 설치 설정 중에 등록 페이지가 표시되었을 때입니다. 다음과 같이 오른쪽 상단 모서리에 있는 [네트워크 구성...] 버튼을 클릭합니다.
그림 1: SLES 설정 등록 페이지 #네트워크 설정 페이지가 표시됩니다. 기본적으로 네트워크 어댑터는 DHCP를 사용하도록 구성되어 있습니다. 이를 변경하려면 [편집] 버튼을 클릭하십시오.
그림 2: SLES 설정 네트워크 설정 #네트워크 카드 설정 페이지에서 “할당된 고정 IP 주소”를 선택하고 “IP 주소”, “서브넷 마스크”와 “호스트 이름” 필드에 해당 정보를 입력합니다.
그림 3: SLES 설정 네트워크 카드 #설치 중에는 설치해야 할 확장을 조정하는 작업도 필요합니다. RKE 2를 작동하려면 컨테이너 모듈이 필요합니다.
그림 4: SLES 설정 확장 #그래픽 인터페이스가 필요 없으므로 텍스트 기반 서버를 설치하는 것이 좋습니다.
그림 5: SLES 설정 시스템 역할 #Kubernetes를 실행하려면 스왑 파티션을 비활성화해야 합니다. 이를 위해 설치 중 파티션 제안을 조정할 수 있습니다.
그림 6: SLES 설정 파티셔닝 #고급 파티션 도구를 열 때 스왑 파티션을 선택하여 삭제해야 합니다.
그림 7: SLES 설정 고급 파티션 도구 스왑 #스왑 파티션을 삭제하고 난 후 생기는 공간은 기본 파티션을 확장하는 데 사용할 수 있습니다. 이를 위해 크기 조정 페이지를 호출할 수 있습니다.
그림 8: SLES 설정 고급 파티션 도구 크기 조정 #모든 미사용 공간을 사용할 수 있는 가장 손쉬운 방법은 여기에서 “최대 크기” 옵션을 선택하는 것입니다.
그림 9: SLES 설정 크기 조정 디스크 #그다음에 NTP 시간 동기화를 활성화합니다. 설치 중에 시계 및 시간대 페이지가 표시되면 활성화할 수 있습니다. NTP를 활성화하려면 [기타 설정 ...] 버튼을 클릭하십시오.
그림 10: SLES 설정 시간대 #“NTP 서버와 동기화” 옵션을 선택합니다. 원하는 경우 사용자 정의 NTP 서버 주소를 추가할 수 있습니다. “NTP를 데몬으로 실행”과 “NTP 구성 저장”의 확인란을 선택해야 합니다.
그림 11: SLES 설정 NTP #설치 설정 페이지가 표시되면 다음과 같이 되어 있는지 확인하십시오.
방화벽이 비활성화됨
SSH 서비스가 비활성화됨
Kdump 상태가 비활성화됨
그림 12: SLES 설정 요약 #Kdump를 비활성화하려면 레이블을 클릭하십시오. 그러면 Kdump 시작 페이지가 열립니다. 이 페이지에서 “Kdump 비활성화”가 선택되어 있는지 확인합니다.
그림 13: SLES 설정 Kdump #
설치를 완료한 후 다음 장으로 이동하십시오.
4.2 Kubernetes 노드 구성 #
이 안내서의 목적상 워크스테이션을 사용해 Salt를 통해 다른 모든 시스템을 오케스트레이션합니다.
4.2.1 Salt 미니언 설치와 구성 #
먼저 설치 도중 및 이후에 모든 시스템을 SUSE Customer Center나 SMT 또는 RMT 서버에 등록하여 업데이트를 가져옵니다.
SMT 또는 RMT 서버를 사용할 때는 다음과 같이 주소를 지정해야 합니다.
$ sudo SUSEConnect --url "https://<SMT/RMT-address>"
SUSE Customer Center를 통해 등록할 때는 다음과 같이 구독 및 이메일 주소를 사용하십시오.
$ sudo SUSEConnect -r <SubscriptionCode> -e <EmailAddress>
다른 모든 모듈에서는 기본 시스템이 필수적입니다. 설치를 시작하려면 다음과 같이 실행하십시오.
$ sudo SUSEConnect -p sle-module-basesystem/15.2/x86_64
오케스트레이션을 위해 워크스테이션을 사용하려면 먼저 다음과 같이 모든 Kubernetes 노드에서 Salt를 설치하여 구성하십시오.
$ sudo zypper in -y salt-minion $ sudo echo "master: <WorkstationIP>" > /etc/salt/minion $ sudo systemctl enable salt-minion --now
4.3 관리 워크스테이션 구성 #
관리 워크스테이션은 Kubernetes 클러스터와 이 클러스터에서 실행되는 워크로드를 배포하고 유지하는 데 사용됩니다.
4.3.1 Salt 마스터 설치 및 구성 #
Salt를 사용해 모든 Kubernetes 노드를 오케스트레이션하는 것이 좋습니다. 이 활동을 건너뛸 수 있지만 그럴 경우 향후 모든 노드를 수동으로 구성해야 합니다.
Salt를 설치하려면 다음과 같이 실행하십시오.
$ sudo zypper in -y salt-master $ sudo systemctl enable salt-master --now
다음과 같이 실행하면 모든 Kubernetes 노드가 표시되어야 합니다.
$ salt-key -L
다음과 같이 모든 미니언 키를 수락하고 확인합니다.
$ salt-key -A -y $ salt-key -L
RKE 배포에는 SSH가 필요하므로
ssh키가 있어야 합니다. 새로운 키를 생성하려면 다음과 같이 실행하십시오.$ ssh-keygen -t rsa -b 4096
생성된 키를 다음 명령을 이용해 다른 모든 노드로 배포합니다.
$ ssh-copy-id -i <path to your sshkey> root@<nodeIP>
4.3.2 Kubernetes 노드 구성 #
다음과 같이 방화벽의 상태를 확인하고 아직 비활성화되지 않은 경우 비활성화합니다.
$ sudo salt '*' cmd.run 'systemctl status firewalld' $ sudo salt '*' cmd.run 'systemctl disable firewalld --now'
다음과 같이 Kdump의 상태를 확인하고 아직 비활성화되지 않은 경우 비활성화합니다.
$ sudo salt '*' cmd.run 'systemctl status kdump' $ sudo salt '*' cmd.run 'systemctl disable kdump --now'
다음과 같이
스왑이 비활성화되었는지 확인하고 아직 비활성화되지 않은 경우 비활성화합니다.$ sudo salt '*' cmd.run 'cat /proc/swaps' $ sudo salt '*' cmd.run 'swapoff -a'
다음과 같이 NTP 시간 동기화를 확인하고 아직 활성화되지 않은 경우 활성화합니다.
$ sudo salt '*' cmd.run 'systemctl status chronyd' $ sudo salt '*' cmd.run 'systemctl enable chronyd --now' $ sudo salt '*' cmd.run 'chronyc sources'
다음과 같이 SSH 서버가 실행 중인지 확인합니다.
$ sudo salt '*' cmd.run 'systemctl status sshd' $ sudo salt '*' cmd.run 'systemctl enable sshd --now'
다음과 같이 필요한 SUSE 모듈을 활성화합니다.
$ sudo salt '*' cmd.run 'SUSEConnect -p sle-module-containers/15.2/x86_64'
다음과 같이 SAP Data Intelligence를 실행하는 데 필요한 패키지를 설치합니다.
$ sudo salt '*' cmd.run 'zypper in -y nfs-client nfs-kernel-server xfsprogs ceph-common open-iscsi'
다음과 같이
open-iscsid를 활성화합니다.$ sudo salt '*' cmd.run 'systemctl status iscsid' $ sudo salt '*' cmd.run 'systemctl enable iscsid --now'
4.4 Rancher Kubernetes Engine 2 설치 #
클러스터 노드에 RKE 2를 설치하려면 RKE 2 설치 스크립트를 다운로드하여 각 Kubernetes 클러스터 노드에 복사하십시오. 각 단계는 다음 섹션에 설명되어 있습니다.
자세한 내용은 RKE 2 빠른 시작 안내서를 참조하십시오.
4.4.1 RKE 2 설치 스크립트 다운로드 #
RKE 2 설치 스크립트를 다운로드하려면 다음 명령을 실행하십시오.
$ curl -sfL https://get.rke2.io --output install.sh $ chmod 0700 install.sh
4.4.2 RKE 2 배포 #
이제 다음과 같이 Kubernetes 클러스터를 배포하십시오.
첫 번째 단계에서는 Kubernetes 마스터 노드를 배포합니다.
두 번째 단계는 Kubernetes 클러스터의 작업자 노드를 배포하는 것입니다.
끝으로 관리 워크스테이션에서 RKE 2 클러스터에 대한 액세스 권한을 구성하고 테스트합니다.
4.4.2.1 RKE 2 마스터 노드 배포 #
이 섹션에서는 RKE 2 마스터 노드 배포에 관해 설명합니다.
앞서 다운로드한
install.sh스크립트를 모든 Kubernetes 노드(마스터 및 작업자)로 복사합니다.$ export INSTALL_RKE2_TYPE="server" $ export INSTALL_RKE2_VERSION=v1.19.8+rke2r1 $ ./install.sh
위 명령은 TAR 아카이브를 다운로드하여 로컬 시스템에 압축을 풉니다.
RKE 2 배포를 위해 다음과 같이 첫 구성 파일을 생성합니다.
$ sudo mkdir -p /etc/rancher/rke2 $ sudo cat <<EOF > /etc/rancher/rke2/config.yaml disable: rke2-ingress-nginx EOF
다음 명령을 이용해 실제 배포를 시작합니다.
$ sudo systemctl enable --now rke2-server.service
나머지 마스터 노드에 대해서는 다음 명령을 실행합니다.
$ sudo mkdir -p /etc/rancher/rke2/
/var/lib/rancher/server/token에 있는 첫 마스터 노드에서 인증 토큰을 복사합니다. 나중에 사용할 수 있도록 이 토큰을 저장합니다.RKE 2 클러스터의 다른 노드에
/etc/rancher/rke2/config.yaml이라는 파일을 생성합니다.$ sudo cat <<EOF > /etc/rancher/rke2/config.yaml server: https://<ip of first master node>:9345 token: <add token gained from first master node> disable: rke2-nginx-ingress EOF
이 파일을 나머지 마스터 및 작업자 노드로 배포합니다.
4.4.2.2 RKE 2 작업자 노드 배포 #
이 섹션에서는 RKE 2 작업자 노드 배포에 관해 설명합니다.
설치 스크립트를 작업자 노드로 복사합니다(아직 복사하지 않은 경우).
작업자 노드를 위한
/etc/rancher/rke2/config.yaml파일을 생성합니다.환경 변수를 설정하여 RKE 2 작업자 노드를 설치하고 설치 스크립트를 실행합니다.
$ export INSTALL_RKE2_VERSION=v1.19.8+rke2r1 $ export INSTALL_RKE2_TYPE="agent" $ sudo ./install.sh $ sudo systemctl enable --now rke2-agent.service
systemd 저널을 통해 설치 진행을 모니터링할 수 있습니다.
$ sudo journalctl -f -u rke2-agent
4.4.2.3 설치 확인 #
일치하는
kubectl버전을 관리 워크스테이션으로 다운로드합니다.kubectl버전 1.19.8의 예시는 아래와 같습니다.$ curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.19.8/bin/linux/amd64/kubectl $ chmod a+x kubectl $ sudo cp -av kubectl /usr/bin/kubectl
다음과 같이 첫 번째 마스터 노드에서 KUBECONFIG 파일을 가져와 관리 워크스테이션으로 복사합니다.
$ scp <first master node>:/etc/rancher/rke2/rke2.yaml <management workstation>:/path/where/kubeconfig/should/be/placed
다음과 같이
rke2.yaml의 “127.0.0.1”을 첫 번째 마스터 노드의 IP 주소로 교체합니다.$ sed -e -i 's/127.0.0.1/<ip of first master node>/' rke2.yaml
다음 명령을 실행하여 이를 확인합니다.
$ export KUBECONFIG=<PATH to your kubeconfig> $ kubectl version $ kubectl get nodes
이제 RKE 2 클러스터를 사용할 수 있게 되었습니다.
5 SAP Data Intelligence 3.1 설치 #
이 섹션에서는 RKE 2 제공 Kubernetes 클러스터에 SAP DI 3.1을 설치하는 방법에 관해 설명합니다.
5.1 준비 #
SAP DI 3.1 배포를 시작하려면 먼저 다음 단계를 실행해야 합니다.
SAP DI 3.1용 네임스페이스를 생성합니다.
보안 개인 레지스트리에 대한 액세스 권한을 생성합니다.
기본 저장 클래스를 생성합니다.
SAP SLC Bridge를 다운로드하여 설치합니다.
DI 3.1 설치 조달을 위해
stack.xml파일을 다운로드합니다.nfsd및nfsv4커널 모듈이 로드되었는지 여부 및/또는 Kubernetes 노드에 로드 가능한지 여부를 확인합니다.
5.1.1 Kubernetes 클러스터에 SAP DI 3.1용 네임스페이스 생성 #
관리 워크스테이션에 로그인하여 DI 3.1을 배포할 Kubernetes 클러스터에 네임스페이스를 생성합니다.
$ kubectl create ns <NAMESPACE for DI 31> $ kubectl get ns
5.1.2 보안 개인 레지스트리 액세스를 위한 cert 파일 생성 #
보안 개인 레지스트리용 SSL 인증서 체인을 포함하는 cert라는 파일을 생성합니다. 이로써 인증서가 SAP DI 3.1로 임포트됩니다.
$ cat CA.pem > cert $ kubectl -n <NAMESPACE for DI 31> create secret generic cmcertificates --from-file=cert
5.2 기본 저장 클래스 생성 #
SAP DI 3.1을 설치하려면 설치를 물리적 볼륨(PV)으로 조달하기 위한 기본 저장 클래스가 필요합니다. CSI를 사용하는 ceph/rbd 기반 저장 클래스의 예는 아래와 같습니다.
저장 클래스용
yaml파일을 생성하고, 저장 관리자에게 연락하여 필요한 정보를 얻습니다.다음과 같이
config-map을 생성합니다.$ cat << EOF > csi-config-map.yaml --- apiVersion: v1 kind: ConfigMap data: config.json: |- [ { "clusterID": "<ID of your ceph cluster>", "monitors": [ "<IP of Monitor 1>:6789", "<IP of Monitor 2>:6789", "<IP of Monitor 3>:6789" ] } ] metadata: name: ceph-csi-config EOF다음과 같이 저장소 액세스를 위한 비밀을 생성합니다.
$ cat << EOF > csi-rbd-secret.yaml --- apiVersion: v1 kind: Secret metadata: name: csi-rbd-secret namespace: default stringData: userID: admin userKey: AQCR7htglvJzBxAAtPN0YUeSiDzyTeQe0lveDQ== EOF
다음과 같이 파일을 다운로드합니다.
$ curl -LO https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin-provisioner.yaml
다음과 같이 파일을 다운로드합니다.
$ curl -LO https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin.yaml
다음과 같이 PV를 생성할 Ceph 저장소에 풀을 만들고 풀 이름과 Ceph 클러스터 ID를 삽입합니다.
$ cat << EOF > csi-rbd-sc.yaml --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: csi-rbd-sc provisioner: rbd.csi.ceph.com parameters: clusterID: <your ceph cluster id> pool: <your pool> csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret csi.storage.k8s.io/provisioner-secret-namespace: default csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret csi.storage.k8s.io/node-stage-secret-namespace: default reclaimPolicy: Delete mountOptions: - discard EOF
암호화를 위해
config를 생성합니다. 반드시 이렇게 해야 합니다. 그러지 않으면ceph/rbd에 대한 CSI 드라이버 배포가 실패합니다.$ cat << EOF > kms-config.yaml --- apiVersion: v1 kind: ConfigMap data: config.json: |- { }, "vault-tokens-test": { "encryptionKMSType": "vaulttokens", "vaultAddress": "http://vault.default.svc.cluster.local:8200", "vaultBackendPath": "secret/", "vaultTLSServerName": "vault.default.svc.cluster.local", "vaultCAVerify": "false", "tenantConfigName": "ceph-csi-kms-config", "tenantTokenName": "ceph-csi-kms-token", "tenants": { "my-app": { "vaultAddress": "https://vault.example.com", "vaultCAVerify": "true" }, "an-other-app": { "tenantTokenName": "storage-encryption-token" } } } } metadata: name: ceph-csi-encryption-kms-config EOF다음과 같이
ceph/rbdCSI 및 저장 클래스를 배포합니다.$ kubectl apply -f csi-config-map.yaml $ kubectl apply -f csi-rbd-secret.yaml $ kubectl apply -f \ https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-provisioner-rbac.yaml $ kubectl apply -f \ https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-nodeplugin-rbac.yaml $ kubectl apply -f csi-rbdplugin-provisioner.yaml $ kubectl apply -f csi-rbdplugin.yaml $ kubectl apply -f csi-rbd-sc.yaml $ kubectl apply -f kms-config.yaml $ kubectl patch storageclass csi-rbd-sc \ -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'다음과 같이 저장 클래스를 확인합니다.
$ kubectl get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE csi-rbd-sc (default) rbd.csi.ceph.com Delete Immediate false 103m
5.3 물리적 볼륨용 Longhorn 사용 #
유효한 대안으로 가능한 것은 SAP DI 3의 PV를 제공하기 위한 Longhorn 저장소를 배포하는 것입니다. 자세한 내용을 보려면 https://longhorn.io를 방문하십시오.
Longhorn은 저장소 액세스를 위해 CSI를 사용합니다.
5.3.1 전제 조건 #
Longhorn이 설치되는 Kubernetes 클러스터의 각 노드는 다음 요구사항을 충족해야 합니다.
일치하는 Kubernetes 버전(이는 우리가 SAP DI 3을 설치하고 있기 때문입니다.)
open-iscsi
XFS 파일 시스템에 대한 지원
nfsv4클라이언트를 설치해야 합니다.curl,lsblk,blkid,findmnt,grep,awk를 설치해야 합니다.Kubernetes 클러스터에서 탑재 전파를 활성화해야 합니다.
Longhorn 프로젝트가 제공하는 확인 스크립트를 관리 워크스테이션에 설치할 수 있습니다.
$ curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v1.1.0/scripts/environment_check.sh | bash
저장소 노드의 역할을 해야 하는 Kubernetes 작업자 노드에서 충분한 디스크 드라이브를 추가합니다. 이 디스크의 탑재 지점을 생성한 다음, 상단에 XFS 파일 시스템을 만들어 디스크를 탑재합니다. Longhorn은 데이터 저장을 위해 이 디스크를 사용하도록 구성됩니다. 디스크 크기에 대한 자세한 내용은 SAP DI 3을 위한 SAP 크기 조정 안내서를 참조하십시오.
또한 다음과 같이 iscsid가 Longhorn 노드에서 시작하는지 확인합니다.
$ sudo systemctl enable --now iscsid
5.3.2 Longhorn 설치 #
Longhorn 설치는 간단합니다. 이 안내서는 https://longhorn.io/docs/1.1.0/에서 볼 수 있는 Longhorn 설명서를 따릅니다.
다음 명령으로 배포를 시작합니다.
$ kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.0/deploy/longhorn.yaml
다음 명령으로 배포 진행을 모니터링합니다.
$ kubectl get pods \ --namespace longhorn-system \ --watch
5.3.3 Longhorn 구성 #
Longhorn 저장소 관리는 기본 제공 UI 대시보드를 통해 이루어집니다. 이 UI에 액세스하려면 Ingress를 구성해야 합니다.
5.3.3.1 기본 인증으로 Ingress 생성 #
다음과 같이 기본
auth파일을 생성합니다.$ USER=<USERNAME_HERE>; \ PASSWORD=<PASSWORD_HERE>; \ echo "${USER}:$(openssl passwd -stdin -apr1 <<< ${PASSWORD})" >> auth다음과 같이
auth파일에서 비밀을 생성합니다.$ kubectl -n longhorn-system create secret generic basic-auth --from-file=auth
다음과 같이 기본 인증으로 Ingress를 생성합니다.
$ cat <<EOF > longhorn-ingress.yaml apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: longhorn-ingress namespace: longhorn-system annotations: # type of authentication nginx.ingress.kubernetes.io/auth-type: basic # prevent the controller from redirecting (308) to HTTPS nginx.ingress.kubernetes.io/ssl-redirect: 'false' # name of the secret that contains the user/password definitions nginx.ingress.kubernetes.io/auth-secret: basic-auth # message to display with an appropriate context why the authentication is required nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required ' spec: rules: - http: paths: - path: / backend: serviceName: longhorn-frontend servicePort: 80 EOF $ kubectl -n longhorn-system apply -f longhorn-ingress.yaml
5.3.3.2 Longhorn용 디스크 공간 추가 #
이 섹션에서는 Longhorn 구현에 디스크 공간을 추가하는 방법을 설명합니다.
다음과 같이 디스크를 준비합니다.
디스크의 탑재 지점을 생성합니다.
디스크에 파티션과 파일 시스템을 생성합니다.
디스크의 파일 시스템을 생성한 탑재 지점에 탑재합니다.
이 파일 시스템에 대한 항목을
fstab에 추가합니다.이 설정을 테스트합니다(예: 파일 시스템
umount,mount -a실행, 파일 시스템이 올바르게 탑재되었는지lsblk로 확인).
다음과 같이 Longhorn UI를 사용해 추가 디스크를 구성합니다.
[노드 및 디스크 편집]을 클릭합니다.
그림 17: Longhorn UI 디스크 추가 #[디스크 추가] 버튼을 클릭합니다.
그림 18: Longhorn UI 디스크 저장 #탑재 지점을 입력하고 이 지점을 예약 가능으로 표시합니다.
[저장]을 클릭합니다.
다른 노드의 다른 디스크에 대해 이를 반복합니다.
다음과 같이 Longhorn의 UI에서 상태를 확인합니다.
Ingress에 정의된 URL을 브라우저에 입력합니다.
위에서 생성한 사용자와 비밀번호로 인증합니다.
UI는 Longhorn 저장소의 개요를 표시합니다.
자세한 내용은 Longhorn 설명서를 참조하십시오.
5.3.4 Longhorn 위에 저장 클래스 생성 #
다음 명령은 SAP DI 3.1 사용을 위해 longhorn이라는 저장 클래스를 생성합니다.
$ kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.0/examples/storageclass.yaml
이 저장 클래스에 다음과 같이 기본값으로 주석을 답니다.
$ kubectl patch storageclass longhorn \
-p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'5.3.5 Longhorn 설명서 #
자세한 내용은 Longhorn 설명서를 참조하십시오.
5.4 NetApp Trident 및 NetApp StorageGRID를 블록 및 객체 저장소로 사용 #
5.4.1 NetApp Trident 설치 #
다음과 같이 https://netapp-trident.readthedocs.io/en/stable-v21.01/에 있는 설명서에 따라 NetApp Trident를 설치합니다.
NetApp Trident 위에 저장 클래스를 생성하고 이를 기본 저장 클래스로 삼습니다.
다음과 같이 igroup을 만들고 RKE 2 작업자 노드에서 개시자 이름을 추가합니다.
RKE2 작업자 노드에 로그인하여
/etc/iscsi/initiator.iscsi에서 개시자 이름을 쿼리합니다.개시자 이름이 유일한지 확인합니다! 유일하지 않다면
iscsi-iname으로 생성된 새로운 이름으로 교체합니다.vserver 내부에 igroup을 생성하고 모든 개시자 이름을 추가합니다.
5.4.2 NetApp StorageGRID 설치 #
SAP Data Intelligence 체크포인트 저장소를 사용해야 하거나 AI/ML 시나리오를 사용해야 한다면 객체 저장소가 필수적입니다. StorageGRID를 SAP Data Intelligence용 객체 저장소로 사용하려면 다음과 같은 설치(StorageGRID가 어플라이언스로 사용되지 않는 경우) 및 구성 단계를 완료하십시오.
다음과 같이 객체 저장소를 위한 NetApp StorageGRID를 준비합니다.
공개적으로 제공되는 문서인 Kubernetes 클러스터에서 StorageGRID 배포에 나와 있는 지침을 사용해 클러스터에 StorageGRID를 설치합니다.
인증서 관리를 선택하고 사용 중인 인증서가 공식 신뢰 센터가 발급한 NetApp- StorageGRID/SSL-Certificate-Configuration(StorageGRID에 대한 SSL 인증서 구성이라는 문서에 간략히 설명되어 있음)인지 확인합니다.
테넌트 계정 및 연결 섹션에 나와 있는 지침에 따라 테넌트를 구성합니다.
S3 버킷 생성 섹션에 나와 있는 지침에 따라 생성한 테넌트에 로그인하여 버킷(예: DataHub)을 생성합니다.
다른 사용자의 S3 액세스 키 생성 섹션에 나와 있는 지침을 사용하여 액세스 키를 정의합니다. 그런 다음 생성한 액세스 키와 이에 상응하는 비밀을 저장합니다.
5.5 SLC Bridge 다운로드 #
SLC Bridge는 다음 방법으로 얻을 수 있습니다.
SAP 소프트웨어 센터(https://support.sap.com/en/tools/software-logistics-tools.html#section_622087154)에서 SLC Bridge 다운로드를 선택합니다.
https://launchpad.support.sap.com/#/notes/2589449에서 SLC Bridge의 릴리스 노트에 있는 정보를 참조합니다.
https://help.sap.com/viewer/a8d90a56d61a49718ebcb5f65014bbe7/3.1.latest/en-US/8ae38791d71046fab1f25ee0f682dc4c.html을 통해 얻을 수 있습니다.
SLC Bridge 소프트웨어를 관리 워크스테이션으로 다운로드합니다.
5.6 SLC Bridge 설치 #
SLC Bridge 바이너리의 이름을 slcb로 변경하고 실행 파일로 만듭니다. SLC Bridge를 Kubernetes 클러스터로 배포합니다.
$ mv SLCB01_XX-70003322.EXE slcb $ chmod 0700 slcb $ export KUBECONFIG=<KUBE_CONFIG> $ ./slcb init
대화형 설치 중에는 다음 정보가 필요합니다.
보안 개인 레지스트리의 URL
전문가 모드 선택
해당 서비스에 대해 NodePort 선택
SLC Bridge의 서비스 포트를 적어 둡니다. 서비스 포트는 SAP DI 3.1을 설치하거나 DI 3.1을 구성할 때 백업 활성화와 같은 목적으로 필요합니다. 적어 놓는 것을 잊어버렸다면 다음 명령으로 서비스 포트를 나열할 수 있습니다.
$ kubectl -n sap-slcbridge get svc
5.7 SAP DI 설치를 위해 스택 XML 생성 및 다운로드 #
SAP DI 3.1 설치 안내서의 클러스터에서 인터넷 액세스를 통해 SLC Bridge로 SAP Data Intelligence 설치 장에 설명된 단계를 따르십시오.
5.7.1 스택 XML 생성 #
SAP 유지보수 계획 도우미를 통해 스택 XML을 생성할 수 있습니다. https://support.sap.com/en/alm/solution-manager/processes-72/maintenance-planner.html을 통해 도구에 액세스합니다. SAP 웹 사이트에 게시된 https://apps.support.sap.com/sap/support/mp의 유지보수 계획 도우미로 이동하여 설치하려는 SAP Data Intelligence 릴리스의 컨테이너 이미지 정의가 포함된 스택 XML 파일을 생성합니다. 스택 XML 파일을 로컬 디렉토리로 다운로드합니다. stack.xml을 관리 워크스테이션으로 복사합니다.
5.8 SAP DI 설치 실행 #
SAP DI 3.1 설치는 다음 코드로 호출됩니다.
$ export KUBECONFIG=<path to kubeconfig> $ ./slcb execute --useStackXML MP_Stack_XXXXXXXXXX_XXXXXXXX_.xml --url https://<node>:<service port>/docs/index.html
이 코드는 SAP DI 3.1 구성 및 배포를 위한 대화형 프로세스를 시작합니다.
아래 표에는 SAP DI 3.1 설치에 사용할 수 있는 몇 가지 파라미터가 나열되어 있습니다.
| 파라미터 | 조건 | 권장 사항 |
|---|---|---|
Kubernetes 네임스페이스 | 항상 | 미리 생성한 네임스페이스로 설정 |
설치 유형 | 설치 또는 업데이트 | 양자택일 |
컨테이너 레지스트리 | 항상 | 보안 개인 레지스트리용 uri 추가 |
체크포인트 저장소 구성 | 설치 | 체크포인트 저장소 활성화 여부 |
체크포인트 저장소 유형 | 체크포인트 저장소가 활성화된 경우 | SES에서 S3 객체 저장소 사용 |
체크포인트 저장소 유효성 검사 | 체크포인트가 활성화된 경우 | 체크포인트 저장소 액세스 확인 |
파이프라인 모델러용 컨테이너 레지스트리 설정 | 선택 | 두 번째 컨테이너 레지스트리가 사용되는 경우 사용 |
StorageClass 구성 | 선택, 일부 구성 요소에 다른 StorageClass가 사용되는 경우 필요함 | 기본값 남김 |
기본 StorageClass | SAP DI 설치 프로그램이 감지 | Kubernetes 클러스터에는 기본 SC로 주석이 달린 저장 클래스가 있어야 함 |
Kaniko 사용 활성화 | Docker에서 실행하는 경우 선택 | 활성화 |
SAP Data Intelligence 모델러용 컨테이너 이미지 리포지토리 설정 | 필수 | |
파이프라인 모델러용 컨테이너 레지스트리 | 선택 | 파이프라인 모델러 이미지에 다른 컨테이너 레지스트리가 사용되는 경우 필요함 |
NFS 모듈 로드 | 선택 | nfsd와 nfsv4 커널 모듈이 모든 작업자 노드에 로드되는지 확인 |
추가 설치 프로그램 파라미터 | 선택 | |
SAP DI 3.1 설치를 위한 입력 파라미터에 대한 자세한 내용을 보려면 SAP Data Intelligence 설치 안내서의 필수 입력 파라미터 섹션을 방문하십시오.
5.9 설치 후 작업 #
설치 워크플로가 성공적으로 완료되면 다음과 같은 몇 가지 추가 작업을 수행해야 합니다.
다음과 같이 SSL 인증서를 가져오거나 생성하여 SAP DI 설치에 안전하게 액세스합니다.
openssl을 사용해 인증서 요청을 생성합니다. 예를 들면 다음과 같습니다.$ openssl req -newkey rsa:2048 -keyout <hostname>.key -out <hostname>.csr
다음과 같이 키를 복호화합니다.
$ openssl rsa -in <hostname>.key -out decrypted-<hostname>.key
CA가 <hostname>.csr에 서명하게 합니다. 그러면 <호스트 이름>.crt를 수신하게 됩니다.
다음과 같이 인증서에서 비밀을 생성하고 SAP DI 3 네임스페이스에 키를 생성합니다.
$ export NAMESPACE=<SAP DI 3 namespace> $ kubectl -n $NAMESPACE create secret tls vsystem-tls-certs --key decrypted-<hostname>.key--cert <hostname>.crt
nginx-ingress컨트롤러 배포자세한 내용은 https://kubernetes.github.io/ingress-nginx/deploy/#bare-metal 참조
다음과 같이 Ingress
nginx설명서에 따라nginx-ingress컨트롤러를 nodePort 서비스로 생성합니다.$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.46.0/deploy/static/provider/baremetal/deploy.yaml
다음과 같이
nginx컨트롤러가 HTTPS를 리디렉트하고 있는 포트를 확인합니다.$ kubectl -n ingress-nginx get svc ingress-nginx-controller
출력은 다음과 같이 표시되어야 합니다.
kubectl -n ingress-nginx get svc ingress-nginx-controller NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ingress-nginx-controller NodePort 10.43.86.90 <none> 80:31963/TCP,443:31106/TCP 53d
이 예시에서 TLS 포트는 31106입니다. 외부에서 SAP DI 설치에 액세스하는 데 필요하므로 포트 IP를 적어 두십시오.
다음과 같이 Ingress를 생성하여 SAP DI 설치에 액세스합니다.
$ cat <<EOF > ingress.yaml apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/force-ssl-redirect: "true" nginx.ingress.kubernetes.io/secure-backends: "true" nginx.ingress.kubernetes.io/backend-protocol: HTTPS nginx.ingress.kubernetes.io/proxy-body-size: "0" nginx.ingress.kubernetes.io/proxy-buffer-size: 16k nginx.ingress.kubernetes.io/proxy-connect-timeout: "30" nginx.ingress.kubernetes.io/proxy-read-timeout: "1800" nginx.ingress.kubernetes.io/proxy-send-timeout: "1800" name: vsystem spec: rules: - host: "<hostname FQDN must match SSL certificate" http: paths: - backend: serviceName: vsystem servicePort: 8797 path: / tls: - hosts: - "<hostname FQDN must match SSL certificate>" secretName: vsystem-tls-certs EOF $ kubectl apply -f ingress.yamlhttps://hostname:<ingress service port>에 연결하면 SAP DI 로그인 대화 상자가 표시됩니다.
5.10 SAP DaP Data Intelligence 3 설치 테스트 #
끝으로 SAP DI 3 설치를 다음과 같은 몇 가지 매우 기본적인 테스트로 확인해야 합니다.
SAP DI의 론치패드로 로그인
예시 파이프라인 생성
ML 시나리오 생성
기계 학습 테스트
vctl다운로드
자세한 내용은 SAP DI 3 설치 안내서를 참조하십시오.
6 유지보수 작업 #
이 섹션에서는 Kubernetes 클러스터, 운영 체제, SAP DI 3 배포를 유지보수하기 위해 실행해야 하고 실행할 수 있는 작업에 관한 팁을 몇 가지 제공합니다.
6.1 백업 #
장애 발생 시 환경을 복원할 수 있도록 모든 관련 데이터를 백업하는 것이 좋습니다.
정기적인 백업을 수행하려면 아래의 해당 문서에 설명된 지침을 따르십시오.
RKE 2의 경우 백업 및 재해 복구 섹션을 참조하십시오.
SAP Data Intelligence 3가 정기 백업을 생성하도록 구성할 수 있습니다. 자세한 내용을 보려면 help.sap.com( https://help.sap.com/viewer/a8d90a56d61a49718ebcb5f65014bbe7/3.1.latest/en-US/e8d4c33e6cd648b0af9fd674dbf6e76c.html)을 방문하십시오.
6.2 업그레이드 또는 업데이트 #
이 섹션에서는 SAP DI, RKE 2 및 SUSE Linux Enterprise Server 설치를 최신 상태로 유지하는 방법에 대해 설명합니다.
6.2.1 운영 체제 업데이트 #
SUSE Linux Enterprise Server 15 SP2에 대한 업데이트를 얻으려면 설치를 SUSE Customer Center, SMT 또는 RMT 서버, 또는 구독이 유효한 SUSE Manager에 등록해야 합니다.
SUSE Linux Enterprise Server 15 SP2는 다음과 같이
zypper를 사용해 명령 줄에서 업데이트할 수 있습니다.$ sudo zypper ref -s $ sudo zypper lu $ sudo zypper patch
SUSE Linux Enterprise Server 15 SP2를 업데이트하는 다른 방법은 제품 설명서에 기술되어 있습니다.
서버를 재부팅해야 업데이트가 가능한 경우 재부팅이 안전하게 이루어지도록 해야 합니다.
예를 들어 다음과 같이 재부팅 전에 SAP DI에 대한 액세스를 차단하고 Kubernetes 노드에 대해 drain 및 cordon 명령을 실행합니다.
$ kubectl edit ingress <put in some dummy port> $ kubectl drain <node>
다음과 같이 노드의 상태를 확인합니다.
$kubectl get node <node>
노드는 예약 불가로 표시되어야 합니다.
RKE 2 마스터 노드에서 다음 명령을 실행합니다.
$ sudo systemctl stop rke2-server
RKE 2 작업자 노드에서 다음 명령을 실행합니다.
$ sudo systemctl stop rke2-agent
SUSE Linux Enterprise Server 15 SP2 업데이트:
$ ssh node $ sudo zypper patch
필요한 경우 노드를 재부팅하거나 적절한 RKE 2 서비스를 시작합니다.
마스터 노드에서 다음 명령을 실행합니다.
$ sudo systemctl start rke2-server
작업자 노드에서 다음 명령을 실행합니다.
$ sudo systemctl start rke2-agent
해당 노드가 다시 표시되는지 확인하고 uncordon 명령을 실행합니다.
$ kubectl get nodes $ kubectl uncordon <node>
6.2.2 RKE 2 업데이트 #
RKE 2를 업데이트하기 전에 먼저 다음 문서를 읽으십시오.
RKE 2 설명서에 있는 업그레이드 기본 사항 섹션
이어서 다음 작업을 수행합니다.
모든 것에 대한 백업을 생성합니다.
SAP DI에 대한 액세스를 차단합니다.
RKE 2 설명서의 업그레이드 기본 사항 섹션에 따라 RKE 2 업데이트를 실행합니다.
6.2.3 SAP Data Intelligence 업데이트 #
SAP DI 3.1을 업데이트하려면 다음과 같은 SAP의 업데이트 안내서 및 노트를 따르십시오.
7 사용권 고지사항 #
Copyright ©2006–2021 SUSE LLC 및 작성자. All rights reserved.
GNU 무료 설명서 라이선스, 버전 1.2 또는 (사용자 선택에 따라) 버전 1.3의 조항에 따라 본 문서를 복사, 배포 및/또는 수정하는 권한이 허가됩니다. 그리고 각 항목에는 본 저작권 표시 및 라이선스가 설명된 고정(Invariant) 섹션이 있습니다. 라이선스 버전 1.2의 복사본은 "GNU 무료 설명서 라이선스" 섹션에 포함되어 있습니다.
SUSE, SUSE 로고 및 YaST는 미국과 기타 국가에서 SUSE LLC의 등록 상표입니다. SUSE 상표에 관해서는 https://www.suse.com/company/legal/을 참조하십시오.
Linux는 Linus Torvalds의 등록 상표입니다. 본 문서에 언급된 기타 모든 이름 또는 상표는 해당 소유주의 상표 또는 등록 상표일 수 있습니다.
본 문서는 "SUSE 모범 사례"라는 문서 시리즈 중 일부입니다. 시리즈의 각 문서는 SUSE 직원 및 제3자가 자발적으로 기여하여 작성되었습니다. 문서의 목적은 특정 작업을 수행하는 방법의 한 가지 예만을 제공하는 것입니다.
또한, SUSE는 문서에서 설명되는 작업이 해당 기능을 수행하는지 또는 의도하지 않은 결과가 제공되지 않는지를 확인할 수 없습니다.
본 문서의 모든 정보는 최대한 주의를 기울여 작성되었습니다. 그러나 이것이 문서의 정확성을 보장하지는 않습니다. 따라서 SUSE LLC, 그 계열사, 저자, 번역자 중 어느 누구도 있을 수 있는 오류나 그에 따른 결과에 책임을 지지 않는다고 명확히 진술할 필요가 있습니다. 아래에 명시된 내용은 문서를 게시할 때 준수해야 할 라이선스에 대한 주의를 환기하기 위한 것입니다.
8 GNU 무료 설명서 라이선스 #
Copyright © 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 누구나 이 라이선스 문서의 축자적 복사본을 복사 및 배포할 수 있지만 변경할 수는 없습니다.
0. 머리말#
이 라이선스의 목적은 매뉴얼, 교재 또는 기타 실용적이고 유용한 문서를 자유라는 의미에서 "무료"로 만드는 것 즉, 이러한 문서를 상업적이나 비상업적인 용도로 수정하든 수정하지 않든 복사하고 재배포할 수 있는 실질적인 자유를 모든 사람에게 보장하는 것입니다. 두 번째로 원저자 및 게시자의 경우 작업에 대한 크레딧을 받지만 다른 사용자가 수정한 사항에 대해서는 책임지지 않는 방식으로 이 라이선스가 유지됩니다.
이 라이선스는 일종의 "카피레프트"이므로 문서의 2차적 저작물도 동일하게 무료여야 합니다. 또한 무료 소프트웨어를 위해 설계된 카피레프트 라이선스인 GNU General Public License를 보완합니다.
당사는 무료 소프트웨어용 매뉴얼에 사용하기 위해 이 라이선스를 설계했습니다. 무료 소프트웨어에는 무료 설명서가 필요하기 때문입니다. 즉, 무료 프로그램에는 소프트웨어에 부여되는 것과 동일한 자유를 부여하는 매뉴얼이 함께 제공되어야 합니다. 하지만 이 라이선스는 소프트웨어 매뉴얼로만 제한되지 않고 주제나 인쇄된 책으로 출판되었는지 여부와 상관없이 모든 글에 사용될 수 있습니다. 이 라이선스는 주로 지침 또는 참조용 문서에 사용하는 것이 좋습니다.
1. 적용 가능성 및 정의#
이 라이선스는 이 라이선스 조건에 따라 배포할 수 있다는 표시를 저작권 소유자가 배치한 모든 매체의 매뉴얼 또는 기타 문서에 적용됩니다. 이러한 표시는 전 세계에서 기간에 제한 없이 해당 문서를 여기에 명시된 조건에 따라 사용할 수 있는 로열티 없는 라이선스를 부여합니다. 아래에서 "문서"는 이러한 매뉴얼 또는 작업을 나타냅니다. 모든 일반인이 정식 사용자이며 "귀하"라고 부릅니다. 저작권법에 따라 사용 권한이 필요한 방식으로 작업을 복사, 수정 또는 배포하는 경우 라이선스에 동의하는 것입니다.
문서의 "수정된 버전"이란 문서 전체 또는 일부를 그대로 또는 수정하여 복사하거나 다른 언어로 번역한 작업을 의미합니다.
"보조 섹션"에서는 문서의 명명된 부록 또는 전문 섹션으로 문서의 게시자 또는 원저자와 문서 전체 주제(또는 관련 사항) 간 관계만을 다루고 해당 전체 주제에 직접 속할 수 있는 내용은 포함하지 않습니다. (따라서 문서가 부분적으로 수학 교재인 경우 보조 섹션에서 수학을 설명할 수 없습니다.) 관계는 주제 또는 관련 사항과의 역사적 연관이나 이와 관련된 법률적, 상업적, 철학적, 윤리적 또는 정치적 입장일 수 있습니다.
"고정 섹션"은 특정 보조 섹션으로 문서가 이 라이선스에 따라 릴리스된다는 표시에서 해당 섹션 제목이 고정 섹션의 제목으로 지정됩니다. 보조에 대한 위 정의에 맞지 않는 섹션은 고정으로 지정할 수 없습니다. 문서에 고정 섹션이 0개일 수 있습니다. 문서에서 고정 섹션을 식별하지 않는 경우 고정 섹션이 없는 것입니다.
"표지 텍스트"는 문서가 이 라이선스에 따라 릴리스된다는 표시에서 앞표지 텍스트 또는 뒤표지 텍스트로 나열되는 짧은 특정 구절입니다. 앞표지 텍스트는 최대 5단어일 수 있고 뒤표지 텍스트는 최대 25단어일 수 있습니다.
문서의 "투명한" 복사본은 일반 대중에게 사양이 제공된 형식으로 표시된 시스템에서 판독 가능한 복사본을 의미하며, 일반 텍스트 편집기, 일반 페인트 프로그램(픽셀로 구성된 이미지의 경우) 또는 널리 사용되는 그리기 편집기(그림의 경우)로 문서를 쉽게 수정하는 데 적합하고 텍스트 포맷터에 입력하거나 텍스트 포맷터에 입력할 수 있는 다양한 형식으로 자동 변환하는 데 적합합니다. 구독자의 후속 수정을 저지하거나 막기 위해 마크업이 배열되어 있거나 마크업이 없는 다른 투명한 파일 형식으로 만든 복사본은 투명이 아닙니다. 이미지 형식은 상당한 양의 텍스트에 사용되는 경우 투명이 아닙니다. "투명"이 아닌 복사본은 "불투명"이라고 합니다.
투명한 복사본에 적합한 형식의 예로는 마크업이 없는 일반 ASCII, Texinfo 입력 형식, LaTeX 입력 형식, 공개적으로 사용 가능한 DTD를 사용하는 SGML 또는 XML, 표준을 준수하는 단순 HTML, 사람이 수정하도록 설계된 PostScript 또는 PDF 등이 있습니다. 투명한 이미지 형식의 예로는 PNG, XCF 및 JPG가 있습니다. 불투명한 형식에는 소유 워드 프로세서에서만 읽고 편집할 수 있는 소유 형식, DTD 및/또는 처리 도구가 일반 공급되지 않는 SGML 또는 XML, 시스템 생성 HTML, 일부 워드 프로세서에서 출력용으로만 생성하는 PostScript 또는 PDF 등이 있습니다.
"제목 페이지"는 인쇄된 책의 경우 제목 페이지 자체와 이 라이선스가 제목 페이지에 표시되어야 하는 자료를 읽기 쉽게 유지하기 위해 필요한 다음 페이지를 의미합니다. 제목 페이지가 없는 형식의 작업인 경우 "제목 페이지"는 본문 시작 부분 앞에 나오며 눈에 가장 잘 띄는 작업 제목 옆의 텍스트를 의미합니다.
"XYZ라는 제목" 섹션은 제목이 정확히 XYZ이거나 XYZ를 다른 언어로 번역하는 텍스트 다음의 괄호 안에 XYZ를 포함하는 문서의 명명된 하위 단위를 의미합니다. (여기서 XYZ는 "승인", "헌신", "보증" 또는 "이력"과 같은 아래에 열거된 특정 섹션 이름을 나타냅니다.) 문서를 수정할 때 이러한 섹션의 "제목을 유지"한다는 것은 이 정의에 따라 "XYZ라는 제목" 섹션을 유지한다는 것을 의미합니다.
문서에서 이 라이선스가 문서에 적용된다는 표시 옆에 보증 부인이 포함될 수 있습니다. 이러한 보증 부인은 이 라이선스에 참조로 포함되지만 보증 부인으로만 간주되며, 이러한 보증 부인에 있을 수 있는 다른 의미는 법적 효력이 없고 이 라이선스의 의미에 아무 영향을 미치지 않습니다.
2. 축자적 복사#
이 라이선스, 저작권 표시 및 이 라이선스가 문서에 적용된다는 라이선스 표시를 모든 복사본에 복제하고 이 라이선스 조건에 다른 조건을 전혀 추가하지 않는 경우 상업적으로나 비상업적으로 문서를 원하는 매체에 복사하고 배포할 수 있습니다. 만들거나 배포하는 복사본을 읽거나 추가로 복사하지 못하도록 방지 또는 통제하는 기술적 조치를 사용해서는 안 됩니다. 그러나 복사본에 대한 답례로 보상을 받을 수는 있습니다. 많은 수의 복사본을 배포하는 경우에는 섹션 3의 조건도 준수해야 합니다.
또한 위에 명시된 것과 동일한 조건에 따라 복사본을 임대할 수도 있고 복사본을 공개적으로 표시할 수도 있습니다.
3. 대량 복사#
문서의 인쇄된 복사본(또는 일반적으로 인쇄된 표지가 있는 매체의 복사본)을 100부 이상 게시하고 문서 라이선스 표시에 표지 텍스트가 필요한 경우 앞표지의 앞표지 텍스트와 뒤표지의 뒤표지 텍스트가 모두 명확하고 읽기 쉽게 붙어 있는 표지로 복사본을 묶어야 합니다. 또한 두 표지에서는 귀하를 이러한 복사본의 게시자로 명확하고 읽기 쉽게 식별해야 합니다. 앞표지에서는 전체 제목을 표시해야 하며 제목의 모든 단어를 똑같이 눈에 띄게 표시해야 합니다. 표지에 다른 자료를 추가할 수도 있습니다. 표지로 한정된 변경 사항을 포함하는 복사는 문서 제목을 유지하고 이러한 조건을 충족하는 경우 다른 면에서는 축자적 복사로 간주될 수 있습니다.
어느 표지든 필요한 텍스트가 너무 방대하여 읽기 쉽지 않은 경우 나열되는 첫 텍스트(적당히 맞을 만큼)를 실제 표시에 넣고 나머지는 다음 페이지에서 계속해야 합니다.
문서의 불투명한 복사본을 100부 이상 게시 또는 배포하는 경우 시스템에서 판독 가능한 투명한 복사본을 각 불투명한 복사본과 함께 포함하거나 각 불투명한 복사본 내에 일반 네트워크 사용 대중이 공용 표준 네트워크 프로토콜을 사용하여 문서의 전체 투명한 복사본을 추가 자료 없이 다운로드하기 위한 액세스 권한이 있는 컴퓨터 네트워크 위치를 명시해야 합니다. 후자 옵션을 사용하는 경우 불투명한 복사본 대량 배포를 시작할 때 해당 버전의 불투명한 복사본을 직접 또는 에이전트나 소매점을 통해 대중에게 배포하는 마지막 시간 이후 최소 1년까지 명시된 위치에서 이 투명한 복사본을 액세스 가능하도록 유지하기 위해 상당히 신중한 단계를 수행해야 합니다.
필수는 아니지만 대량 복사본을 재배포하기 전에 문서의 원저자에게 문의하여 문서의 업데이트된 버전을 제공할 기회를 주도록 요청받습니다.
4. 수정#
문서의 수정된 버전을 위 섹션 2 및 3의 조건에 따라 복사 및 배포할 수 있습니다. 단, 수정된 버전을 정확히 이 라이선스에 따라 릴리스하여 수정된 버전이 문서의 역할을 다하고 해당 복사본을 소유하는 모든 사람에게 수정된 버전을 배포 및 수정할 수 있도록 허여해야 합니다. 또한 수정된 버전에서 다음 작업을 수행해야 합니다.
제목 페이지 및 표지(있는 경우)에 문서의 제목 및 이전 버전의 제목(있는 경우 문서의 이력 섹션에 나열해야 함)과 다른 제목을 사용합니다. 해당 버전의 원래 게시자가 사용 권한을 부여한 경우 이전 버전과 동일한 제목을 사용할 수 있습니다.
제목 페이지에 문서의 주 원저자 5인 이상(5인 이하인 경우 주 원저자 모두)과 함께 수정된 버전의 수정 작업을 담당하는 하나 이상의 개인 또는 법인을 저자로 나열합니다. 단, 원저자가 이 요구 사항을 해제한 경우는 제외합니다.
제목 페이지에 수정된 버전의 게시자 이름을 게시자로 명시합니다.
문서의 저작권 표시를 모두 유지합니다.
자신이 수정한 사항에 대한 적절한 저작권 표시를 다른 저작권 표시 옆에 추가합니다.
저작권 표시 바로 뒤에 이 라이선스 조건에 따라 수정된 버전을 사용할 수 있는 공용 권한을 부여하는 라이선스 표시를 아래 추록에 표시된 양식으로 포함합니다.
해당 라이선스 표시에 문서 라이선스 표시에 지정된 고정 섹션 및 필수 표지 텍스트의 전체 목록을 유지합니다.
이 라이선스의 변경되지 않은 복사본을 포함합니다.
"이력"이라는 제목의 섹션을 유지하고 해당 제목을 유지하며 제목 페이지에 지정된 대로 최소한 수정된 버전의 제목, 연도, 새 원저자 및 게시자를 명시하는 항목을 이 섹션에 추가합니다. 문서에 "이력"이라는 제목의 섹션이 없는 경우 제목 페이지에 지정된 대로 문서의 제목, 연도, 원저자 및 게시자를 명시하는 섹션을 만든 다음 이전 문장에 명시된 대로 수정된 버전을 설명하는 항목을 추가합니다.
문서의 투명한 복사본에 대한 공용 액세스를 위해 문서에 지정된 네트워크 위치(있는 경우)를 유지하고 마찬가지로 문서가 기반으로 하는 이전 버전에 대해 문서에 지정된 네트워크 위치도 유지합니다. 이러한 위치는 "이력" 섹션에 배치할 수 있습니다. 문서 자체보다 최소 4년 전에 게시된 작업의 경우 또는 문서가 참조하는 버전의 원래 게시자가 사용 권한을 부여하는 경우 네트워크 위치를 생략할 수 있습니다.
"승인" 또는 "헌신"이라는 섹션의 경우 섹션 제목을 유지하고 섹션에서 지정된 각 제공자 승인 및/또는 헌신의 요지와 어조를 모두 유지합니다.
문서의 모든 고정 섹션을 해당 텍스트와 제목이 변경되지 않은 상태로 유지합니다. 섹션 번호 또는 이에 해당되는 항목은 섹션 제목의 일부로 간주되지 않습니다.
"보증"이라는 제목의 섹션은 삭제합니다. 이러한 섹션은 수정된 버전에 포함하면 안 됩니다.
기존 섹션의 제목을 "보증"이라는 제목 또는 고정 섹션과 충돌하는 제목으로 변경하지 마십시오.
보증 부인을 유지합니다.
수정된 버전에 보조 섹션으로 선별되고 문서의 자료가 복사되지 않은 새 전문 섹션이나 부록이 포함되는 경우 선택에 따라 이러한 섹션의 일부 또는 전부를 고정 섹션으로 지정할 수 있습니다. 이렇게 하려면 수정된 버전의 라이선스 표시에서 해당 제목을 고정 섹션 목록에 추가하십시오. 이러한 제목은 다른 섹션 제목과 달라야 합니다.
"보증"이라는 제목의 섹션은 다양한 당사자의 수정된 버전에 대한 보증(예: 동종 업계 평가에 대한 문구) 외의 내용을 포함하지 않거나 해당 내용을 조직에서 표준에 대한 신뢰할 수 있는 정의로 승인한 경우 추가할 수 있습니다.
수정된 버전에서 표시 텍스트 목록 끝에 최대 5단어 구절을 앞표지 텍스트로, 최대 25단어 구절을 뒤표지 텍스트로 추가할 수 있습니다. 한 법인이 앞표지 텍스트 구절 하나와 뒤표지 텍스트 구절 하나만 직접(또는 체결한 계약을 통해) 추가할 수 있습니다. 기존에 직접 또는 대표하는 동일한 업체가 체결한 계약을 통해 추가된 동일한 표지에 대한 표지 텍스트가 문서에 이미 포함되어 있는 경우 다른 표지 텍스트를 추가할 수 없지만 이전 표지 텍스트를 추가한 이전 게시자의 명시적 사용 권한을 받고 이전 표지 텍스트를 바꿀 수는 있습니다.
문서의 원저자 및 게시자는 이 라이선스에 의해 자신의 이름을 홍보에 사용하거나 수정된 버전에 대한 보증을 주장하거나 의미할 수 있는 사용 권한을 부여하지 않습니다.
5. 문서 결합#
위 섹션 4에서 수정된 버전에 대해 정의된 조건에 따라 문서를 이 라이선스에 따라 릴리스된 다른 문서와 결합할 수 있습니다. 단, 결합한 문서에 모든 원래 문서의 모든 고정 섹션을 수정하지 않고 포함하고 이들 섹션 모두를 라이선스 표시에서 결합한 문서의 고정 섹션으로 나열하고 해당하는 보증 부인을 모두 유지해야 합니다.
결합한 문서는 이 라이선스의 복사본 하나만 포함하면 되며 여러 동일한 고정 섹션을 하나의 복사본으로 대체할 수 있습니다. 이름은 같지만 내용이 다른 고정 섹션이 여럿인 경우 각 섹션 제목 끝에 해당 섹션 원래 원저자 또는 게시자 이름(아는 경우)이나 고유 번호를 추가하여 섹션 제목을 고유하게 만드십시오. 결합한 문서의 라이선스 표시에서 고정 섹션 목록에 있는 섹션 제목을 동일하게 조정하십시오.
결합에서는 다양한 원래 문서에 있는 "이력"이라는 제목의 모든 섹션을 결합하여 "이력"이라는 제목의 섹션 하나를 형성해야 하며, 마찬가지로 "승인"이라는 섹션과 "헌신"이라는 섹션도 결합해야 합니다. "보증"이라는 섹션은 모두 삭제해야 합니다.
6. 문서 모음#
문서와 이 라이선스에 따라 릴리스된 다른 문서로 구성된 모음을 만들 수 있고 다양한 문서에 있는 이 라이선스의 개별 복사본을 모음에 포함되는 단일 복사본으로 바꿀 수 있습니다. 단, 다른 모든 면에서는 각 문서의 축자적 복사에 대한 이 라이선스 규칙을 따라야 합니다.
이러한 모음에서 단일 문서를 추출하고 이 라이선스에 따라 개별적으로 배포할 수 있습니다. 단, 이 라이선스의 복사본을 추출한 문서에 삽입하고 다른 모든 면에서 해당 문서의 축자적 복사와 관련된 이 라이선스 규칙을 준수해야 합니다.
7. 독립 문서 취합#
문서 또는 해당 2차적 저작물을 다른 별도의 독립 문서 또는 작업과 한 볼륨의 저장 또는 배포 매체로 컴파일하는 것을 컴파일로 인해 발생하는 저작권이 개별 작업에서 허용하는 권한을 넘어 컴파일 사용자의 법적 권한을 제한하는 데 사용되지 않는 경우 "취합"이라고 합니다. 문서가 취합에 포함되는 경우 문서의 2차적 저작물이 아닌 취합의 다른 작업에는 이 라이선스가 적용되지 않습니다.
섹션 3의 표지 텍스트 요구 사항이 문서의 이러한 복사본에 적용되고 문서가 전체 취합의 절반 이하인 경우 문서 표지 텍스트가 취합 내에서 문서를 묶는 표지 또는 문서가 전자적 형식인 경우 표지에 해당하는 전자적 항목 내에 배치될 수 있습니다. 그렇지 않은 경우 전체 취합을 묶는 인쇄된 표지에 문서 표지 텍스를 표시해야 합니다.
8. 번역#
번역은 수정으로 간주되므로 섹션 4의 조건에 따라 문서의 번역을 배포할 수 있습니다. 고정 섹션을 번역으로 대체하려면 해당 저작권 소유자의 특별한 사용 권한을 받아야 하지만 이러한 고정 섹션의 원래 버전에 추가하여 고정 섹션 일부 또는 전부에 대한 번역을 포함할 수는 있습니다. 이 라이선스, 문서의 모든 라이선스 표시 및 보증 부인의 번역을 포함할 수 있습니다. 단, 이 라이선스의 원래 영어 버전과 해당 라이선스 표시 및 부인의 원래 버전도 포함해야 합니다. 이 라이선스, 라이선스 표시 또는 부인의 번역과 원래 버전이 불일치하는 경우에는 원래 버전이 우선합니다.
문서 섹션의 제목이 "승인", "헌신" 또는 "이력"인 경우 제목 유지(섹션 1)에 대한 요구 사항(섹션 4)을 따르려면 일반적으로 실제 제목을 변경해야 합니다.
9. 종료#
이 라이선스에 따라 명시적으로 제공된 경우를 제외하고는 문서를 복사, 수정, 서브라이선스 또는 배포할 수 없습니다. 문서를 복사, 수정, 서브라이선스 또는 배포하려는 기타 시도는 효력이 없으며 이 라이선스에 따라 권한이 자동으로 종료됩니다. 그러나 귀하에게서 이 라이선스에 따라 복사본 또는 권한을 받는 당사자는 계속 완벽히 준수하는 한 라이선스가 종료되지 않습니다.
10. 이 라이선스의 향후 수정#
Free Software Foundation은 언제든지 GNU Free Documentation License의 수정된 새 버전을 게시할 수 있습니다. 이러한 새 버전은 현재 버전과 정신은 유사하지만 새 문제나 우려를 해결하는 세부 내용은 다를 수 있습니다. http://www.gnu.org/copyleft/를 참조하십시오.
각 라이선스 버전에는 구분하는 버전 번호가 지정됩니다. 문서에서 이 라이선스의 특정 버전 "또는 후속 버전"을 적용하도록 지정하는 경우 Free Software Foundation에서 게시한(초안이 아님) 지정된 해당 버전 또는 후속 버전의 규정 및 조건을 따를 수 있습니다. 문서에서 이 라이선스의 버전 번호를 지정하지 않는 경우 Free Software Foundation에서 지금까지 게시한 버전(초안이 아님) 중에서 선택할 수 있습니다.
추록: 문서에 이 라이선스를 사용하는 방법#
Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.
고정 섹션, 앞표지 텍스트 및 뒤표지 텍스트가 있는 경우 “ with…Texts” 줄을 다음과 같이 교체하십시오.
with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
표지 텍스트가 없는 고정 섹션이 있거나 이 세 가지 항목의 조합이 다른 경우 상황에 맞게 이러한 두 가지 대안을 합치십시오.
문서에 프로그램 코드 예제가 적지 않게 포함된 경우 GNU General Public License와 같은 선택한 무료 소프트웨어 라이선스에 따라 이러한 예제를 동시에 릴리스하여 무료 소프트웨어에서 사용할 수 있도록 허가하는 것이 좋습니다.