관리자 기능

관리자 계정으로 로그인 하면 왼쪽 사이드바에 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 요청 빈도가 많을 경우 이 값을 증가시키는 것을 권장됨.

참고

USERS, CREDENTIALS 탭의 우측 끝부분에 ⋯ 모양의 아이콘이 있습니다. 이 버튼을 클릭하면 export CSV 메뉴가 나타나고, 다시 해당 메뉴를 클릭하면 각 탭 자원 별 CSV export 다이얼로그가 나타납니다. 필요한 경우 적당한 파일 이름을 기입하고, EXPORT CSV FILE 버튼을 클릭하면 사용자, 키페어 리스트를 CSV 형태로 다운로드 할 수 있습니다.

프로젝트 Storage 폴더를 다른 사용자와 공유하기

Backend.AI 는 개인용 Storage 폴더 외에 프로젝트 전용 Storage 폴더를 제공합니다. 프로젝트 Storage 폴더는 특정 사용자가 아닌 특정 프로젝트에 속하는 폴더이며, 해당 프로젝트에 속한 모든 사용자가 접근할 수 있습니다.

참고

프로젝트 폴더는 오직 관리자만 생성할 수 있습니다. 일반 사용자는 관리자가 생성한 프로젝트 폴더 내용을 공유받아 접근할 수 있을 뿐입니다. 단, 시스템 설정에 따라 프로젝트 폴더 생성이 허용되지 않는 경우도 있을 수 있습니다.

먼저 관리자 계정으로 로그인 한 뒤 프로젝트 폴더를 만들어보겠습니다. Data & Storage 페이지로 이동 후 NEW FOLDER 를 클릭하여 폴더 생성 다이얼로그를 엽니다. 폴더 이름을 입력하고 Type 을 Project 로 설정한 후 목표 Project를 선택합니다. 이 때, 목표 프로젝트는 사용자 B 가 속한 프로젝트로 설정합니다. Permission 은 Read-Only 로 설정했습니다.

폴더가 생성된 것을 확인한 후 사용자 B 계정으로 로그인 하여 Data & Storage 페이지에 방금 생성한 프로젝트 폴더가 별도의 초대 절차 없이 조회되는 것을 확인합니다. Permission 열에 R(읽기전용) 표시가 나타난 것을 확인할 수 있습니다.

모델 카드 관리

모델 스토어에 있는 모든 모델 카드는 프로젝트 관리자에 의해 관리됩니다. 모델 스토어에 모델 정의 파일과 함께 모델 폴더를 업로드하면, 프로젝트에 있는 그 어떤 사용자도 모델 카드에 접근할 수 있고 필요하다면 복제할 수도 있습니다.

Hugging Face 에 있는 모델을 모델 카드로 추가해봅시다.

참고

모델 카드를 만들기 전에 Hugging Face에서 복제하고자 하는 모델에 대한 접근 권한을 얻어야 합니다. 더 자세한 내용은 Gated models 를 참고하시기 바랍니다.

'model-store' 로 프로젝트를 변경합니다.

오른쪽의 'Add' 버튼 을 클릭합니다. 폴더명을 입력하고, 나머지 폴더 설정값을 다음과 같이 설정합니다.

• Type: project

• Project: 'model-store'

• Usage Mode: Model

• Permission: Read-Write

• Cloneable: True

폴더 생성이 끝나면, model-definition.yaml 파일을 만들고, 방금 생성한 폴더에 업로드해야 합니다. 여기 모델 정의 파일 예시가 있습니다. 모델 정의 파일 작성법이 궁금하시다면, 모델 정의 파일 형식 을 참고하시기 바랍니다.

models:
- metadata:
   architecture: LlamaForCausalLM
   author: meta-llama
   category: huggingface
   created_at: '2024-04-17 09:35:12'
   description: Meta's Llama 3 by AI@Meta are dialogue-optimized, safe large language
      models in 8B and 70B sizes.
   framework:
   - transformers
   label:
   - facebook
   - meta
   - pytorch
   - llama
   - llama-3
   license: llama3
   min_resource:
      cuda.shares: 2.4305981636047362
   modified_at: '2024-05-29 12:27:16'
   task: text-generation
   title: meta-llama/Meta-Llama-3-8B-Instruct
model_path: /models
name: Meta-Llama-3-8B-Instruct

model-definition 파일 업로드가 끝나면, 모델 스토어 영역에 모델 카드가 추가된 것을 확인할 수 있습니다.

참고

모델 정의 파일 작업이 완료된 뒤, 모델 폴더에 모델을 직접 다운로드해야 합니다. 모델 파일을 폴더에 다운로드 하기 위해서는, 모델 폴더를 세션 생성시 마운트 한 뒤, Downloading models 를 참고하여 파일을 다운로드 받을 수 있습니다.

방금 생성한 모델 카드를 클릭하면 방금 업로드한 모델 정의 파일의 상세 정보를 확인할 수 있습니다. 이제 프로젝트 구성원 모두가 모델 카드에 접근 및 복제할 수 있게 되었습니다.

자원 정책 관리

키페어 자원 정책

Backend.AI에서 관리자는 각 키페어, 사용자 및 프로젝트에 대해 사용 가능한 자원의 총량에 대한 제한을 설정할 수 있습니다. 자원 정책을 사용하면 최대 허용 자원 및 기타 계산 세션 관련 설정을 정의할 수 있습니다. 필요한 경우 사용자 또는 연구 목적과 같이 여러 자원 정책을 만들고 개별적으로 적용할 수 있습니다.

자원 정책 페이지에서 관리자는 현재 등록된 자원 정책 목록을 확인할 수 있습니다. 자원 정책 페이지에서는 키페어, 사용자 및 프로젝트에 설정된 자원 정책 목록을 확인할 수 있습니다. 먼저 키페어에 대한 자원 정책을 살펴봅시다. 아래 그림에서는 총 세 가지 정책 (gardener, student, default)이 있습니다. 무한대 기호 (∞)는 해당 리소스에 제한이 없음을 나타냅니다.

이 가이드에서 사용 중인 사용자 계정은 현재 default 자원 정책에 할당되어 있습니다. 이 정보는 사용자 페이지의 자격 증명 탭에서 확인할 수 있습니다. 자원 정책 패널에서는 모든 자원이 하드웨어 한도까지 사용 가능함을 확인할 수 있습니다 (∞).

자원 정책을 수정하려면 기본 정책 그룹의 제어 열에 있는 '설정' 버튼을 클릭합니다. 자원 정책 업데이트 다이얼로그에서 정책 이름을 제외한 모든 옵션을 편집할 수 있으며, 이는 목록에서 자원 정책을 구별하는 주요 키 역할을 합니다. 여기에서는 CPU, RAM 및 fGPU 하단의 무제한 확인란을 해제하고 원하는 값으로 리소스 제한을 설정하겠습니다. 할당된 리소스는 총 하드웨어 용량보다 작아야 합니다. 이 경우 CPU, RAM 및 fGPU를 각각 2, 4, 1로 설정하겠습니다. 업데이트된 자원 정책을 적용하려면 OK 버튼을 클릭합니다.

자원 정책 창의 각 옵션에 대한 자세한 내용은 아래 설명을 참조하세요.

• 자원 정책

  • CPU : CPU 코어 최대 할당 가능량 설정. (최대 입력 값: 512)

  • Memory : GB 단위로 최대 할당 가능한 메모리 양 설정. 최대 할당 가능한 GPU 메모리 양의 두 배 이상으로 설정하는 것이 권장됨. (최대 입력 값: 1024)

  • CUDA-capable GPU : 할당 가능한 최대 물리 GPU 개수 설정. 서버에서 GPU 분할 가상화 기능이 켜져 있는 경우에는 적용되지 않음. (최대 입력 값: 64) * 대부분의 엔터프라이즈 사이트에는 GPU 분할 가상화 기능이 켜져 있음.

  • CUDA-capable GPU (fractional) : Backend.AI 의 Fractional GPU (fGPU) 기능이 켜져 있으면, 물리 GPU 를 분할하여 여러 사용자 세션에 나눠어 배치하고 효율적으로 사용할 수 있음. 할당 가능한 최대 분할 GPU 양은 여기서 설정합니다. 만약 서버에 GPU 분할 가상화 기능이 꺼져 있다면, 이 항목은 적용되지 않습니다. (최대 입력 값: 256)

• 연산 세션

  • Container Per Session : 한 세션이 가질 수 있는 최대 컨테이너의 수. 사용자가 클러스터 세션을 생성할 수 있게 하려면, 이 값이 1보다 커야 함. (최대 입력 값: 100)

  • Session Lifetime (sec.): 세션이 예약 시간 이후 활성 상태로 존재할 수 있는 최대 시간. 활성 상태는 PENDING 및 RUNNING 상태를 포함함. 예약 후 설정된 시간이 지나면 세션이 사용중이라 할지라도 강제로 종료됨. 사용중이라 할지라도 강제로 종료됩니다. 연산 세션이 무한히 실행되는 것을 방지할 때 유용한 옵션.

  • Concurrent Jobs: 키페어를 통해 동시에 생성할 수 있는 최대 연산 세션의 개수입니다. 예를 들어, 이 값이 3 으로 지정되어 있을 경우, 해당 정책에 영향을 받는 사용자는 동시에 3개가 넘는 연산 세션을 생성할 수 없음. (최대 입력 값: 100)

  • Idle timeout (sec.): 사용자가 세션에 영향을 주지 않고 비활성 상태일 수 있는 최대 시간. 유휴 제한 시간 동안 연산 세션에 활동이 감지되지 않으면, 해당 세션이 자동으로 삭제됨. 활동을 측정하는 기준은 다양하며, 관리자가 설정할 수 있음. (최대 입력 값: 15552000(초) (약 180 일))

• 폴더

  • Allowed hosts : Backend.AI 는 여러 NFS 마운트포인트를 인식할 수 있음. 이 항목을 통해 사용자가 접근할 수 있는 마운트 위치를 지정할 수 있음. 예를 들어, “data-1” 이라는 NFS 가 Backend.AI 에서 인식되어 있는 상태일지라도, Allowed hosts 정책으로 허용되지 않은 경우 사용자는 해당 NFS 에 접근할 수 없음.

  • (23.09.4 이후로 사용 중단) Max. #: 생성 또는 공유 초대 받을 수 있는 저장 폴더의 최대 개수. (최대 입력 값: 50)

키페어 자원 정책 리스트에서 default 정책의 Resources 값이 업데이트 된 것을 확인합니다.

Create 버튼을 클릭하여 새로운 자원 정책을 생성할 수 있습니다. 각 설정값의 의미는 상기한 설명과 동일합니다.

키페어 자원 정책을 생성한 후 키페어에 연결하기 위해서는 Users 페이지의 Credentials 탭으로 가서 원하는 키페어의 Controls 열에 위치한 '설정' 버튼을 누른 후, Select Policy 필드를 클릭하여 선택합니다.

Control 열의 '휴지통' 아이콘을 클릭하여 각 리소스 키페어를 삭제할 수 있습니다. 아이콘을 클릭하면 확인 팝업이 나타납니다. 삭제하려면 'Delete' 버튼을 클릭하세요.

참고

비활성 사용자를 포함한 어떤 유저가 삭제할 자원 정책을 따르고 있다면, 삭제가 되지 않을 수 있습니다. 자원 정책을 삭제하기 위해서는 반드시 해당 자원 정책을 선택한 사용자가 남아 있지 않아야 합니다.

특정 열을 숨기거나 보고 싶다면 테이블 우측 하단의 '설정' 버튼을 클릭합니다. 이후에는 아래에 다이얼로그가 표시되어 보고 싶은 열을 선택할 수 있습니다.

사용자 자원 정책

24.03 버전부터 Backend.AI는 사용자 자원 정책 관리를 지원합니다. 각 사용자는 여러 키페어를 가질 수 있지만 사용자 당 사용자 자원 정책은 하나만 가질 수 있습니다. 사용자 자원 정책 페이지에서는 Max Folder Count 및 Max Folder Size와 같은 폴더 관련 다양한 설정을 제한 할 수 있으며, Max Session Count Per Model Session 및 Max Customized Image Count와 같은 개별 리소스를 제한 할 수 있습니다.

테이블 오른쪽 위에 있는 Create 버튼을 클릭하여 새로운 사용자 자원 정책을 생성할 수 있습니다.

• Name: 사용자 자원 정책의 이름.

• Max Folder Count: 사용자가 생성할 수 있는 최대 폴더 수. 사용자의 폴더 수가 해당 값을 초과하면 새 폴더를 생성할 수 없게 되며, 무제한으로 설정된 경우에는 “∞“로 표시됨.

• Max Folder Size: 사용자의 저장 공간의 최대 크기. 사용자의 저장 공간이 해당 값을 초과하면 사용자는 새 데이터 폴더를 만들 수 없게 되며, 무제한으로 설정된 경우에는 “∞“로 표시됨.

• Max Session Count Per Model Session: 각 사용자가 생성한 모델 서비스 당 사용 가능한 세션의 최대 수. 해당 값을 증가시키면 세션 스케줄러에 부하가 가해질 수 있고, 잠재적인 시스템 다운타임으로 이어질 수 있습니다. 따라서, 이 설정을 조정할 때는 주의가 필요합니다.

• Max Customized Image Count: 사용자가 생성할 수 있는 최대 사용자 정의 이미지 개수. 사용자의 사용자 정의 이미지 수가 이 값을 초과하면, 사용자는 새로운 사용자 정의 이미지를 만들 수 없음. 사용자 정의 이미지에 대해 더 알고 싶다면, 나의 실행 환경 섹션을 참조 할 수 있음.

• ID: 사용자 자원 정책의 ID.

• Created At: 사용자 자원 정책이 생성된 날짜와 시간.

Control 열의 '설정' 버튼을 클릭합니다. 삭제하려면 '휴지통' 버튼을 클릭하세요.

참고

자원 정책을 변경하면 해당 사용자 자원 정책을 사용하는 모든 사용자에게 영향을 줄 수 있습니다. 자원 정책을 변경할 때는 사용자의 주의가 필요합니다.

키페어 자원 정책과 마찬가지로, 원하는 열만 선택하여 표시하려면 테이블 오른쪽 하단의 '설정' 버튼을 클릭하세요.

프로젝트 자원 정책

24.03 버전부터 Backend.AI는 프로젝트 자원 정책 관리를 지원합니다. 프로젝트 자원 정책은 프로젝트의 저장 공간(할당량) 및 폴더 관련 제한 사항을 관리합니다.

Resource Policy 페이지의 'Project' 탭을 클릭하면 프로젝트 자원 정책 목록을 볼 수 있습니다.

테이블 오른쪽 위에 있는 'Create' 버튼을 클릭하여 새로운 프로젝트 자원 정책을 생성할 수 있습니다.

• Name: 프로젝트 자원 정책의 이름.

• Max Folder Count: 관리자가 생성할 수 있는 프로젝트 폴더의 최대 개수. 프로젝트 폴더 수가 해당 값을 초과하면 관리자가 새 프로젝트 폴더를 생성할 수 없게 되며, 무제한으로 설정된 경우에는 “∞“로 표시됨.

• Max Folder Size: 프로젝트의 저장 공간의 최대 크기. 프로젝트의 저장 공간이 이 값을 초과하면 관리자가 새 프로젝트 폴더를 생성할 수 없게 되며, 무제한으로 설정된 경우에는 “∞“로 표시됨.

각 필드의 의미는 사용자 자원 정책과 유사합니다. 차이점은 프로젝트 자원 정책이 프로젝트 폴더에 적용되는 반면 사용자 자원 정책은 사용자 폴더에 적용된다는 것입니다.

변경을 원하면 제어 열의 '설정' 버튼을 클릭하세요. 자원 정책 이름은 편집할 수 없습니다. 삭제는 '휴지통' 버튼을 클릭하여 수행할 수 있습니다.

참고

자원 정책을 변경하면 해당 사용자 자원 정책을 사용하는 모든 사용자에게 영향을 줄 수 있습니다. 자원 정책을 변경할 때는 사용자의 주의가 필요합니다.

원하는 열만 선택하여 표시하려면 테이블 오른쪽 하단의 '설정' 버튼을 클릭하세요.

프로젝트 자원 정책 수정 다이얼로그

현재 자원 정책을 파일로 저장하고 싶다면, 각 탭의 왼쪽 위에 위치한 'Tools' 메뉴를 클릭합니다. 메뉴를 클릭하면, 파일 다운로드 모달이 띄워지게 됩니다.

이미지 관리

세션 생성 시 사용할 이미지 관리는 Environments 페이지의 Images 탭에서 할 수 있습니다. 탭에 들어가면 현재 Backend.AI 서버에서 가지고 있는 모든 이미지의 메타 정보가 출력됩니다. 이미지 별로 속한 레지스트리, 네임스페이스, 이미지 이름, 이미지의 기반 OS, Digest, 요구되는 최소 자원 등의 정보를 확인할 수 있습니다. 관리되고 있는 agent 노드 중 하나 이상에 다운로드 되어 있는 이미지의 경우 installed 태그가 각 이미지의 Status 컬럼에 표시됩니다.

참고

특정 agent를 선택하여 이미지를 설치하는 기능은 현재 개발 중에 있습니다.

Controls 열의 '설정' 버튼을 클릭하여 이미지의 최소 자원 요구량을 변경할 수 있습니다. 이미지마다 최소 동작을 위해 필요한 연산 자원 양 및 하드웨어가 있습니다. (예를 들어, GPU 전용 이미지의 경우 최소 할당 GPU가 있어야 합니다.) 최소 자원량의 기본값은 이미지의 메타데이터에 포함된 채로 제공됩니다. 각 이미지마다 지정 된 자원의 양보다 작은 자원으로 세션을 생성하려고 할 경우, 해당 요청은 자동으로 이미지 최소 자원 요구량으로 조정된 후 생성됩니다.

경고

미리 지정된 값보다 작은 양으로 최소 자원 요구량을 변경하지 마세요! 이미지 메타데이터에 포함된 최소 자원 요구량은 테스트를 거쳐 결정된 값입니다. 변경하려는 최소 자원량에 대하여 정말 잘 알고 있는 것이 아니라면, 기본값으로 남겨두시기 바랍니다.

또한 Controls 열의 '앱' 버튼을 클릭하여 이미지 별로 지원하는 앱을 추가하거나 수정할 수 있습니다. 앱 버튼을 클릭하면, 이미지에서 지원하는 앱과 대응하는 포트넘버를 확인하실 수 있습니다.

이 모달에서는 'Add' 버튼을 클릭하여 지원되는 커스텀 앱을 추가할 수 있습니다. 앱을 삭제하고 싶다면, 각 행에 오른쪽에 있는 '빨간색 휴지통 버튼' 을 클릭하면 됩니다.

참고

이미지에서 지원하는 앱을 수정할 경우에는 이미지 재설치가 필요합니다.

도커 레지스트리 관리

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 버전부터는 쿼타 관리를 지원하는 스토리지에 대해 사용자별/프로젝트별 쿼타 설정이 가능합니다. 이 기능을 사용함으로써, 관리자는 좀 더 손쉽게 사용자와 프로젝트용 폴더가 스토리지 내에서 얼마만큼 공간을 차지하고 있는지 확인하고 관리할 수 있습니다.

쿼타를 설정하기 위해서는 자원 페이지의 '저장소(Storage)' 탭을 누르고, 컨트롤 컬럼의 '설정' 버튼을 클릭합니다.

참고

쿼타 설정은 해당 기능을 제공하는 저장소 (예: 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 패널을 확인하십시오.

참고

이 페이지는 현재 정보를 보여주기 위한 것입니다.