관리자 기능
관리자 계정으로 로그인 하면 왼쪽 사이드바에 Administration 메뉴가 추가로 보입니다. Backend.AI 에 등록된 사용자 정보는 Users 탭에서 볼 수 있습니다. Domain admin 의 경우 도메인에 속한 사용자 정보만 확인할 수 있고, super admin 은 전체 사용자 정보를 조회할 수 있습니다. 사용자의 생성 및 비활성화는 super admin 만 할 수 있습니다.
사용자 ID(이메일), username, 메인 access key 는 컬럼 헤더의 검색창에 텍스트를 입력하여 조회 결과를 필터링할 수도 있습니다.
참고
플러그인 설정에 따라 이중 인증 사용(2FA Enabled) 열이 안보일 수 있습니다. 이 경우에는 시스템 관리자에게 문의 하십시오.
새로운 사용자 생성 및 정보 갱신
사용자는 CREATE USER 버튼을 클릭하여 생성할 수 있습니다. 이 때 비밀번호는 8 자 이상, 알파벳/특수문자/숫자를 1 개 이상 포함해야 합니다. E-Mail 과 Username 필드에는 최대 64 자까지 입력할 수 있습니다.
참고
이미 같은 이메일이나 사용자 이름을 가지는 사용자가 존재한다면 사용자를 생성할 수 없습니다. 다른 이메일과 사용자 이름을 사용해 보십시오.
사용자가 생성된 것을 확인합니다.
Controls 열에서 초록색 정보 버튼을 클릭하면 보다 자세한 사용자 정보를 확인할 수 있습니다. 사용자가 소속된 Domain과 Project 정보 또한 확인할 수 있습니다.
Controls 열의 톱니바퀴로 된 설정 아이콘을 클릭하면 이미 존재하는 사용자의 정보를 업데이트 할 수 있습니다. 사용자의 이름, 비밀번호, 활성/비활성 여부 등을 변경하여 저장할 수 있습니다. User ID는 변경되지 않습니다.
이 다이얼로그 하단의 세 항목은 각각 다음과 같은 기능을 합니다.
User Status: 사용자의 상태를 나타냅니다. 비활성(Inactive) 사용자는 로그인이 불가합니다. Before Verification 상태의 경우 해당 계정을 활성화 하기 위해 추가 단계가 남아있음을 의미합니다. 이는 사용자 이메일을 통한 검증 또는 관리자의 승인 절차 등이 될 수 있습니다. 비활성 사용자는 Inactive 탭에 별도로 보여지게 됩니다.
Require password change?: 관리자가 일괄적으로 사용자를 생성하면서 비밀번호를 임의 지정했을 경우, 이 필드를 On 으로 지정하여 구분할 수 있습니다. 비밀번호 변경이 필요하다는 일종의 기록 플래그로, 사용자 화면 상단에 비밀번호 변경을 안내하는 메시지가 출력되긴 하지만 실 사용에는 아무런 영향을 미치지 않습니다.
Enable sudo session: 사용자가 연산 세션에서 sudo 를 사용할 수 있도록 허용합니다. 이는 사용자가 패키지를 설치하거나 루트 권한이 필요한 명령을 실행할 때 유용합니다. 그러나 모든 사용자에게 이 옵션을 활성화 하는 것은 보안 문제를 일으킬 수 있기 때문에 권장되지 않습니다.
2FA Enabled: 사용자가 이중 인증을 사용하는지를 나타내는 플래그입니다. 이중 인증을 사용할 경우, 사용자는 로그인 시 OTP 코드를 추가로 입력해야 합니다. 관리자는 다른 사용자의 이중 인증 해제만 가능합니다.
사용자 계정 비활성화
사용자 계정을 삭제하는 기능은 사용량 통계 처리 및 메트릭 보존, 실수로 인한 계정 유실을 막기 위하여 만약을 위해 관리자라 할지라도 막혀 있습니다. 대신 사용자 계정을 비활성화 해서 사용자가 해당 계정을 통해 로그인 하는 것을 막을 수 있습니다. Controls 열의 휴지통 아이콘을 클릭합니다. 확인을 위한 다이얼로그가 뜨는데, OKAY 버튼을 클릭하면 사용자를 비활성화 할 수 있습니다.
사용자를 다시 활성화 하려면 Users - Inactive 탭에 방문하여 사용자 편집 버튼(톱니 아이콘)을 클릭한 후 사용자의 상태를 Active 로 변경하십시오.
경고
사용자 계정을 비활성화 하면 그 사용자의 모든 자격증명도 따라서 비활성 상태로 바뀌게 됩니다. 하지만, 사용자를 다시 활성화 해도 비활성 상태의 자격증명을 다시 활성화 하지는 않습니다. 사용자는 여러 개의 자격증명을 가질 수 있어 어떤 키페어를 활성화 할지 일관된 정책을 정하기 어렵기 때문입니다.
사용자의 키페어 관리
사용자 계정에는 보통 하나 이상의 키페어가 할당되어 있습니다. 키페어는 사용자 로그인 후 Backend.AI 서버로 요청을 보낼 때 인증을 위해 사용 됩니다. 로그인을 위해서는 사용자 이메일 및 비밀번호를 통한 인증이 필요하지만, 사용자가 서버로 보내는 매 요청은 키페어에 기반하여 인증하게 됩니다.
한 사용자가 여러 개의 키페어를 가질 수 있지만, 사용자의 키페어 관리 부담을 줄이기 위해 현재는 사용자의 키페어 중 하나만 사용하여 요청을 보내도록 하고 있습니다. 또한, 새 사용자를 생성하면 자동으로 키페어가 하나 만들어지므로, 사용자 생성 시 별도로 키페어를 생성하여 할당할 필요는 없습니다.
키페어는 Users 페이지의 Credentials 탭에서 조회할 수 있습니다. 현재 활성화된 키페어가 바로 출력이 되고, 비활성 키페어를 조회하려면 하단의 Inactive 패널을 클릭하면 됩니다.
Users 탭과 마찬가지로 Controls 열의 버튼을 이용해서 키페어의 상세 정보를 확인하거나 업데이트 할 수 있습니다. 파란색 휴지통 버튼을 클릭하면 해당 키페어를 비활성화 할 수 있고, 빨간색 휴지통 버튼을 클릭하면 키페어를 완전히 삭제할 수 있습니다. 단, 키페어를 사용해서 연산 세션을 생성한 적이 있으면 삭제할 수 없습니다. 만약, 실수로 키페어를 삭제한 경우 우측 상단의 ADD CREDENTIAL 버튼을 클릭하여 해당 사용자의 키페어를 다시 생성할 수 있습니다. 필요한 경우 Advanced 패널을 클릭해서 access key 와 secret key 를 직접 명시적으로 적어줄 수도 있습니다.
Rate Limit 필드는 15분 동안 Backend.AI 서버로 보내는 요청의 최대 수를 지정하는 곳입니다. 예를 들어 1000으로 설정한 경우, 해당 키페어로는 15분 동안 1000개 이상의 API 요청을 보내면 서버에서 에러를 발생하고 요청을 받아들이지 않습니다. 기본값을 사용하다가 사용자의 패턴에 따라 API 요청 빈도가 많을 경우 이 값을 증가시키는 것을 권장합니다.
프로젝트 Storage 폴더를 다른 사용자와 공유하기
Backend.AI 는 개인용 Storage 폴더 외에 프로젝트 전용 Storage 폴더를 제공합니다. 프로젝트 Storage 폴더는 특정 사용자가 아닌 특정 프로젝트에 속하는 폴더이며, 해당 프로젝트에 속한 모든 사용자가 접근할 수 있습니다.
참고
프로젝트 폴더는 오직 관리자만 생성할 수 있습니다. 일반 사용자는 관리자가 생성한 프로젝트 폴더 내용을 공유해서 접근할 수 있을 뿐입니다. 또한, 시스템 설정에 따라 프로젝트 폴더 생성이 허용되지 않는 경우도 있을 수 있습니다.
먼저 관리자 계정으로 로그인 한 뒤 프로젝트 폴더를 만들어보겠습니다. Data & Storage 페이지로 이동 후 NEW FOLDER 를 클릭하여 폴더 생성 다이얼로그를 엽니다. 폴더 이름을 입력하고 Type 을 Project 로 설정한 후 목표 Project 선택합니다. 이 때, 목표 프로젝트 사용자 B 가 속한 프로젝트로 설정합니다. Permission 은 Read-Only 로 설정하였습니다.
폴더가 생성된 것을 확인한 후 사용자 B 계정으로 로그인 하여 Data & Storage 페이지에 방금 생성한 프로젝트 폴더가 별도의 초대 절차 없이 조회되는 것을 확인합니다. Permission 열에는 역시 R(읽기전용)이 표시된 것을 확인할 수 있습니다.
자원 정책 관리
Backend.AI 에는 사용자 및 프로젝트 별로 총 사용 가능한 자원의 제한을 설정할 수 있습니다. 프로젝트 별 자원 제한은 엔터프라이즈 전용 관리자 GUI Control-Panel을 통해서만 가능하나, 사용자 별 (정확하게는 사용자의 키페어 별) 자원 제한은 사용자 Web-UI 에서도 설정할 수 있습니다.
자원 정책을 통해 키페어 별로 자원 사용 및 기타 세션 사용 관련 정책을 설정할 수 있습니다. 필요에 따라 사용자용/연구용 등 목적으로 여러 가지 자원 정책을 설정하여 키페어에 분리 적용할 수 있습니다.
참고
도메인과 프로젝트 수준에서 리소스 정책을 설정하려면, 관리자 전용 UI인 Control-Panel을 사용해야 합니다. Web-UI에서는 키페어 수준의 리소스 정책만 설정 가능합니다. Control-Panel은 엔터프라이즈 전용 서비스입니다.
자원 제한 상태를 확인하기 위해 관리자 계정으로 사용자 Web-UI 에 로그인 합니다. 관리자로 로그인 하면 좌측 메뉴 아래쪽에 관리자 전용 메뉴가 더 보입니다. 이 중 Users 를 클릭하여 사용자 관리 페이지로 이동한 뒤 Resource Policies 탭을 클릭합니다. 현재 설정되 어 있는 자원 정책의 리스트를 확인할 수 있습니다. 하단 그림에는 총세 개의 정책이 있습니다 (gardener, STUDENT, default). default 정책의 Resources 열을 보면 Cores, RAM, fGPU 등의 자원이 무한대 (∞) 로 표기된 것을 확인할 수 있습니다. 무한대 표시는 별도의 자원 제약이 이루어지지 않은 상태를 뜻합니다.
현재 이 가이드에서 사용 중인 사용자 계정은 default 자원 정책의 제한을 받고 있습니다. 좌 측의 Credentials 탭에서 확인할 수 있습니다. Resource Policy 를 보면 역시 모든 자원을 (하드웨어가 허락하는 한도 내에서) 무한대로 활용할 수 있음을 확인할 수 있습니다.
자원 정책 편집 화면에서 자원 정책 명을 제외한 모든 설정은 수정이 가능합니다. 이는 자원 정책 명이 자원 정책 리스트로 부터 각 자원 정책을 구분하는 고유 키이기 때문입니다. 수치로 입력할 수 있는 모든 부분들은 세션 생성/삭제 또는 vfolder 의 갯수에 사용되는 최대 값을 나타냅니다. CPU, RAM, fGPU 하단의 Unlimited 체크박스를 해제하고 원하는 값으로 자원 제약을 설정해봅니다. 이 때,제약하는 자원의 양이 하드웨어의 총 자원량 보다 작게 설정합니다. 여기서는 각각 2, 4, 1 로 설정을 했습니다. UPDATE 버튼을 클릭하여 자원 정책을 수정합니다.
자원 정책 창의 각 옵션에 대한 자세한 내용은 아래 설명을 참조하시기 바랍니다.
- 자원 정책
CPU : CPU 코어 최대 할당 가능량을 설정합니다. (최대 입력 값: 512)
RAM : GB 단위로 최대 할당 가능한 메모리 양을 설정합니다. 최대 할당 가능한 GPU 메모리 양의 두 배 이상으로 설정하는 것을 권장합니다. (최대 입력 값: 1024)
GPU : 할당 가능한 최대 물리 GPU 개수를 설정합니다. 서버에서 GPU 분할 가상화 기능이 켜져 있는 경우에는 (대부분의 엔터프라이즈 사이트에는 켜져 있습니다) 아무런 효과가 없습니다. (최대 입력 값: 64)
fGPU : Backend.AI 의 Fractional GPU (fGPU) 기능이 켜져 있으면, 물리 GPU 를 분할하여 여러 사용자 세션에 나눠어 배치하고 효율적으로 사용할 수 있습니다. 할당 가능한 최대 분할 GPU 양은 여기서 설정합니다. 만약 서버에 GPU 분할 가상화 기능이 꺼져 있다면 이 항목은 효과가 없습니다. (최대 입력 값: 256)
- 연산 세션
Container Per Session : 한 세션이 가질 수 있는 최대 컨테이너의 수. 사용자가 클러스터 세션을 생성할 수 있게 하라면, 이 값이 1보다 커야 합니다. (최대 입력 값: 100)
Idle timeout (sec.): 사용자가 세션에 영향을 주지 않고 비활성 상태일 수 있 는 최대 시간입니다. 유휴 제한 시간 동안 연산 세션에 아무런 활동이 감지되지 않으면, 해당 세션은 자동으로 삭제 됩니다. 활동을 측정하는 기준은 다양하며 관리자가 설정할 수 있습니다. (최대 입력 값: 15552000(초) (약 180 일))
Concurrent Jobs: 키페어를 통해 동시에 생성할 수 있는 최대 연산 세션의 개수입니다. 예를 들어, 이 값이 3 으로 지정되어 있을 경우, 이 정책에 영향을 받는 사용자는 동시에 3 개를 넘는 연산 세션을 생성할 수 없습니다. (최대 입력 값: 100)
Session Lifetime (sec.): 세션이 예약 시간 이후 활성 상태로 존재할 수 있는 최대 시간을 제한합니다. 이 때, 활성 상태는
PENDING및RUNNING상태를 포함합니다. 예약 후 설정된 시간이 지나면 세션은 지속적으로 사용중이라 할지라도 강제로 종료됩니다. 연산 세션이 무한히 실행되는 것을 방지하고자 할 때 유용하게 사용할 수 있습니다.
- 폴더
Allowed hosts : Backend.AI 는 여러 NFS 마운트포인트를 인식할 수 있 습니다. 이 항목을 통해 사용자가 접근할 수 있는 마운트 위치를 지정할 수 있 습니다. 예를 들어, “data-1” 이라는 NFS 가 Backend.AI 에서 인식되어 있는 상태일지라도, Allowed hosts 정책으로 허용되지 않은 경우 사용자는 해당 NFS 에 접근할 수 없습니다.
Capacity(GB) : 하나의 저장 폴더가 가질 수 있는 최대 파일 크기입니다. 이 항목은 FlashBlade 등과 같은 특별한 저장소나 파일시스템에서만 작동합니다.(최대 입력 값: 1024)
Max. #: 생성 또는 공유 초대 받을 수 있는 저장 폴더의 최대 개수입니다. (최대 입력 값: 50)
자원 정책 리스트에서 default 정책의 Resources 값이 업데이트 된 것을 확인합니다.
CREATE POLICY 버튼을 클릭하여 새로운 자원 정책을 생성할 수도 있습니다. 각 설정값의 위미는 상기 설명과 동일합니다.
자원 정책을 생성한 후 키페어에 연결하기 위해서는 Users 페이지의 Credentials 탭으로 가서 원하는 키페어의 Controls 열에 위치한 톱니바퀴 설정 버튼을 누른 후 Select Policy 필드를 클릭하여 선택하면 됩니다.
Control 열의 휴지통 아이콘을 눌러서 자원 정책을 삭제할 수도 있습니다. 아이콘을 클릭하면 삭제 확인 다이얼로그가 나타나게 됩니다. OKAY 버튼을 눌러서 삭제할 수 있습니다.
참고
비활성 사용자를 포함한 어떤 유저가 삭제할 자원 정책을 따르고 있다면, 삭제가 되지 않을 수 있습니다. 자원 정책을 삭제하기 위해서는 반드시 해당 자원 정책을 선택한 사용자가 남아 있지 않도록 하십시오.
참고
USERS, CREDENTIALS, RESOURCE POLICIES 탭의 우측 끝부분에 ⋯ 모양의 아이콘이 있습니다. 이 버튼을 클릭하면 export CSV 메뉴가 뜨고, 다시 이 메뉴를 클릭하면 각 탭 자원 별 CSV export 다이얼로그가 뜹니다. 필요한 경우 적당한 파일 이름을 쓰고 EXPORT CSV FILE 버튼을 클릭하면 사용자, 키페어, 자원 정책의 리스트를 CSV 형태로 다운로드 할 수 있습니다.
이미지 관리
세션 생성 시 사용할 이미지 관리는 Environments 페이지의 Images 탭에서 할 수 있습니다. 탭에 들어가면 현재 Backend.AI 서버에서 가지고 있는 모든 이미지의 메타 정보가 출력됩니다. 이미지 별로 속한 레지스트리, 네임스페이스, 이미지 이름, 이미지의 기반 OS, Digest, 요구되는 최소 자원 등의 정보를 확인할 수 있습니다. 관리되고 있는 agent 노드 중 하나 이상에 다운로드 되어 있는 이미지의 경우 installed 태그가 각 이미지의 Status 컬럼에 표시됩니다.
참고
특정 agent를 선택하여 이미지를 설치하는 기능은 현재 개발 중에 있습니다.
Controls 열의 설정 아이콘을 클릭하여 이미지의 최소 자원 요구량을 변경할 수 있습니다. 이미지마다 최소 동작을 위해 필요한 연산 자원 양 및 하드웨어가 있습니다. (예를 들어, GPU 전용 이미지의 경우 최소 할당 GPU가 있어야 합니다.) 최소 자원량의 기본값은 이미지의 메타데이터에 포함된 채로 제공됩니다. 각 이미지마다 지정 된 자원의 양보다 작은 자원으로 세션을 생성하려고 할 경우, 해당 요청은 자동으로 이미지 최소 자원 요구량으로 조정된 후 생성이 진행됩니다.
경고
미리 지정된 값보다 작은 양으로 최소 자원 요구량을 변경하지 마세요! 이미지 메타데이터에 포함된 최소 자원 요구량은 테스트를 거쳐 결정된 값입니다. 변경하려는 최소 자원량에 대하여 정말 잘 알고 있지 않은 경우 기본값으로 남겨두시기 바랍니다.
도커 레지스트리 관리
Environments의 Registries 탭을 클릭하여 현재 연결되어 있는 도커 레지스트리의 정보를 확인할 수 있습니다. cr.backend.ai 는 Harbor에서 서비스 하는 레지스트리로 기본적으로 등록되어 있습니다.
참고
오프라인 환경일 경우 기본 도커 레지스트리에 접근이 불가능하므로, 우측 휴지통 아이콘을 클릭하여 삭제하면 됩니다.
Controls에 있는 리프레시 아이콘을 클릭하여 해당 레지스트리에 저장된 Backend.AI 용 이미지 정보를 Backend.AI에 받아올 수 있습니다. 레지스트리에 저장된 이미지 중 Backend.AI 용으로 레이블 되지 않은 이미지 정보는 따로 받아오지 않습니다.
ADD REGISTRY 버튼을 클릭하여 운영하고 있는 사설 도커 레지스트리를 추가할 수 있습니다. 이 때, Registry Hostname과 Registry URL 주소는 동일하게 설정하여야 하고, Registry URL의 경우 http:// 또는 https:// 와 같은 scheme을 명시적으로 붙여 주어야 합니다. 또한, 해당 레지스트리에 저장되는 이미지는 반드시 Registry Hostname을 접두어로 한 이름을 가져야 합니다. Username과 Password는 선택 사항으로, 레지스트리에서 별도 인증 설정을 한 경우에는 채워주시면 됩니다.
Registry Hostname을 제외하고 이미 존재하는 레지스트리 정보를 수정할 수도 있습니다.
레지스트리를 생성하고 메타 정보를 업데이트 했다고 하더라도 사용자가 바로 해당 레지스트리에 있는 이미지를 사용할 수는 없습니다. Storage 폴더 사용을 위해 allowed hosts를 등록해야 했던 것처럼, 레지스트리 등록 후 도메인 또는 프로젝트 수준에서 allowed docker registries 필드에 해당 레지스트리를 등록해야 도메인 또는 프로젝트 소속 사용자가 레지스트리 이미지에 접근할 수 있습니다. Allowed docker registries 등록은 도메인과 프로젝트 관리 기능이 있는 Control-Panel을 이용해서 할 수 있습니다. 키페어의 자원 정책에서 allowed docker registries를 설정하는 기능은 아직 제공하지 않고 있습니다.
자원 프리셋 설정
연산 세션을 생성할 때 Resource allocation 패널에서 다음과 같은 사전 정의된 자원 프리셋이 출력 됩니다. Super admin에게는 이 자원 프리셋을 설정할 수 있는 기능을 제공합니다.
Environment 페이지의 Resource Presets 탭으로 이동합니다. 현재 정의되어 있는 자원 프리셋의 리스트를 확인할 수 있습니다.
Controls 열의 설정 아이콘(톱니바퀴 모양)을 클릭하여 자원 프리셋이 제공할 CPU, RAM, fGPU 등의 자원을 설정할 수 있습니다. 아래 예제의 경우 Backend.AI 서버의 GPU 제공 모드가 shares이므로 GPU 필드는 비활성화 되어 있습니다. 원하는 값으로 자원을 설정한 후 저장하고 연산 세션 생성 시 해당 프리셋이 출력되는지 확인해 봅니다. 프리셋에 정의된 자원량보다 적은 자원만 할당 가능한 경우에는 해당 프리셋이 출력되지 않습니다.
또한 Resource Presets 탭의 우측 상단의 CREATE PRESETS 버튼을 클릭하여 자원 프리셋을 생성 할 수도 있습니다. 이미 존재하는 자원 프리셋 이름으로는 생성이 불가능한데, 이는 프리셋 이름이 각 자원 프리셋을 구분하는 키 값이기 때문입니다.
Agent 노드 관리
Superadmin의 경우 Resources 페이지의 Connected 탭에서는 현재 Backend.AI에 연결된 agent 워커 노드를 조회할 수 있습니다. 노드의 IP와 연결된 시간, 현재 사용중인 실제 자원 등을 조회할 수 있습니다. Web-UI 앱에서는 별도로 agent 노드를 조작하는 기능은 제공하지 않습니다.
Agent 노드 조회
또한 agent 워커 노드의 자원에 대한 정확한 사용량을 Control 패널의 노트 아이콘을 클릭하여확인할 수 있습니다.
Terminated 탭으로 이동하면 한 번 연결되었다가 종료되거나 연결이 끊긴 에이전트의 정보를 확인할 수 있습니다. 노드 관리에 참고 자료로 활용할 수 있습니다.
Agent 노드의 스케줄링 가능 상태 설정하기
특정 Agent 서비스를 중단하지 않고 신규 세션이 스케줄링되는 것을 막고 싶을 수 있습니다. 이 경우, Agent의 Schedulable 상태를 비활성화할 수 있습니다. 기존에 해당 Agent에서 실행 중이던 연산 세션은 그대로 보존하면서 신규 세션 생성만 차단할 수 있습니다.
자원 그룹 관리
Agent는 자원 그룹이라는 단위로 묶일 수 있습니다. 예를 들어, V100 GPU를 탑재한 agent가 3대, P100 GPU를 탑재한 agent가 2대 있는데, 사용자에게 두 GPU 자원을 별도로 노출하고 싶을 경우 V100 agent 3대를 하나의 자원 그룹으로 묶고, 나머지 P100 agent 2대를 다른 자원 그룹으로 묶어서 관리할 수 있습니다.
자원 그룹에 특정 agent를 추가하는 작업은 현재 UI 상에서 처리되지 않으며, agent 설치 폴더의 설정 파일 옵션을 수정한 뒤 agent를 재시작 하는 방식으로 가능합니다. 자원 그룹은 Resources 페이지의 Resource Group 탭에서 조회할 수 있습니다.
Control 열에서 설정 아이콘을 클릭하여 자원 그룹을 편집할 수 있습니다. Select scheduler 필드에서 연산 세션 생성 스케줄링 방식을 선택할 수 있는데, 현재 지원하는 방식은 FIFO, LIFO, DRF 세 가지 입니다. FIFO 와 LIFO 는 가장 처음 또는 가장 마지막에 작업 큐에 들어 온 연산 세션을 먼저 생성하는 방식으로 스케줄링 방식이고, DRF 는 Dominant Resource Fairness 의 약자로 사용자 별로 최대한 공평하게 자원 할당이 가능하도록 조절하여 스케줄링 하는 방식입니다. Active Status 를 꺼서 해당 자원 정책을 비활성화 할 수 있습니다.
WSProxy Server Address에는 리소스 그룹에 속한 Agent 에서 사용할 WSProxy 서비스 주소를 설정할 수 있습니다. 이 필드에 URL 을 설정하면 WSProxy 에서 Jupyter 등의 앱 트래픽을 중계할 때 Manager 를 거치지 않고 Agent 를 통해 바로 사용자의 컨테이너에 접속하게 됩니다(v2 API). v2 API 를 사용하는 경우, 앱 서비스 사용 시 Manager 의 부하를 줄일 수 있습니다. 서비스를 배포할 때 효율성과 확장성도 증가합니다. 다만, WSProxy 에서 Agent 가 설치된 노드로 직접적인 네트워크 연결이 불가능한 경우에는, 이 필드를 빈 값으로 설정하여 Manager 를 거쳐 컨테이너로 트래픽을 중계하는 v1 API 를 사용할 수 있습니다.
리소스 그룹에서 스케줄러 관련 옵션(Scheduler Options)을 추가 설정할 수도 있습니다. 각 항목은 다음 의미를 가집니다.
Allowed session types: 사용자가 세션 타입을 설정할 수 있기 때문에, 자원 그룹에서도 특정 타입의 세션만 허용할 수 있습니다. 하나 이상의 세션 타입을 허용해야 합니다. 허용되는 세션 타입은 Interactive, Batch, Inference 입니다.
Pending timeout: PENDING 상태에 머무는 시간이 Pending timeout 보다 긴 경우, 해당 세션을 취소합니다. 무한히 PENDING 상태에 머무르는 세션을 방지하고자 할 때 기준 시간을 설정합니다. 0을 설정하면 Pending timeout을 적용하지 않습니다.
The number of retries to skip pending session: PENDING 세션을 건너뛸 때까지의 스케줄러 재시도 횟수입니다. 한 PENDING 세션이 그 뒤에 요 청된 세션의 스케줄링을 무한히 막는 경우(Head-of-line blocking, HOL)를 방지하 기 위해 설정할 수 있습니다. 따로 설정하지 않는 경우에는 Etcd 에 설정된 글로벌 값 (num_retries_to_skip, 기본 3 회)을 사용하게 됩니다.
CREATE 버튼을 클릭하여 새로운 자원 정책을 생성할 수 있습니다.다른 생성하기 기능과 마찬가지로, 자원 정책 이름은 키 값이기 때문에, 이미 존재하는 자원 정책 이름과 동일한 이름을 갖는 자원 정책 생성은 불가능합니다.
저장소
STORAGES 탭에서는 시스템에 마운트 된 볼륨을 조회할 수 있습니다. 주로 NFS라고 생각하시면 됩니다. 23.03 버전부터는 쿼타 관리를 지원하는 스토리지에 대해 사용자별/프로젝트별 쿼타 설정이 가능합니다. 이 기능을 사용함으로써, 관리자는 좀 더 손쉽게 사용자와 프로젝트용 폴더가 스토리지 내에서 얼마만큼 공간을 차지하고 있는지 확인하고 관리할 수 있습니다.
쿼타를 설정하기 위해서는, 자원 페이지의 저장소(스토리지) 탭에 먼저 접근해야 합니다. 그리고, 컨트롤 컬럼의 톱니바퀴 아이콘을 클릭합니다.
참고
쿼타 설정은 해당 기능을 제공하는 저장소 (예: XFS, CephFS, NetApp, Purestorage, 등)에 한해서만 가능합니다. 저장소의 쿼타 설정 기능 제공 여부에 관계없이, 쿼타 설정 페이지는 제공하나, 내부적으로 쿼타 설정을 지원하지 않는 저장소에 대해서는 쿼타 설정할 수 없습니다.
쿼타 설정 패널
쿼타 설정 페이지에는 각 패널의 제목에 대응하는 두 개의 패널이 있습니다.
- 스토리지 정보 패널
사용량: 선택된 저장소에서의 실제 사용량
엔드포인트: 선택된 저장소가 스토리지 노드에 마운트된 경로
백엔드 타입: 저장소의 타입
지원 기능: 선택된 저장소에서 지원하는 기능
- 시스템 설정 조회
사용자 대상: 사용자별로 쿼타를 설정합니다.
프로젝트 대상: 프로젝트별로 쿼타(프로젝트-폴더) 를 설정합니다.
ID: 사용자나 프로젝트 ID에 대응합니다.
Hard Limit (GB): 선택된 쿼타에서 현재 설정된 Hard Limit 쿼타를 표시합니다.
설정: Hard limit 과 같은 설정값을 수정하거나, 쿼타 설정값을 삭제하는 기능을 제공합니다.
사용자 쿼타 설정하기
Backend.AI에서는 사용자와 프로젝트 관리자에 의해 생성되는 두 가지 타입의 폴더가 있습니다. 이 섹션에서는, 사용자별로 현재 쿼타 설정값을 확인하고, 어떻게 값을 설정하는지 다룹니다. 우선, 쿼타 설정 패널의 활성화된 탭이 For User 인지 확인해주세요. 그 다음, 쿼타를 수정하고 확인할 대상인 사용자를 선택해주세요. 만일 쿼타가 이미 설정되어 있다면, 사용자 ID와 동일한 쿼타 ID 값이 테이블에 표시된 것을 확인하실 수 있습니다.
물론, 쿼타를 수정하려고 할 경우, 컨트롤 컬럼의 수정 버튼을 선택하기만 하면 됩니다. Edit 버튼을 클릭하고 나면, 쿼타를 설정하는 작은 모달 창이 뜬 것을 확인하실 수 있습니다. 설정할 값을 정확히 입력 후, 반드시 OK 버튼을 클릭해주세요. 그렇지 않으면 변경 내용은 반영되지 않습니다.
프로젝트 쿼타 설정하기
프로젝트 폴더에 대해 쿼타를 설정하는 것은 사용자 쿼타 설정과 유사합니다. 프로젝트별로 적용되는 쿼타와 사용자별로 적용되는 쿼타의 차이점은, 프로젝트별로 적용되는 쿼타에서는 프로젝트가 소속되어 있는 도메인을 우선 선택하는 과정이 추가되었다는 것입니다. 그 이후 과정은 동일합니다. 하단 그림에서 볼 수 있듯이, 우선 도메인을 선택하고, 적용할 프로젝트를 선택하면 됩니다.
쿼타 해제하기
쿼타를 해제하는 기능도 제공합니다. 쿼타 설정값을 삭제한 뒤에는, 해당 프로젝트/사용자에 적용된 쿼타는 사용자 또는 프로젝트에서 기본적으로 적용된 쿼타를 따라가게 됩니다. 이 값은 WebUI에서 따로 설정하는 사용자 인터페이스를 지원하지 않습니다. 기본 쿼타 설정값을 변경하려면, 관리자 전용 페이지에 접근해서 해당 값을 변경해야 합니다. 컨트롤 컬럼에 있는 Unset 버튼을 클릭하면, 작은 스낵바 메시지 창이 뜨고, 현재 쿼타 세팅을 정말로 삭제할 것인지 확인하게 됩니다. 여기서 OK 버튼을 클릭하게 되면, 쿼타 설정값이 삭제되고, 자동으로 쿼타 설정값은 쿼타의 타입(사용자 / 프로젝트)에 대응하는 값으로 적용되게 됩니다.
참고
만일 사용자 별/프로젝트 별 설정값이 없을 경우, 사용자/프로젝트 별 자원 정책 내 대응하는 값들이 기본 값으로 설정되게 됩니다. 예를 들어 쿼타에서 hard limit 값이 설정되어 있지 않다면, 자원 정책 내 max_vfolder_size 값이 기본 값으로 쓰이게 됩니다.
세션 자원 다운로드
세션 페이지에는 관리자를 위한 추가 기능이 있습니다. FINISHED 탭 우측을 보면 … 으로 표시된 메뉴가 있습니다. 이 메뉴를 클릭하면 export CSV 라는 하위 메뉴가 나옵니다.
이 메뉴를 클릭하면 현재까지 생성된 연산 세션의 정보를 CSV 형태로 다운로드 받을 수 있습니 다. 다음과 같은 다이얼로그가 열린 후, (필요한 경우) 적당한 파일 이름을 입력하고 EXPORT 버튼을 클릭하십시오. 파일 이름은 최대 255 자까지만 입력 가능한 점에 유의하십시오. 곧 CSV 파일 하나가 다운로드 될 것입니다.
시스템 설정 조회
Configuration 페이지에서 Backend.AI에 설정된 주요 설정값을 조회할 수 있습니다. 현재는 몇가지 변경 기능 및 설정 조회 기능을 제공하고 있습니다.
자동 설치 및 업데이트 규칙을 Digest, Tag, None 중에서 선택할 수 있습니다. Digest 는 이미지에 대한 checksum 과 같은 것으로, image의 무결성을 검증하고, 중복된 레이어를 재사용함으로써 이미지 다운로드의 효율성을 높이는데에 사용됩니다. Tag 는 개발용 옵션에만 사용할 수 있는데, 태그는 이미지의 무결성을 보장하지 않기 때문입니다.
경고
각 규칙에 대해 완전히 이해하고 있지 않는 한 선택된 규칙을 변경하지 마십시오.
스케일링과 플러그인에 대한 설정도 변경할 수 있습니다.
사용자가 멀티 노드 클러스터 세션(Backend.AI 20.09부터 지원)을 생성할 경우, Backend.AI는 노드간 사설 통신을 지원하기 위해 동적으로 오버레이 네트워크(overlay network)를 생성합니다. 이 오버레이 네트워크에서 사용하는 Maximum Transmission Unit (MTU) 값을 설정할 수 있습니다. 다만, 이 값이 네트워크 성능을 향상시키는 것이 확실할 때만 설정하십시오.
더 보기
Backend.AI 클러스터 세션에 대해 더 자세한 정보를 확인하시려면, Backend.AI 클러스터 연산 세션 섹션을 참고하십시오.
Scheduler의 설정(CONFIG) 버튼을 누르면 스케줄러 별 설정을 할 수 있습니다. 스케줄러 별 설정값은 자원 그룹 의 스케줄러 설정값이 없을 때 사용하는 기본 값을 의미합니다. 자원 그룹에 설정한 값이 있을 경우, 이 값은 무시됩니다.
현재 지원하는 스케줄링 방법에는 FIFO, LIFO, DRF 가 있습니다. 각 스케줄링 방법은 위의 스케줄링 방법 과 동일합니다. 스케줄러 옵션에는 세션 재시도 횟수가 있습니다. 세션 재시도 횟수란 세션 생성이 실패한 경우 세션 생성을 재시도 하는 횟수를 말합니다. 만약 지정한 횟수 안에 세션 생성을 하지 못하는 경우 해당 요청을 무시하고 다음 요청을 처리합니다. 현재는 스케줄러가 FIFO일 때만 가능합니다.
참고
향후 CLI에서 지원하는 다양한 설정 변경 기능을 GUI에도 계속 추가할 예정입니다.
참고
시스템 설정값은 기본 설정입니다. 자원 그룹에서 특정 값이 설정된 경우, 시스템 설정값이 아닌 자원 그룹 설정값을 적용합니다.
서버 관리 메뉴
Maintenance 페이지로 이동하면 서버를 관리할 수 있는 몇 가지 버튼을 볼 수 있습니다.
RECALCULATE USAGE: 간혹 네트워크 접속이나 도커 데몬의 컨테이너 관리 문제로 컨테이너가 실제로 사용하고 있는 자원과 Backend.AI에서 출력되는 자원 점유량이 일치하지 않는 경우가 있을 수 있습니다. 그 때 RECALCULATE USAGE 버튼을 클릭하면 자원 점유량을 수동 보정할 수 있습니다.
RESCAN IMAGES: 등록된 모든 도커 레지스트리에서 이미지 메타 정보를 받고 업데이트 합니다. Backend.AI에서 사용 가능한 이미지를 레지스트리에 새로 등록한 경우 사용할 수 있습니다.
참고
사용하지 않는 이미지를 제거하거나, 주기적 관리 일정 등록 등 기타 관리에 필요한 설정이 계속 추가될 예정입니다.
상세 정보
Information 페이지에서는 여러가지 자세한 정보와 각 기능의 상태를 볼 수 있습니다. 매니저 버전과 API 버전을 보려면 Core 패널을 확인하십시오. Backend.AI를 구성하는 각 컴포넌트의 호환 가능 여부를 보려면 Component 패널을 확인하십시오.
참고
이 페이지는 현재 정보를 보여주기 위한 것입니다.
