NetApp Tech Blog에 갔다가 흥미로운 주제의 글이 보여서 AI 번역(+약간 수정)의 힘을 빌려 읽어보았습니다.
출처: https://community.netapp.com/t5/Tech-ONTAP-Blogs/Central-User-Management-with-NFSv4-1-Improving-Performance-and-Flexibility-for/ba-p/464702
소개
이 문서에서는 Microsoft Active Directory(AD) 서버에서 중앙 집중식 사용자 관리를 통해 SAP(HANA) 시스템을 운영하기 위한 NFSv4.1 사용법을 설명합니다. 중앙에서 관리되는 사용자는 NetApp 스토리지 시스템과 SAP 시스템이 실행되는 Linux 서버 모두에서 사용되어 세부적인 접근 권한 및 권한 배분을 보장합니다.
” NFS를 사용하는 NetApp AFF 시스템의 SAP HANA – 구성 가이드 ” 문서에서는 NFSv4.1 프로토콜을 사용할 때 “-v4-numeric-ids” 매개변수를 “disabled”로 설정할 것을 권장합니다. 이 매개변수는 NFSv4 서버가 NFS 클라이언트로 숫자 UID/GID 값 또는 이름(사용자 및 그룹 이름)을 전송할지 여부를 결정합니다. “-v4-numeric-ids = enabled”로 설정하면 ONTAP은 문자열 이름 대신 숫자 ID(UID/GID)만 클라이언트로 전송합니다. “-v4-numeric-ids = disabled”로 설정하면 서버는 사용자 및 그룹 이름을 전송하려고 시도합니다. 이를 위해서는 이름 확인(LDAP, NIS 또는 로컬 사용자/그룹)이 제대로 작동해야 합니다. 일관된 이름 확인이 불가능한 경우, 볼륨에 저장된 파일의 소유자가 사용자 “nobody”(사용자 ID 65534)와 그룹 “nogroup”(그룹 ID 65534)으로 표시될 수 있습니다. 이러한 소유권 할당으로 인해 해당 볼륨에서 애플리케이션이 제대로 실행되지 않을 수 있습니다.
이 문서는 다음 분야에 대한 지식을 전제로 합니다.
- 리눅스 – 특히 NFSv4.1, 사용자 및 그룹 구성
- Windows – Active Directory 관리, 사용자 및 그룹 관리
- NetApp ONTAP – SVM(스토리지 가상 머신) 관리 및 구성
NFSv4.1과 비교했을 때, NFSv3은 숫자 UID와 GID만 사용하기 때문에 일관된 이름 확인이 필요하지 않습니다.
최신 SAP 아키텍처에서 NFS의 주요 장점: SAN 대비 이점
최신 SAP 환경에서 스토리지 시스템은 자동화를 통해 높은 수준의 유연성을 확보하기 위해 NFS로 연결됩니다. NFS는 SAN에 비해 다음과 같은 장점을 제공합니다.
- NFS는 IP 네트워크를 통한 간편한 관리를 가능하게 합니다. 특별한 파이버 채널 인프라는 필요하지 않습니다.
- NFS 마운트는 서버 간 공유가 용이하고 공유 액세스를 허용하는 반면, SAN 기반 LUN은 일반적으로 하나의 호스트에만 할당되며 LUN 할당을 변경하려면 SAN 인프라를 조정해야 하는 경우가 많습니다.
- LAN 환경의 개발 속도는 SAN 환경보다 훨씬 빠릅니다(LAN의 현재 표준은 100Gbit/s이며, 향후 200Gbit/s 및 400Gbit/s로 도약할 것으로 예상됩니다. SAN의 현재 표준은 32Gbit/s이며, 향후 64Gbit/s로 도약할 것으로 예상됩니다).
- 스토리지 프로토콜로 NFS를 사용하면 고가의 전용 SAN 구성 요소(스위치, HBA 등)에 대한 비용이 절감됩니다.
- NFS를 사용하면 FC 인프라에 비해 벤더 종속성이 훨씬 낮아집니다.
- 적절하게 최적화된 인프라를 사용하면 지연 시간이 거의 동일합니다.
- 향후 NFS를 사용한 데이터 처리량은 FC를 사용한 경우보다 훨씬 높아질 것입니다. (이더넷 400Gbps vs. FC 64Gbps)
NFSv3와 NFSv4 비교: NFSv4가 더 나은 이유
1995년에 발표된 최초의 NFSv3 사양은 UDP 프로토콜을 기반으로 했으며 서버 인증만 지원했습니다. 2010년에 발표된 NFSv4.1 사양은 TCP 프로토콜을 사용하고 단일 TCP 포트만 필요로 하며 서버 인증 외에 사용자 인증도 지원합니다. NFSv4.1은 NFSv3에 비해 특히 파일 및 공유에 대한 접근 보안이 강화되는 등 여러 장점을 가지고 있어 많은 기업들이 NFSv4.1 프로토콜을 도입하고 있습니다.
NFSv4.1 사용자 인증 보안 메커니즘을 사용하려면 NFSv4.1을 통해 파일에 액세스할 사용자가 NFS 서버와 클라이언트 모두에 등록되어 있어야 합니다. 한 가지 방법은 NFS 서버와 모든 NFS 클라이언트에 사용자를 로컬로 생성하는 것이고, 다른 방법은 Microsoft Active Directory(AD) 서버와 같은 중앙 사용자 관리 시스템을 통해 사용자를 제공하는 것입니다.
분산형 사용자 관리의 단점
데이터 센터에서 분산형 사용자 관리란 사용자 계정, 권한 및 접근 제어가 중앙에서 관리되는 것이 아니라 각 시스템에서 로컬로 유지 관리된다는 것을 의미합니다.
이 방식은 소규모 환경에서는 효과적일 수 있지만, 대규모 IT 인프라에서는 상당한 단점이 있습니다.
- 관리 노력 증가:
사용자 계정은 여러 시스템에서 개별적으로 생성, 수정 및 삭제해야 합니다.
이로 인해 작업이 중복되고 관리자의 시간이 늘어납니다. - 보안 위험:
관리되지 않는 계정은 시스템에서 잊혀져 활성 상태로 남아 있는 경우가 많습니다.
관리 소홀로 인해 권한 제어 및 규정 준수 확보가 어려워집니다. - 일관성 및 투명성 부족:
서로 다른 시스템에는 상충되거나 오래된 사용자 정보가 포함될 수 있습니다.
누가 어떤 정보에 접근 권한이 있는지 파악할 수 있는 중앙 집중식 관점이 없습니다. - 접근 관리 및 역할 관리의 어려움
역할 및 권한 개념은 중앙에서 시행하거나 검증하기 어렵습니다. - 사용자 프로비저닝 지연:
개별 시스템에 사용자가 누락되면 시스템 배포가 지연됩니다. - 확장성이 낮음.
시스템과 사용자 수가 증가함에 따라 필요한 노력은 선형적으로 증가하는 것이 아니라 기하급수적으로 증가합니다. - 감사 용이성 및 규정 준수 문제:
보안 점검, 검토 및 감사가 훨씬 더 복잡해지고 있습니다.
따라서 현대 조직은 사용자, 그룹 및 권한을 일관되고 자동으로 관리하기 위해 Active Directory와 같은 중앙 집중식 ID 및 액세스 관리 시스템에 의존합니다.
Windows Active Directory(AD) 구성
이 장에서는 기존 Windows Active Directory에서 필요한 사용자 및 그룹을 생성하고 구성하여 시스템 전체에서 일관된 사용자 및 그룹 ID를 사용하도록 하는 방법을 설명합니다.
일관된 사용자 및 그룹 ID 사용을 보장하려면 Windows AD 사용자 및 그룹의 속성을 설정해야 합니다. 이러한 속성은 “Advanced Features”이 활성화된 경우에만 설정할 수 있습니다. 아래 스크린샷과 같이 “Advanced Features”을 활성화하십시오.
AD 그룹 “sapsys”를 추가하세요.
이제 Active Directory에 “sapsys” 그룹을 생성하고 있습니다.
“sapsys” 그룹을 생성합니다.
다음으로 “sapsys” 그룹을 선택한 다음 “Properties”을 마우스 오른쪽 버튼으로 클릭하고 “Properties” 내에서 “Attribute Editor”를 클릭합니다.
“Attribute Editor”에서 “gidNumber” 속성에 그룹 ID를 할당합니다. 이 ID는 모든 Linux 서버와 ONTAP SVM에서 “sapsys” 그룹에 부여됩니다. 예시에서는 그룹에 “233”이라는 그룹 ID가 할당됩니다.
SAP 시스템 사용자 추가
설명을 위해 도메인 이름이 “MASTER”인 예시 Windows 도메인에 “tstadm”이라는 사용자 이름을 가진 샘플 사용자를 생성하겠습니다.
다음으로, 사용자 “tstadm”을 선택한 다음 마우스 오른쪽 버튼을 클릭하고 “Properties”을 선택합니다.
“Properties”에서 “Attribute Editor”를 선택합니다.
“Attribute Editor”에서 사용자 “tstadm”에 대해 다음과 같은 속성을 구성합니다.
- gidNumber
- uidNumber
- uid
- unixHomeDirectory
- loginShell
먼저, “sapsys” 그룹은 SAP 시스템 관리 사용자의 기본 그룹이므로, “tstadm” 사용자에게도 “sapsys” 그룹에 할당한 것과 동일한 그룹 ID를 할당합니다. 따라서 “gidNumber” 속성으로 이동하여 “233” 값을 할당하십시오.
사용자 “tstadm”에 그룹 ID “233” 할당
다음으로 사용자 “tstadm”에게 고유한 사용자 ID를 할당합니다. 예시에서 사용자 “tstadm”은 속성 파일 “uidNumber”에 사용자 ID “1233”을 할당받습니다. 시스템 전체에 걸쳐 중복된 사용자 ID가 없도록 주의하십시오.
다음으로, 사용자의 사용자 이름을 할당하여 “uid” 속성을 구성합니다. 예시에서 사용자 이름은 “tstadm”입니다.
사용자의 홈 디렉터리를 구성해야 합니다. Linux 서버에 홈 디렉터리가 존재하지 않으면 사용자가 처음 로그인할 때 생성됩니다(사용자 전환(su) 시에도 마찬가지입니다). 사용자 “tstadm”에는 기본 홈 디렉터리 “/home/tstadm”이 할당됩니다.
다음으로, 사용자 “tstadm”의 로그인 셸을 구성합니다. SAP 시스템 관리자의 기본 셸은 “csh”이므로 “loginShell” 속성에 “/bin/csh” 값을 할당합니다. 할당된 셸이 Linux 서버에 설치되어 있는지 확인해야 합니다.
이제 필요한 Windows Active Directory 사용자 및 그룹 구성이 완료되었습니다.
ONTAP 스토리지 시스템 구성
저희 환경에서는 NetApp ONTAP 9.16.1P6 버전이 설치된 NetApp 시스템을 사용하고 있습니다.
Microsoft Windows Active Directory에서 중앙 집중식 사용자 관리를 사용하려면 NetApp SVM을 Windows Active Directory에 추가해야 합니다. 추가 방법은 두 가지가 있습니다.
- 기존 SVM을 Windows Active Directory에 추가
- 새 SVM을 생성하고 생성 시 이 SVM을 Windows Active Directory에 추가하도록 지정합니다.
기존 SVM을 AD에 추가합니다.
기존 SVM을 구성하려면 Active Directory에 추가해야 합니다.
기존 SVM에는 두 가지 옵션이 있습니다.
- SVM에서 CIFS가 전혀 활성화되어 있지 않습니다.
SVM에 CIFS 서버를 생성하고 SVM을 Active Directory에 한 번에 추가할 수 있습니다. 다음 문서에 설명된 단계를 수행하십시오.
https://docs.netapp.com/us-en/ontap-cli/vserver-cifs-create.html - SVM은 CIFS를 워크그룹으로 활성화했습니다.
SVM을 Active Directory에 추가하려면 다음 문서에 설명된 단계를 수행하십시오.
https://docs.netapp.com/us-en/ontap/smb-admin/join-svm-active-directory-domain-task.html
새로운 SVM을 생성하고 AD에 추가하세요.
이 장에서는 새 SVM을 설정하고 설치 과정에서 Microsoft Active Directory에 직접 통합하는 방법을 설명합니다.
다음 그림은 이미 존재하는 SVM을 보여줍니다.
“+ Add” 버튼을 클릭하면 CIFS 및 NFS 프로토콜을 모두 지원하는 새 SVM이 생성됩니다. 이 SVM의 이름은 “smb-svm”입니다. 다음으로, SVM이 생성 즉시 Microsoft Active Directory에 추가될 수 있도록 Microsoft Active Directory 설정을 구성합니다.
다음 항목들을 모두 작성해야 합니다.
- Administrator Name:
Microsoft Active Directory에 컴퓨터를 추가하는 데 필요한 권한을 가진 사용자 - Password
사용자의 비밀번호 - Server Name:
Active Directory에서 SVM이 생성될 때 사용할 이름입니다. 이 이름은 SVM의 IP 주소로 DNS에서 확인 가능해야 합니다. - Active Directory domain
- Organizational Unit:
SVM이 생성될 Microsoft Active Directory의 폴더/그룹 - Domains
DNS 검색 도메인 - Name Servers
DNS 서버
다음으로 NFS 프로토콜을 통한 액세스를 활성화합니다. NFS 프로토콜을 통해 SVM에 액세스하려면 SVM에서 기존 볼륨을 마운트할 수 있는 IP 주소 또는 IP 주소 범위를 지정하는 내보내기 정책을 구성합니다. 그런 다음 기본 언어를 설정하고 SVM 액세스에 사용할 IP 주소를 구성합니다. 또한 지정한 암호를 사용하여 “vsadmin” 사용자로 SVM에 대한 관리자 액세스를 활성화합니다. 관리자 액세스 활성화는 구성된 Microsoft Active Directory 사용자 및 그룹과는 관련이 없습니다. 관리자 액세스는 SVM 내부 설정을 변경하거나, 기존 SnapCenter 백업 환경에 SVM을 추가하거나, 기타 SVM 구성 또는 작업을 수행할 때 필요합니다.
다음 그림은 SVM의 세부 사항을 보여줍니다.
이제 SVM이 Microsoft Active Directory에 추가되었는지 확인하고 있습니다. 먼저 SVM 수준에서 확인해 보겠습니다.
그 후 Microsoft Active Directory에서 추가된 “Computer”를 확인하십시오.
Microsoft Active Directory는 SVM이 Microsoft Active Directory에 추가된 NetApp ONTAP 릴리스 세부 정보도 표시합니다.
볼륨 생성
SVM을 생성한 후에는 NFSv4.1 프로토콜을 사용하여 Linux 서버에 마운트할 수 있는 볼륨을 생성해야 합니다. 이 작업 또한 그래픽 인터페이스를 통해 수행합니다. 볼륨의 이름은 “smb.svm” SVM 내에서 “nfstest”이며 크기는 5GB입니다(테스트 목적에 충분한 크기입니다).
“default” 내보내기 정책을 사용하여 NFSv4.1로 볼륨에 대한 액세스를 구성합니다. 이렇게 하면 192.168.71.0/24 서브넷의 모든 컴퓨터에서 볼륨을 마운트할 수 있습니다. Windows 컴퓨터에서도 볼륨을 마운트하려면 CIFS 프로토콜을 통해 공유합니다. 이는 예를 들어 Linux와 Windows 시스템 간의 파일 교환에 유용할 수 있습니다. “Save”을 클릭하면 볼륨이 생성됩니다.
고급 SVM 설정
SVM과 볼륨이 생성된 후에도 SVM에서 몇 가지 사항을 추가로 구성해야 합니다.
- 일부 설정은 진단 모드에서만 가능하므로 바로 진단 모드로 이동하겠습니다.
testcl1::> set diag
Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y- NFSv4 도메인 ID 설정:
nfs modify -vserver smb-svm -v4-id-domain master.de - NFSv4.1 활성화:
nfs modify -vserver smb-svm -v4.1 enabled - NFSv4 숫자 ID를 비활성화하려면
`nfs modify -vserver smb-svm -v4-numeric-ids disabled` 명령을 사용하십시오. - SVM 서비스 내에 “root” 사용자를 생성합니다.
vserver unix-user modify -vserver smb-svm -user root -primary -gid 0
LDAP 설정 구성
이제 Microsoft Active Directory에서 NFSv4.1 프로토콜 컨텍스트를 사용하여 사용자 권한을 확인할 수 있도록 SVM에서 LDAP 클라이언트를 구성해야 합니다.
- vserver services name-service ldap client create -vserver smb-svm -client-config ad_test -ad-domain MASTER.DE -schema MS-AD-BIS
다음으로, 사용자와 그룹은 먼저 Microsoft Active Directory를 통해 확인한 다음 SVM에서 로컬로 확인하도록 지정합니다.
- vserver services name-service ns-switch modify -vserver smb-svm -database passwd -sources ldap,files
- vserver services name-service ns-switch modify -vserver smb-svm -database group -sources ldap,files
이제 클라이언트 구성을 생성하고 사용자 및 그룹에 대한 Unix <– –> Windows 및 Windows <– –> Unix 매핑을 생성합니다.
- vserver services name-service ldap create -vserver smb-svm -client-config ad_test
- vserver name-mapping create -vserver smb-svm -direction win-unix -position 1 -pattern MASTER\\(.+) -replacement \1
- vserver name-mapping create -vserver smb-svm -direction unix-win -position 2 -pattern (.+) -replacement MASTER\\\1
마지막으로, 다음 명령어를 실행하여 ONTAP 시스템의 Microsoft Active Directory에서 사용자 “tstadm”을 확인할 수 있는지 설정을 점검하고 검증하겠습니다.
- vserver services name-service ns-switch show -vserver smb-svm
Source
Vserver Database Order
————— ———— ———
smb-svm hosts files,
dns
smb-svm group files,ldap
smb-svm passwd files,ldap
smb-svm netgroup files
smb-svm namemap files
5 entries were displayed. - getxxbyyy getpwbyname -vserver smb-svm -username tstadm -node testcl1-01
(vserver services name-service getxxbyyy getpwbyname)
pw_name: tstadm
pw_passwd:
pw_uid: 1233
pw_gid: 233
pw_gecos: tstadm
pw_dir: /home/tstadm
pw_shell: /bin/csh
Linux 호스트 구성
저희 환경에서는 SUSE Linux SLES-15 SP6을 리눅스 시스템으로 사용합니다.
먼저 DNS 설정을 확인하고 LDAP 서비스 “MASTER.DE”가 DNS에서 올바르게 해석되는지 확인합니다.
다음으로, 필요한 종속 패키지를 포함하여 다음 RPM 패키지를 설치해야 합니다.
- realmd
- sssd
- sssd-ad
- sssd-tools
AD에 서버 추가
이제 다음 이미지와 같이 ” realm join master.de -v ” 명령어를 사용하여 Linux 서버를 Microsoft Active Directory에 추가합니다 (-v는 자세한 출력을 위한 옵션입니다).
다음 이미지와 같이 ” realm list ” 명령을 호출하여 서버를 Microsoft Active Directory에 추가하는 작업이 성공했는지 확인합니다.
그런 다음 /etc/nsswitch.conf 파일을 확인하여 사용자와 그룹이 Microsoft Active Directory의 SSSD를 통해 확인되어야 하는지 여부를 확인합니다.
/etc/nsswitch.conf 파일의 올바른 구성
이것이 마이크로소프트 액티브 디렉터리에서 리눅스 서버가 표시되는 방식입니다.
표시된 운영 체제는 “suse-linux-gnu”입니다.
Linux 호스트에서 SSSD를 구성합니다.
이제 리눅스 서버에서 SSSD 데몬을 구성해야 합니다.
SSSD는 System Security Services Daemon의 약자로, Linux/Unix 시스템을 Active Directory 또는 OpenLDAP과 같은 중앙 디렉터리 서비스에 연결하는 유틸리티입니다.
SUSE에서 기본 이름인 nscd 서비스 캐싱 데몬을 비롯한 다른 서비스 캐싱 데몬은 다음 이미지와 같이 중지하고 비활성화해야 합니다.
“nscd”의 자동 시작을 중지하고 비활성화합니다.
이제 etc/sssd/sssd.conf 파일을 수정해야 합니다. 도메인별 설정은 빨간색으로 강조 표시되어 있습니다.
[sssd] config_file_version = 2 services = nss, pam domains = master.de [nss] [pam] [domain/master.de] default_shell = /bin/bash krb5_store_password_if_offline = True cache_credentials = True krb5_realm = MASTER.DE realmd_tags = manages-system joined-with-adcli id_provider = ad fallback_homedir = /home/%u@%d ad_domain = master.de use_fully_qualified_names = False ldap_id_mapping = False ldap_schema = ad access_provider = ad enumerate = True
중요한:
- use_fully_qualified_names = False
- ldap_id_mapping = False
- cache_credentials = True
- enumerate = True
마지막으로 SSSD가 시작되고 시스템 시작 시 자동으로 시작되도록 구성됩니다.
구성의 정확성 확인
이 장에서는 우리가 이전에 설정했던 내용의 최종 결과를 보여드리겠습니다.
“tstadm” 사용자로 Linux 서버에 로그인하십시오.
다음 이미지는 사용자 “tstadm”이 서버 “saptest5″에 로그인하는 모습과 초기 로그인 시 홈 디렉터리가 생성되는 과정을 보여줍니다. ” id ” 명령어를 사용하여 Microsoft Active Directory에 구성된 사용자 및 그룹 ID를 확인합니다.
NFSv4.1을 사용하여 SVM에서 NFS 볼륨을 마운트합니다.
이제 ” showmount -e ” 명령어를 사용하여 SVM “smb-svm”에서 사용 가능한 NFS 볼륨을 표시해 보겠습니다 . 우리가 생성한 “nfstest” 볼륨도 확인할 수 있습니다. SVM의 IP 주소 대신 “SMB-TESTSERVER”라는 이름을 사용할 수도 있습니다.
다음으로, ” mount -o vers=4.1 192.168.71.35/nfstest /mnt ” 명령어를 사용하여 “nfstest” 볼륨을 NFSv4.1을 통해 /mnt 디렉터리에 마운트합니다.
기존 파일이 “tstadm” 사용자와 “sapsys” 그룹에 속하는지 확인합니다. 그런 다음 “root” 사용자 권한으로 “abc”라는 이름의 파일을 새로 생성하고, 숫자 UID와 GID를 사용하여 소유권을 “tstadm:sapsys”로 변경한 후 결과를 확인합니다.
모든 것이 예상대로 작동하고 있습니다. Linux 서버와 SVM에 대한 중앙 사용자 관리가 설정되었고, SAP 설치를 위한 준비도 완료되었습니다.
