9.1.2. iSCSI Name, ISID, and TPGT Use
9.1.2. iSCSI 이름, ISID, TPGT 사용
The designers of the iSCSI protocol envisioned there being one iSCSI Initiator Node Name per operating system image on a machine.
iSCSI 프로토콜 설계자는 시스템의 운영 체제 이미지당 하나의 iSCSI 이니시에이터 노드 이름이 있는 것을 구상했습니다.
This enables SAN resource configuration and authentication schemes based on a system's identity.
이를 통해 시스템 ID를 기반으로 하는 SAN 리소스 구성 및 인증 체계가 가능해집니다.
It supports the notion that it should be possible to assign access to storage resources based on "initiator device" identity.
이는 "이니시에이터 장치" ID를 기반으로 스토리지 리소스에 대한 액세스를 할당하는 것이 가능해야 한다는 개념을 지원합니다.
When there are multiple hardware or software components coordinated as a single iSCSI Node, there must be some (logical) entity that represents the iSCSI Node that makes the iSCSI Node Name available to all components involved in session creation and login.
단일 iSCSI 노드로 조정되는 여러 하드웨어 또는 소프트웨어 구성 요소가 있는 경우 세션 생성 및 로그인과 관련된 모든 구성 요소에서 iSCSI 노드 이름을 사용할 수 있도록 하는 iSCSI 노드를 나타내는 일부 (논리적) 엔터티가 있어야 합니다.
Similarly, this entity that represents the iSCSI Node must be able to coordinate session identifier resources (ISID for initiators) to enforce both the ISID and TSIH RULES (see Section 3.4.3 Consequences of the Model).
마찬가지로, iSCSI 노드를 나타내는 이 엔터티는 ISID 및 TSIH 규칙을 모두 적용하기 위해 세션 식별자 리소스 (초기자의 경우 ISID)를 조정할 수 있어야 합니다 (섹션 3.4.3 모델 결과 참조).
For targets, because of the closed environment, implementation of this entity should be straightforward.
타겟의 경우, 폐쇄된 환경으로 인해 이 엔터티의 구현이 간단해야 합니다.
However, vendors of iSCSI hardware (e.g., NICs or HBAs) intended for targets, SHOULD provide mechanisms for configuration of the iSCSI Node Name across the portal groups instantiated by multiple instances of these components within a target.
하지만 대상용 iSCSI 하드웨어 (예: NIC 또는 HBA) 공급업체는 타겟 내 이러한 구성 요소의 여러 인스턴스에 의해 인스턴스화된 포털 그룹 전체에 걸쳐 iSCSI 노드 이름 구성을 위한 메커니즘을 제공해야 합니다.
However, complex targets making use of multiple Target Portal Group Tags may reconfigure them to achieve various quality goals.
하지만 여러 타겟 포털 그룹 태그를 사용하는 복잡한 타겟은 다양한 품질 목표를 달성하기 위해 태그를 재구성할 수 있습니다.
The initiators have two mechanisms at their disposal to discover and/or check reconfiguring targets - the discovery session type and a key returned by the target during login to confirm the TPGT.
이니시에이터에는 재구성 대상을 검색 및/또는 확인하기 위한 두 가지 메커니즘, 즉 검색 세션 유형과 TPGT를 확인하기 위해 로그인 중에 대상이 반환하는 키가 있습니다.
An initiator should attempt to "rediscover" the target configuration anytime a session is terminated unexpectedly.
이니시에이터는 세션이 예기치 않게 종료될 때마다 타겟 구성을 "재검색"하려고 시도해야 합니다.
For initiators, in the long term, it is expected that operating system vendors will take on the role of this entity and provide standard APIs that can inform components of their iSCSI Node Name and can configure and/or coordinate ISID allocation, use, and reuse.
이니시에이터의 경우, 장기적으로 운영 체제 공급업체가 이 엔터티의 역할을 맡아 구성 요소에 iSCSI 노드 이름을 알리고 ISID 할당, 사용 및 재사용을 구성 및/또는 조정할 수 있는 표준 API를 제공할 것으로 예상됩니다.
Recognizing that such initiator APIs are not available today, other implementations of the role of this entity are possible.
현재 이러한 이니시에이터 API를 사용할 수 없다는 점을 인식하면 이 엔터티 역할의 다른 구현이 가능합니다.
For example, a human may instantiate the (common) Node name as part of the installation process of each iSCSI component involved in session creation and login.
예를 들어, 사람은 세션 생성 및 로그인과 관련된 각 iSCSI 구성 요소의 설치 프로세스의 일부로 (공통) 노드 이름을 인스턴스화할 수 있습니다.
This may be done either by pointing the component to a vendor-specific location for this datum or to a system-wide location.
이는 구성 요소를 이 데이텀에 대한 공급업체별 위치나 시스템 전체 위치로 지정하여 수행할 수 있습니다.
The structure of the ISID namespace (see Section 10.12.5 ISID and [RFC3721]) facilitates implementation of the ISID coordination by allowing each component vendor to independently (of other vendor's components) coordinate allocation, use, and reuse of its own partition of the ISID namespace in a vendor-specific manner.
ISID 네임스페이스의 구조 (섹션 10.12.5 ISID 및 [RFC3721] 참조)는 각 구성 요소 공급업체가 다른 공급업체의 구성 요소와 독립적으로 공급업체별 방식으로 ISID 네임스페이스의 자체 파티션의 할당, 사용 및 재사용을 조정할 수 있도록 하여 ISID 조정을 구현하는 것을 용이하게 합니다.
Partitioning of the ISID namespace within initiator portal groups managed by that vendor allows each such initiator portal group to act independently of all other portal groups when selecting an ISID for a login; this facilitates enforcement of the ISID RULE (see Section 3.4.3 Consequences of the Model) at the initiator.
해당 공급업체가 관리하는 이니시에이터 포털 그룹 내에서 ISID 네임스페이스를 분할하면 각 이니시에이터 포털 그룹은 로그인을 위한 ISID를 선택할 때 다른 모든 포털 그룹과 독립적으로 작동할 수 있습니다. 이를 통해 이니시에이터에서 ISID 규칙 (섹션 3.4.3 모델의 결과 참조)을 시행하기가 용이해집니다.
A vendor of iSCSI hardware (e.g., NICs or HBAs) intended for use in initiators MUST implement a mechanism for configuring the iSCSI Node Name.
이니시에이터에서 사용하도록 고안된 iSCSI 하드웨어 (예: NIC 또는 HBA) 공급업체는 iSCSI 노드 이름을 구성하기 위한 메커니즘을 구현해야 합니다.
Vendors, and administrators must ensure that iSCSI Node Names are unique worldwide.
공급업체와 관리자는 iSCSI 노드 이름이 전 세계적으로 고유한지 확인해야 합니다.
It is therefore important that when one chooses to reuse the iSCSI Node Name of a disabled unit, not to re-assign that name to the original unit unless its worldwide uniqueness can be ascertained again.
따라서 비활성화된 장치의 iSCSI 노드 이름을 재사용하기로 선택한 경우 해당 이름을 전 세계적으로 고유하게 다시 확인할 수 없는 한 원래 장치에 다시 할당하지 않는 것이 중요합니다.
In addition, a vendor of iSCSI hardware must implement a mechanism to configure and/or coordinate ISIDs for all sessions managed by multiple instances of that hardware within a given iSCSI Node.
또한, iSCSI 하드웨어 공급업체는 지정된 iSCSI 노드 내에서 해당 하드웨어의 여러 인스턴스가 관리하는 모든 세션에 대해 ISID를 구성 및/또는 조정하는 메커니즘을 구현해야 합니다.
Such configuration might be either permanently pre-assigned at the factory (in a necessarily globally unique way), statically assigned (e.g., partitioned across all the NICs at initialization in a locally unique way), or dynamically assigned (e.g., on-line allocator, also in a locally unique way).
이러한 구성은 공장에서 영구적으로 사전 할당되거나 (반드시 전역적으로 고유한 방식으로) 정적으로 할당되거나 (예: 초기화 시 로컬에서 고유한 방식으로 모든 NIC에 걸쳐 분할됨) 동적으로 할당될 수 있습니다 (예: 온라인 할당자, 또한 지역적으로 고유한 방식으로).
In the latter two cases, the configuration may be via public APIs (perhaps driven by an independent vendor's software, such as the OS vendor) or via private APIs driven by the vendor's own software.
후자의 두 경우에는 공개 API (OS 공급업체와 같은 독립 공급업체의 소프트웨어에 의해 구동됨)를 통해 구성되거나 공급업체 자체 소프트웨어에 의해 구동되는 개인 API를 통해 구성될 수 있습니다.