IBM Cloud Docs
자주 묻는 질문 Block Storage for Classic

자주 묻는 질문 Block Storage for Classic

Block Storage for Classic 볼륨을 몇 개의 서버 인스턴스가 공유할 수 있나요?

블록 볼륨당 권한 부여 수에 대한 기본 한계는 8개입니다. 즉, 최대 8명의 호스트가 Block Storage for Classic 액세스할 수 있도록 승인될 수 있습니다. VMware® 배치에서 Block Storage for Classic을(를) 사용하는 고객은 권한 한계를 64로 늘리도록 요청할 수 있습니다. 한계 증가를 요청하려면 지원 케이스를 격상하여 지원 센터에 문의하십시오.

여러 호스트가 협력하여 관리하지 않고 동일한 Block Storage for Classic 볼륨을 마운트하는 경우 데이터가 손상될 위험이 있습니다. 여러 호스트가 동시에 볼륨을 변경하는 경우 볼륨 손상이 발생할 수 있습니다. CSV (Microsoft Cluster Shared Volumes), Red Hat Global File System (GFS2), VMware® VMFS등과 같은 데이터 손실을 방지하기 위해 클러스터 인식 공유 디스크 파일 시스템이 필요합니다. 자세한 내용은 호스트의 OS 설명서를 참조하세요.

컴퓨팅 호스트에 네트워크 중복성과 확장된 대역폭에 사용할 서로 다른 IP 주소가 있는 여러 네트워크 카드가 있습니다. 동일한 스토리지 볼륨에 액세스하도록 모두에 권한을 부여하는 방법은 무엇입니까?

콘솔, SLCLI 또는 API를 통해 특정 Block Storage for Classic 볼륨에 액세스하도록 IP 주소의 서브넷에 권한을 부여할 수 있습니다. 호스트에 서브넷의 여러 IP에서 연결할 수 있는 권한을 부여하려면 다음 단계를 완료하십시오.

콘솔

  1. 클래식 인프라로 이동하십시오.
  2. 스토리지 > Block Storage for Classic를 클릭하십시오.
  3. 볼륨을 찾고 생략 기호 조치 아이콘 를 클릭하십시오.
  4. 호스트 권한 부여를 클릭하십시오.
  5. 사용 가능한 IP 주소 목록을 보려면 호스트 유형으로 IP 주소를 선택합니다. 그런 다음 호스트가 있는 서브넷을 선택하십시오.
  6. 필터링된 목록에서 볼륨에 액세스할 수 있는 IP 주소를 하나 이상 선택하고 저장을 클릭하십시오.

SLCLI

$ slcli block subnets-assign -h
Usage: slcli block subnets-assign [OPTIONS] ACCESS_ID
  Assign block storage subnets to the given host id.
  access_id is the host_id obtained by: slcli block access-list <volume_id>

Options:
  --subnet-id INTEGER  ID of the subnets to assign; e.g.: --subnet-id 1234
  -h, --help           Show this message and exit.

주문할 수 있는 볼륨은 얼마나 됩니까?

기본적으로 블록 스토리지와 파일 스토리지 볼륨을 합쳐 총 700개까지 프로비저닝할 수 있습니다. 볼륨 한계를 늘리려면 지원 센터에 문의하십시오. 자세한 정보는 스토리지 한계 관리를 참조하십시오.

호스트에 마운트할 수 있는 Block Storage for Classic 볼륨은 몇 개입니까?

이는 호스트 운영 체제가 처리할 수 있는 기능에 따라 다르지만 IBM Cloud® 에서 제한하는 것은 아닙니다. 마운트할 수 있는 볼륨 수에 대한 한계는 OS 문서를 참조하십시오.

OS 설정이 다른 여러 볼륨을 연결할 수 있나요?

아니오. 호스트는 서로 다른 OS 유형의 볼륨에 동시에 액세스할 수 있는 권한을 부여받을 수 없습니다. 호스트는 단일 OS 유형의 볼륨에 액세스할 수 있는 권한을 부여받을 수 있습니다. 호스트에 서로 다른 OS 유형의 여러 볼륨에 액세스할 수 있는 권한을 부여하려고 하면 오류가 발생합니다.

Block Storage for Classic 볼륨을 위한 윈도우 버전을 어떻게 선택합니까?

볼륨을 만들 때는 OS 유형을 지정해야 합니다. OS 유형은 볼륨에 액세스할 호스트의 운영 체제를 지정합니다. 또한 볼륨에 있는 데이터의 레이아웃, 해당 데이터에 액세스하는 데 사용되는 기하학, 볼륨의 최소 및 최대 크기도 결정합니다. 볼륨이 생성된 후에는 OS 유형을 수정할 수 없습니다. 볼륨의 실제 크기는 볼륨의 OS 유형에 따라 약간 다를 수 있습니다. Windows OS에 대해 올바른 유형을 선택하면 잘못 정렬된 IO 조작을 방지하는 데 도움이 됩니다.

볼륨이 게스트에게 원시 블록 장치로 제공되는 경우, 게스트의 OS 유형을 선택합니다. 볼륨이 가상 하드 디스크(VHD) 파일을 제공하기 위해 하이퍼바이저에 제공되는 경우, Hyper-V를 선택합니다.

Windows GPT

  • 볼륨은 GUID 파티션 유형(GPT) 파티션 스타일을 사용하여 Windows 데이터를 저장합니다. GPT 파티셔닝 방법을 사용하고자 하며 호스트가 이를 사용할 수 있는 경우에 이 옵션을 사용하십시오. Windows Server 2003, 서비스 팩 1 이상은 GPT 파티셔닝 방법을 사용할 수 있으며, 모든 64비트 Windows 버전은 이를 지원합니다.

Windows 2003

  • 볼륨은 MBR(마스터 부트 레코드) 파티셔닝 스타일을 사용하는 단일 파티션 Windows 디스크에 원시 디스크 유형을 저장합니다. 호스트 운영 체제가 MBR 파티셔닝 방법을 사용하는 Windows 2000 Server, Windows XP 또는 Windows Server 2003인 경우에만 이 옵션을 사용하십시오.

Windows 2008+

  • 이 볼륨에는 Windows 2008 이상 버전의 Windows 데이터가 저장됩니다. 호스트 운영 체제가 Windows Server 2008, Windows Server 2012, Windows Server 2016인 경우에는 이 OS 옵션을 사용하십시오. MBR 및 GPT 파티셔닝 방법이 둘 다 지원됩니다.

Hyper-V

  • VHDX는 복원성 고성능 가상 디스크를 작성하기 위해 Windows Server 2012에서 도입된 가상 하드 디스크 형식입니다. 형식에는 더 큰 가상 디스크 크기 및 더 큰 블록 크기 지원과 같은 여러 이점이 있습니다. VHDX 메타데이터 구조에 대한 업데이트를 로깅하여 전원 장애 중 데이터 손상에 대한 보호를 제공합니다. 볼륨이 VHD 파일을 제공하기 위해 하이퍼바이저에 제공되는 경우, OS 유형으로 Hyper-V를 선택합니다.

할당된 IOPS 한계는 인스턴스로 적용됩니까, 아니면 볼륨으로 적용됩니까?

IOPS는 볼륨 레벨에서 적용됩니다. 즉, 6000 IOPS의 볼륨에 연결된 두 호스트가 6000 IOPS를 공유한다는 뜻입니다.

단일 호스트만 볼륨에 액세스하는 경우 사용 가능한 최대 IOPS를 인식하기 어려울 수 있으므로 볼륨에 액세스하는 호스트 수가 중요합니다.

IOPS 측정

IOPS는 무작위 50% 읽기 및 50% 쓰기가 포함된 16KB 블록의 로드 프로필을 기준으로 측정됩니다. 이 프로파일과 다른 워크로드에서는 성능이 저하될 수 있습니다. 성능 향상을 위해 호스트 큐 깊이 설정을 조정하거나 점보 프레임을 사용하도록 시도할 수 있습니다.

성능을 측정하는 데 더 작은 블록 크기를 사용하면 어떻게 됩니까?

더 작은 블록 크기를 사용해도 최대 IOPS를 얻을 수 있습니다. 그러나 처리량은 작아집니다. 예를 들어, 6000 IOPS의 볼륨의 경우 다양한 블록 크기에서 처리량은 다음과 같습니다.

  • 16KB * 6000IOPS == ~93.75MB/sec
  • 8KB * 6000IOPS == ~46.88MB/sec
  • 4KB * 6000IOPS == ~23.44MB/sec

스토리지가 얼마나 많이 사용되고 있는지 알 수 있는 방법은 무엇입니까? Block Storage for Classic 사용 내역이 콘솔에 표시되지 않는 이유는 무엇인가요?

Block Storage for Classic 는 사용자가 원하는 방식으로 포맷하고 관리할 수 있습니다. IBM Cloud® 는 볼륨의 내용을 볼 수 없으므로 UI에서 디스크 공간 사용량에 대한 정보를 제공할 수 없습니다. 컴퓨팅 호스트의 운영 체제에서 사용 가능한 디스크 공간 크기 및 사용 가능한 크기와 같은 볼륨에 대한 자세한 정보를 얻을 수 있습니다.

  • Linux® 에서 다음 명령을 사용할 수 있습니다.

    df -h
    

    명령은 사용 가능한 공간의 크기와 사용된 백분율을 표시하는 출력을 제공합니다.

    $ df -hT /dev/sda1
    Filesystem     Type      Size  Used Avail Use% Mounted on
    /dev/sda1      disk      6.0G  1.2G  4.9G  20% /
    
  • Windows에서는 이 PC 를 클릭하여 파일 탐색기에서 디스크 여유 공간을 확인할 수도 있으며, 두 가지 명령 옵션이 있습니다.

    fsutil volume diskfree C:
    
    dir C:
    

    출력의 마지막 줄에는 사용되지 않은 공간의 양이 표시됩니다.

내 OS에 표시되는 사용 가능한 용량이 내가 프로비저닝한 용량과 일치하지 않는 이유는 무엇입니까?

운영 체제가 base-2 변환을 사용하기 때문일 수 있습니다. 예를 들어 콘솔에서 4000GB 볼륨을 프로비저닝하면 스토리지 시스템은 4,000GB 볼륨을 예약합니다. GiB 볼륨 또는 4,294,967,296,000바이트의 저장 공간을 제공합니다. 프로비저닝된 볼륨 크기가 4TB보다 큽니다. 그러나 운영 체제에서는 저장소 크기를 다음과 같이 표시할 수 있습니다. 3.9 T를 사용하기 때문에 base-2 전환이며 T는 다음을 의미합니다. TiB, 결핵이 아닙니다.

두 번째로, Block Storage 를 파티셔닝하고 파일 시스템을 작성하면 사용 가능한 스토리지 공간이 줄어듭니다. 서식 지정으로 공간이 줄어드는 정도는 서식 지정 유형과 시스템에 있는 다양한 파일의 양과 크기에 따라 달라집니다.

저장 용량은 GB 단위로 측정됩니까? GiB?

스토리지의 한 가지 혼동되는 측면은 스토리지 용량 및 사용량이 보고되는 단위입니다. 때때로 GB는 실제로 GB (base-10) 이며 GB는 GiB로 축약되어야 하는 기비바이트 (base-2) 를 나타내기도 합니다.

일반적으로 사용자는 10진수 (base-10) 시스템에서 숫자를 생각하고 계산합니다. 이 문서에서는 업계 표준 용어에 맞게 단위 GB (GB) 를 사용하여 스토리지 용량을 참조합니다. UI, CLI, API및 Terraform에서 용량을 조회할 때 사용되고 표시되는 단위 GB가 표시됩니다. 4TB볼륨을 주문하려는 경우 프로비저닝 요청에 4,000GB를 입력합니다.

그러나 컴퓨터는 2진으로 작동하므로 base-2의 메모리 주소 공간과 같은 일부 자원을 표시하는 것이 더 좋습니다. 1984이후로 컴퓨터 파일 시스템은 메모리와 함께 base-2 로 크기를 표시합니다. 이전에는 사용 가능한 스토리지 디바이스가 더 작았으며 2진단위와 10진수단위 간의 크기 차이는 무시할 수 있었습니다. 사용 가능한 스토리지 시스템이 상당히 크므로 이 장치 차이로 인해 혼동이 발생합니다.

GB와 GiB 의 차이는 숫자 표시에 있습니다.

  • GB (기가바이트) 는 10진수단위입니다. 여기서 1GB는 1,000,000,000바이트에 해당합니다. GB를 TB로 변환할 때 승수로 1000을 사용합니다.
  • GiB (Gibibyte) 는 2진 단위입니다. 여기서 1 GiB 는 1,073 ,741,824바이트와 같습니다. 변환할 때 GiB 에게 TiB, 1024를 승수로 사용합니다.

다음 표는 10진수및 2진단위로 표시되는 동일한 바이트 수를 표시합니다.

십진법과 이진법 단위
10진수 SI (기본 10) 2진 (기본 2)
2,000 ,000 ,000 ,000 ,000 B 2,000 ,000 ,000 ,000 ,000 B
2,000 ,000 ,000KB 1,953,125,000 KiB
2,000 ,000MB 1,907,348 MiB
2,000GB 1,862 GiB
2TB 1.81 TiB

스토리지 시스템은 볼륨 할당에 base-2 단위를 사용합니다. 따라서 볼륨이 4,000 GB로 프로비저닝되는 경우 실제로 4,000 GiB 또는 4,294,967,296,000바이트의 스토리지 공간입니다. 프로비저닝된 볼륨 크기가 4TB보다 큽니다. 그러나 운영 체제에서는 저장소 크기를 다음과 같이 표시할 수 있습니다. 3.9 T를 사용하기 때문에 base-2 전환이며 T는 다음을 의미합니다. TiB, 결핵이 아닙니다.

예상 처리량을 달성하기 위해 볼륨을 미리 예열해야 하나요?

사전 준비는 필요하지 않습니다. 볼륨을 프로비저닝하는 즉시 지정된 처리량을 관찰할 수 있습니다.

더 빠른 이더넷 연결을 사용하면 더 많은 처리량을 달성할 수 있습니까?

처리량 제한은 LUN 수준에서 설정되며 이더넷 연결 속도가 빨라진다고 해서 제한이 증가하지는 않습니다. 그러나 보다 느린 이더넷 연결을 사용하면 대역폭에서 잠재적으로 병목 현상이 발생할 수 있습니다.

방화벽과 보안 그룹이 성능에 영향을 줍니까?

방화벽을 우회하는 VLAN을 통해 스토리지 트래픽을 실행하는 것이 가장 좋습니다. 소프트웨어 방화벽을 통해 스토리지 트래픽을 실행하면 대기 시간이 늘어나서 결국 스토리지 성능이 저하됩니다.

Block Storage for Classic 트래픽을 고유 VLAN 인터페이스로 라우팅하고 방화벽을 우회할 수 있는 방법은 무엇입니까?

이 우수 사례를 규정하려면 다음 단계를 완료하십시오.

  1. 호스트 및 Block Storage for Classic 디바이스와 동일한 데이터 센터에서 VLAN을 프로비저닝하십시오. 자세한 정보는 VLAN 시작하기를 참조하십시오.

  2. 새 VLAN.3으로 보조 사설 서브넷 프로비저닝

  3. 새 VLAN을 호스트의 사설 인터페이스에 트렁크하십시오. 자세한 내용은 내 VLAN을 서버로 트렁크하는 방법을 참조하세요.

    이 조치로 인해 VLAN이 호스트에 트렁크되는 동안 호스트에서 네트워크 트래픽이 일시적으로 중단됩니다.

  4. 호스트에서 네트워크 인터페이스를 작성하십시오.

    • Linux® 또는 Windows에서 802.11q 인터페이스를 만듭니다. 새로 트렁크된 VLAN에서 사용되지 않은 보조 IP 주소 중 하나를 선택하고 해당 IP 주소, 서브넷 마스크 및 게이트웨이를 작성한 새 802.11q 인터페이스에 지정하십시오.
    • VMware®에서 VMkernel 네트워크 인터페이스(vmk)를 작성하고 새로 트렁크된 VLAN에서 새 VMK 인터페이스로 사용되지 않은 보조 IP 주소, 서브넷 마스크 및 게이트웨이를 지정하십시오.
  5. 호스트의 새 지속적 정적 라우트를 대상 iSCSI 서브넷에 추가하십시오.

  6. 새로 추가된 인터페이스의 IP가 호스트 권한 부여 목록에 추가되었는지 확인합니다.

  7. 다음 주제에 설명된 대로 발견을 수행하고 대상 포털에 로그인하십시오.

802.3ad LACP 포트 채널을 통해 iSCSI 트래픽을 실행하는 것이 좋습니까?

아니오. LACP(Link Aggregation Control Protocol)는 iSCSI를 사용한 권장 구성이 아닙니다. I/O 밸런싱 및 이중화를 위해 다중 경로 입력/출력(MPIO) 프레임워크를 사용하세요.

MPIO 구성을 사용하는 경우, 여러 NIC가 있는 서버가 사용 가능한 모든 인터페이스에서 해당 MPIO 지원 스토리지 디바이스로 I/O를 전송 및 수신할 수 있습니다. 이 설정은 경로 중 하나를 사용할 수 없게 되더라도 스토리지 트래픽이 안정적으로 유지될 수 있도록 이중화 기능을 제공합니다. 서버에 두 개의 1Gb NIC가 있고 스토리지 서버에 두 개의 1Gb NIC가 있는 경우 이론상 최대 처리량은 약 200MB/s입니다.

NIC 팀 구성을 통한 링크 집계(예: LACP 또는 802.3ad)는 MPIO와 동일한 방식으로 작동하지 않습니다. 링크 집계는 단일 I/O 플로우의 처리량을 개선하지 않고 여러 경로를 제공하지도 않습니다. 단일 플로우는 항상 단일 경로를 따라 이동합니다. 여러 개의 "고유" 플로우가 있고 각 플로우의 소스가 서로 다른 경우 링크 집계의 이점이 보일 수 있습니다. 각 개별 흐름은 해시 알고리즘에 의해 결정되는 자체 사용 가능한 NIC 인터페이스를 통해 전송됩니다. 따라서 고유 플로우가 많으면 더 많은 NIC가 더 높은 집계 처리량을 제공할 수 있습니다.

서버와 스위치 사이에는 결합이 작동합니다. 그러나 MPIO는 스위치가 경로에 있는 경우에도 스토리지 서버와 호스트 사이에서 작동합니다.

자세한 정보는 다음 문서 중 하나를 참조하십시오.

Block Storage for Classic의 예상 대기 시간은 얼마입니까?

스토리지 내의 목표 대기 시간은 1밀리초입니다. 스토리지가 공유 네트워크의 컴퓨팅 인스턴스에 연결되므로 정확한 성능 대기 시간은 조작 중 네트워크 트래픽에 따라 다릅니다.

부적합한 데이터 센터에서 Block Storage for Classic 볼륨을 주문했습니다. 스토리지를 다른 데이터 센터로 이동하거나 마이그레이션할 수 있습니까?

올바른 데이터 센터에 새 Block Storage for Classic 볼륨을 주문한 다음 잘못된 위치에서 주문한 Block Storage for Classic 장치를 취소해야 합니다.

공유의 복제본을 만들고 상위 공유를 취소할 수도 있습니다. 자세한 내용은 중복 볼륨 만들기 및 관리하기를 참조하세요.

Block Storage for Classic 볼륨을 '즉시' 취소했지만 콘솔에는 여전히 표시되어 있습니다. 왜 삭제되지 않나요?

볼륨이 취소되면 요청 뒤에 24시간재생 대기 기간이 옵니다. 이 24시간 동안에는 콘솔에서 해당 볼륨을 계속 확인할 수 있습니다. 24시간의 대기 기간을 통해 필요한 경우 취소 요청을 무효화할 수 있습니다. 볼륨 삭제를 취소하려면 지원 케이스를 제기하십시오. 볼륨에 대한 비용 청구는 즉시 중지됩니다. 재생 기간이 만료되면 데이터가 손상되고 볼륨이 콘솔에서도 제거됩니다.

암호화된 Block Storage for Classic 볼륨을 어떻게 알 수 있습니까?

IBM Cloud® 콘솔에서 Block Storage for Classic 목록을 보면 암호화된 볼륨의 볼륨 이름 옆에 자물쇠 아이콘이 있는 것을 볼 수 있습니다.

Db2 pureScale에 대한 I/O 펜싱을 구현하기 위한 Block Storage for Classic의 SCSI-3 Persistent Reserve를 지원합니까?

예, Block Storage for Classic는 SCSI-2 및 SCSI-3 Persistent Reserve를 지원합니다.

Block Storage for Classic 볼륨이 삭제되면 데이터는 어떻게 됩니까?

IBM Cloud® Block Storage for Classic는 재사용 전에 삭제되는 물리적 스토리지의 고객에게 블록 볼륨을 표시합니다.

Block Storage for Classic 볼륨을 삭제하면 해당 데이터에 즉시 액세스할 수 없게 됩니다. 물리적 디스크의 데이터에 대한 모든 포인터가 제거됩니다. 나중에 같은 계정이나 다른 계정에서 새 볼륨을 작성하면 새 포인터 세트가 할당됩니다. 해당 포인터가 삭제되었으므로 계정은 물리적 스토리지에 있는 데이터에 액세스할 수 없습니다. 새 데이터가 디스크에 기록되면 삭제된 볼륨에서 액세스할 수 없는 모든 데이터가 겹쳐쓰기됩니다.

IBM은 삭제된 데이터에 액세스할 수 없으며 삭제된 데이터가 결국 겹쳐써지고 삭제됨을 보장합니다. 또한 Block Storage for Classic 볼륨을 삭제하는 경우, 해당 블록을 겹쳐써야 사용자 또는 다른 고객이 해당 블록 스토리지를 다시 사용할 수 있습니다.

IBM이 실제 드라이브를 폐기할 때 드라이브는 폐기하기 전에 영구 삭제됩니다. 폐기된 드라이브는 사용할 수 없으며 이 드라이브의 데이터에는 액세스할 수 없습니다.

매체 완전 삭제를 위한 NIST 800-88 가이드라인과 같은 규제 준수에 대한 특별한 요구사항을 가진 고객은 스토리지를 삭제하기 전에 데이터 완전 삭제 프로시저를 수행할 수 있습니다.

클라우드 데이터 센터에서 폐기된 드라이브는 어떻게 됩니까?

드라이브가 폐기되는 경우 IBM은 이를 처분하기 전에 파기합니다. 해당 드라이브는 사용할 수 없는 상태가 됩니다. 해당 드라이브에 쓰여진 데이터는 더 이상 액세스할 수 없습니다.

클라우드 콘솔에서 취소 작업이 비활성화되어 있어서 Block Storage for Classic 볼륨을 취소할 수 없습니다. 그러면 어떻게 됩니까?

이 스토리지 디바이스에 대한 취소 프로세스가 진행 중이므로 더 이상 취소 조치를 사용할 수 없습니다. 볼륨은 회수될 때까지 최소 24시간 동안 표시됩니다. UI에 비활성 상태가 표시되고 "취소 보류 중" 상태가 표시됩니다. 최소 24시간의 대기 기간을 통해 필요한 경우 취소 요청을 무효화할 수 있습니다. 볼륨 삭제를 취소하려면 지원 케이스를 제기하십시오.

실수로 볼륨을 삭제했는데 어떻게 하면 다시 복구할 수 있나요?

답변은 스토리지 볼륨을 삭제한 지 얼마나 되었는지, 즉시 삭제할지 아니면 기념일에 삭제할지 여부에 따라 달라집니다. 지난 24시간 이내에 삭제되었거나 기념일이 아직 다가오지 않은 경우, 해당 볼륨은 아직 회수 대기 중일 수 있습니다. 볼륨 상태가 '취소 보류 중'인 경우 지원팀에 문의하여 취소 요청을 무효화할 수 있습니다. 회수 기간이 만료되면 데이터가 자동으로 삭제되고 더 이상 복구할 수 없으므로 신속하게 조치를 취하는 것이 중요합니다.

내 Windows 2012 호스트는 여러 스토리지 볼륨에 액세스할 수 있어야 하는데 디스크 관리자에서 해당 볼륨을 볼 수 없습니다. 이 오류를 수정하려면 어떻게 해야 합니까?

동일한 호스트에서 두 개 이상의 볼륨을 사용하고 모든 iSCSI 연결이 동일한 스토리지 장치에서 이루어지는 경우 디스크 관리자에는 두 개의 장치만 표시될 수 있습니다. 이 상황이 발생하면 iSCSI 이니시에이터에서 각 장치에 수동으로 연결해야 합니다. 자세한 정보는 Windows 2012 R2 - 다중 iSCSI 디바이스 문제점 해결을 참조하십시오.

Windows Server 2012 R2 의 지원은 2023년 10월 10일에 종료됩니다. Microsoft는 더 이상 이 운영 체제에 대한 보안 업데이트, 버그 수정 또는 기술 지원을 제공하지 않습니다. 서버를 Windows Server 2022와 같은 최신 운영 체제로 마이그레이션하십시오.

내 스토리지가 오프라인 또는 읽기 전용으로 표시됩니다. 이 문제가 발생한 이유는 무엇이며 이 문제를 어떻게 수정합니까?

일부 시나리오에서는 호스트(베어메탈 또는 VM)가 스토리지에 대한 연결이 잠시 끊어질 수 있으며, 그 결과 데이터 손상을 방지하기 위해 읽기 전용 볼륨으로 간주합니다. 대부분의 경우 연결 끊김은 네트워크와 관련이 있지만, 네트워크 연결이 복원된 경우에도 스토리지 상태가 호스트 관점에서 계속 읽기 전용으로 남아 있습니다. 호스트를 다시 시작하면 읽기 전용 상태 문제가 해결됩니다.

이 문제는 MPIO 설정이 올바르지 않은 호스트에서 발견될 수 있습니다. MPIO가 올바르게 구성되지 않은 경우 호스트는 스토리지에 대한 연결이 끊어지고 연결 문제가 해결되어도 스토리지에 다시 연결하지 못할 수 있습니다.

단일 경로로 Block Storage for Classic에 접속할 수 있습니까? 다중 경로를 사용해야 하나요?

하나의 경로로 볼륨을 연결할 수도 있지만 서비스 중단을 방지하려면 두 경로 모두에 연결을 설정하는 것이 중요합니다. MPIO 연결 구성에 대한 자세한 정보는 다음 문서를 참조하십시오.

Block Storage for Classic 볼륨에 대한 다중 경로 연결을 구성 및 유효성 검증하려면 어떻게 해야 합니까?

계획된 유지보수 또는 계획되지 않은 중단 중에 경로 중 하나가 중단됩니다. MPIO가 올바르게 구성된 경우 호스트는 여전히 두 번째 경로를 통해 첨부된 스토리지에 액세스할 수 있습니다. MPIO 설정에 대한 자세한 내용은 다음 항목을 참조하세요.

일반적으로 로드 밸런싱이 적용되는 스토리지 데이터 경로가 일시적으로 중단되면, 컴퓨팅 호스트는 연결된 스토리지와 통신하기 위해 살아남은 데이터 경로 중 하나를 선택해야 합니다. 결과적으로, 증가된 데이터 트래픽은 더 적은 데이터 경로를 통해 이동합니다. 더 적은 리소스로 더 많은 요청을 처리하기 때문에 지연 시간과 연결 설정 시간이 늘어날 수 있습니다.

드물게 볼륨이 프로비저닝되고 연결되어 있는 동안 두 번째 경로가 다운되는 경우가 있습니다. 이러한 경우, 호스트는 감지 스캔이 실행될 때 하나의 단일 경로를 볼 수 있습니다. 이러한 현상이 발생하면 IBM Cloud® 상태 페이지 를 확인하여 이벤트가 스토리지에 액세스하는 호스트의 기능에 영향을 주는지 확인하십시오. 이벤트가 보고되지 않으면 검색 스캔을 다시 수행하여 모든 경로가 제대로 검색되었는지 확인합니다. 이벤트가 진행 중인 경우 스토리지를 단일 경로로 첨부할 수 있습니다. 그러나 이벤트가 완료된 후 경로가 다시 스캔되어야 합니다. 재검색 후에도 두 경로가 모두 발견되지 않으면 지원 케이스를 만들어 제대로 조사할 수 있도록 하세요.

VMware 배포에서 보다 안정적인 연결을 위해, 먼저 하이퍼바이저에 네트워크 스토리지를 마운트 하십시오(마운트 ISCSI VMware ESXi 참조). 그런 다음, 가상 머신을 생성하고, 다중 경로 연결을 통해 가상 서버의 OS에서 연결된 저장 볼륨을 마운트합니다. 더 자세한 정보는 ESXi를 iSCSI SAN과 함께 사용하기, ESXi 환경에서의 다중 경로 및 장애 조치 이해하기, ESXi를 사용한 iSCSI 및 iSER 용 네트워크 설정하기를 참고하세요.

Cloud 콘솔을 통해 내 Block Storage for Classic의 볼륨 크기를 확장했으나 내 서버의 크기는 여전히 동일합니다. 이 오류를 수정하려면 어떻게 해야 합니까?

새로 확장된 볼륨 크기를 확인하려면 서버에서 기존 Block Storage for Classic 디스크를 다시 검색하고 재구성해야 합니다. 다음 예제를 참조하십시오. 자세한 정보는 해당 운영 체제 문서를 참조하십시오.

Windows 2016

  1. Server Manager > Tools > Computer Management > Disk Management로 이동하십시오.
  2. Action > Refresh를 클릭하십시오.
  3. Action > Rescan Disks를 클릭하십시오. 이 과정을 완료하는 데 최대 5분 이상 소요될 수 있습니다. 추가 용량은 기존 디스크에서 할당 해제된 파티션으로 표시됩니다.
  4. 할당 해제된 공간을 원하는 대로 분할합니다. 자세한 정보는 Microsoft-기본 볼륨 확장을 참조하십시오.

Linux

  1. 확장한 블록 스토리지 디바이스의 각 다중 경로 세션에서 로그아웃하십시오.

    # iscsiadm --mode node --portal <Target IP> --logout
    
  2. 다시 로그인하십시오.

    # iscsiadm --mode node --portal <Target IP> --login
    
  3. iscsi 세션을 다시 스캔하십시오.

    # iscsiadm -m session --rescan
    
  4. 스토리지가 확장되었는지 확인하기 위해 fdisk -l을(를) 사용하여 새 크기를 나열하십시오.

  5. 다중 경로 장치 맵을 다시 로드하십시오.

    # multipath -r <WWID>
    
    # multipath -r 3600a09803830477039244e6b4a396b30
    reload: 3600a09803830477039244e6b4a396b30 undef NETAPP  ,LUN C-Mode
    size=30G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=undef
    |-+- policy='round-robin 0' prio=50 status=undef
    | `- 2:0:0:3 sda  8:0     active ready running
    `-+- policy='round-robin 0' prio=10 status=undef
    `- 4:0:0:3 sdd  8:48    active ready running
    
  6. 파일 시스템을 확장하십시오.

    • LVM

      1. 실제 볼륨의 크기를 조정하십시오.

        # pvresize /dev/mapper/3600a09803830477039244e6b4a396b30
          Physical volume "/dev/mapper/3600a09803830477039244e6b4a396b30" changed
          1 physical volume(s) resized or updated / 0 physical volume(s) not resized
        
        # pvdisplay -m /dev/mapper/3600a09803830477039244e6b4a396b30
          --- Physical volume ---
          PV Name               /dev/mapper/3600a09803830477039244e6b4a396b30
          VG Name               vg00
          PV Size               <30.00 GiB / not usable 3.00 MiB
          Allocatable           yes
          PE Size               4.00 MiB
          Total PE              7679 - Changed  <- new number of physical extents
          Free PE               2560
          Allocated PE          5119
          PV UUID               dehWT5-VxgV-SJsb-ydyd-1Uck-JUA9-B9w0cO
        
          --- Physical Segments ---
          Physical extent 0 to 5118:
          Logical volume  /dev/vg00/vol_projects
          Logical extents 6399 to 11517
          Physical extent 5119 to 7678:
            FREE
        
      2. 논리적 볼륨의 크기를 조정하십시오.

        # lvextend -l +100%FREE -r /dev/vg00/vol_projects
          Size of logical volume vg00/vol_projects changed from 49.99 GiB (12798 extents) to 59.99 GiB (15358 extents).
          Logical volume vg00/vol_projects successfully resized.
          resize2fs 1.42.9 (28-Dec-2013)
          Filesystem at /dev/mapper/vg00-vol_projects is mounted on /projects; on-line resizing required
          old_desc_blocks = 7, new_desc_blocks = 8
          The filesystem on /dev/mapper/vg00-vol_projects is now 15726592 blocks long.
        
        # lvdisplay
          --- Logical volume ---
          LV Path                /dev/vg00/vol_projects
          LV Name                vol_projects
          VG Name                vg00
          LV UUID                z1lukZ-AuvR-zjLr-u1kK-eWcp-AHjX-IcnerW
          LV Write Access        read/write
          LV Creation host, time acs-kyungmo-lamp.tsstesting.com, 2021-12-07 19:34:39 -0600
          LV Status              available
          # open                 1
          LV Size                59.99 GiB <--- new logical volume size
          Current LE             15358
          Segments               4
          Allocation             inherit
          Read ahead sectors     auto
          - currently set to     8192
          Block device           253:2
        
      3. 파일 시스템 크기를 확인합니다.

        # df -Th /projects
        Filesystem                    Type  Size  Used Avail Use% Mounted on
        /dev/mapper/vg00-vol_projects ext4   59G  2.1G   55G   4% /projects
        

        자세한 정보는 RHEL 8-논리 볼륨 수정을 참조하십시오.

    • Non-LVM - ext2, ext3, ext4:

      1. growpartxfs_progs 유틸리티를 사용하여 디스크의 기존 파티션을 확장하십시오. 설치해야 하는 경우 다음 명령을 실행하십시오.

        # yum install cloud-utils-growpart xfsprogs -y
        
        1. 파티션을 확장할 볼륨을 마운트 해제하십시오.

          # umount /dev/mapper/3600a098038304338415d4b4159487669p1
          
        2. growpart 유틸리티를 실행하십시오. 이 조치는 ext2, ext3, ext 또는 xfsf 파일 시스템인지 여부에 상관없이 지정된 파티션을 확장합니다.

          # growpart /dev/mapper/3600a098038304338415d4b4159487669 1
          CHANGED: partition=1 start=2048 old: size=146800640 end=146802688 new: size=209713119,end=209715167
          
        3. partprobe 을 실행하여 디스크와 해당 파티션을 다시 읽은 다음 lsblk 을 실행하여 새 확장 파티션 크기를 확인합니다.

          # partprobe
          
          # lsblk
          NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
          sda 8:0 0 100G 0 disk
          ├─sda1 8:1 0 100G 0 part
          └─3600a098038304338415d4b4159487669 253:0 0 100G 0 mpath
          └─3600a098038304338415d4b4159487669p1 253:1 0 100G 0 part
          sdb 8:16 0 100G 0 disk
          └─3600a098038304338415d4b4159487669 253:0 0 100G 0 mpath
          └─3600a098038304338415d4b4159487669p1 253:1 0 100G 0 part
          xvda 202:0 0 100G 0 disk
          ├─xvda1 202:1 0 256M 0 part /boot
          └─xvda2 202:2 0 99.8G 0 part /
          xvdb 202:16 0 2G 0 disk
          └─xvdb1 202:17 0 2G 0 part [SWAP]
          
      2. 파티션에서 기존 파일 시스템을 확장하십시오.

        1. 파티션을 마운트 해제하십시오.

          # umount /dev/mapper/3600a098038304338415d4b4159487669p1
          
        2. 크기 조정을 진행하기 전에 e2fsck -f 을 실행하여 파일 시스템이 깨끗하고 문제가 없는지 확인합니다.

          # e2fsck -f /dev/mapper/3600a098038304338415d4b4159487669p1
          e2fsck 1.42.9 (28-Dec-2013)
          Pass 1: Checking inodes, blocks, and sizes
          Pass 2: Checking directory structure
          Pass 3: Checking directory connectivity
          Pass 4: Checking reference counts
          Pass 5: Checking group summary information
          /dev/mapper/3600a098038304338415d4b4159487669p1: 12/4587520 files (0.0% non-contiguous), 596201/18350080 blocks
          
        3. resize2fs 명령을 실행하여 파일 시스템의 크기를 조정하십시오.

          # resize2fs /dev/mapper/3600a098038304338415d4b4159487669p1
          resize2fs 1.42.9 (28-Dec-2013)
          Resizing the filesystem on /dev/mapper/3600a098038304338415d4b4159487669p1 to 26214139 (4k) blocks.
          The filesystem on /dev/mapper/3600a098038304338415d4b4159487669p1 is now 26214139 blocks long.
          
        4. 파티션을 마운트하고 df -vh 를 실행하여 새 크기가 올바른지 확인하십시오.

          # mount /dev/mapper/3600a098038304338415d4b4159487669p1 /SL02SEL1160157-73
          
          # df -vh
          Filesystem Size Used Avail Use% Mounted on
          /dev/xvda2 99G 3.7G 90G 4% /
          devtmpfs 3.9G 0 3.9G 0% /dev
          tmpfs 3.9G 1.7M 3.9G 1% /dev/shm
          tmpfs 3.9G 25M 3.8G 1% /run
          tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
          /dev/xvda1 240M 148M 80M 65% /boot
          fsf-sjc0401b-fz.adn.networklayer.com:/SL02SV1160157_8/data01 40G 1.1G 39G 3% /SL02SV1160157_8
          tmpfs 782M 0 782M 0% /run/user/0 /dev/mapper/3600a098038304338415d4b4159487669p1 99G 1.1G 93G 2% /SL02SEL1160157-73
          
    • Non-LVM - xfs

      1. xfs 파일시스템을 마운트 포인트로 다시 마운트하십시오. xfs 파티션의 이전 마운트 포인트가 확실하지 않은 경우 /etc/fstab을(를) 참조하십시오.

        # mount /dev/sdb1 /mnt
        
      2. 파일 시스템을 확장하십시오. 파일 시스템의 마운트 지점을 대체하십시오.

        # xfs_growfs -d </mnt>
        

단일 스토리지 디바이스를 추가할 때 디스크 관리에 두 개의 디스크가 표시되는 이유는 무엇입니까?

MPIO가 설치되지 않았거나 ISCSI에 사용할 수 없을 때 디스크 관리에 두 개의 디스크가 표시됩니다. MPIO 구성을 확인하려면 Linux® 에 대한 MPIO 구성 확인 또는 Windows 운영 체제에서 MPIO가 올바르게 구성되었는지 확인하는 단계를 참조하세요.

섀시 스왑 후 어떻게 다시 스토리지에 연결합니까?

섀시 스왑 후에 스토리지를 다시 연결하려면 다음 단계를 완료하십시오.

  1. 스왑 전에 스토리지 디바이스에서 권한을 제거하십시오(액세스 권한 취소).
  2. 스왑 후에 호스트에 다시 권한을 부여하십시오.
  3. 새 권한으로부터 얻은 새 인증 정보를 사용하여 스토리지 디바이스를 다시 검색하십시오.

자세한 정보는 Block Storage for Classic 관리를 참조하십시오.

호스트에서 내 스토리지 디바이스의 연결을 끊는 방법은 무엇입니까?

호스트에서 연결을 끊으려면 다음 단계를 완료하십시오.

  1. 운영 체제 ISCSI 세션을 제거하고 디바이스를 마운트 해제하십시오(해당 경우).
  2. IBM Cloud® 콘솔에서 저장 장치에서 호스트에 대한 액세스 권한을 해지합니다.
  3. 자동 검색을 제거하고 ISCSI 연결을 위해 운영 체제에서 현재 데이터베이스 항목을 제거하십시오(해당 경우).

Endurance와 성능 스토리지의 차이점은 무엇입니까?

Endurance와 성능은 스토리지 디바이스에 대해 선택할 수 있는 옵션을 프로비저닝합니다. 즉, Endurance IOPS 티어는 사전 정의된 성능 레벨을 제공하지만 성능 티어로 해당 레벨을 상세 조정할 수 있습니다. 동일한 장치를 사용하여 다양한 옵션을 제공하는 서비스를 제공합니다. 자세한 내용은 IBM Cloud Block Storage: 세부 정보를 참조하세요.

스토리지를 업그레이드할 수 없습니다. 스토리지를 업그레이드하거나 확장시키는 기능에 영향을 미치는 항목은 무엇입니까?

스토리지를 업그레이드하거나 확장시키는 기능에 영향을 줄 수 있는 상황은 다음과 같습니다.

스토리지를 업그레이드하면 볼륨에 있는 데이터에 영향을 주나요?

아니오. 스토리지 볼륨을 확장하거나 IOPS 값을 조정해도 변경 사항은 데이터에 영향을 미치지 않습니다. 이러한 작업 중에는 아무것도 덮어쓰거나 지워지지 않습니다. 이 조정으로 인해 스토리지가 중단되거나 액세스 부족이 발생하지 않습니다.

iSCSI 볼륨이 얇게 프로비저닝되나요, 아니면 두껍게 프로비저닝되나요?

모든 파일 및 Block Storage for Classic 서비스는 씬 프로비저닝되었습니다. 이 방법은 수정할 수 없습니다.

내 청구 ID가 바뀌었습니다. 이것은 무엇을 의미합니까?

이제 스토리지 볼륨이 "Enterprise Storage" 대신 "Endurance 스토리지 서비스" 또는 "Performance 스토리지 서비스" 로 청구되는 것을 알 수 있습니다. 콘솔에 IOPS를 조정하거나 용량을 늘리는 기능과 같은 새 옵션이 있을 수도 있습니다. IBM Cloud® 는 스토리지 기능을 지속적으로 개선하기 위해 노력합니다. 데이터센터의 하드웨어가 업그레이드되면 해당 데이터센터에 있는 스토리지 볼륨도 모든 향상된 기능을 사용할 수 있도록 업그레이드됩니다. 스토리지 볼륨에 대해 지불하는 가격은 이 업그레이드와 함께 변경되지 않습니다.

Block Storage for Classic는 얼마나 지속됩니까?

데이터를 Block Storage for Classic에 저장하면 지속적이고 가용성이 높으며 암호화됩니다. 단일 가용성 구역의 내구성 목표는 99.999999999%입니다. 자세한 정보는 Block Storage for Classic의 가용성 및 내구성의 내용을 참조하십시오.

Block Storage for Classic의 평균 가동 시간은 얼마입니까?

Block Storage for Classic 에 데이터를 저장하면 내구성이 뛰어나고 가용성이 높으며 암호화되어 있습니다. Block Storage for Classic 는 동급 최고의 검증된 엔터프라이즈급 하드웨어와 소프트웨어를 기반으로 구축되어 높은 가용성과 가동 시간을 제공합니다. 가용성 목표인 99.999 %(9의 5개)를 충족하기 위해 데이터는 HA 페어링된 노드의 여러 물리적 디스크에 중복 저장됩니다. 각 스토리지 노드에는 자체 SSD(Solid-State Drive) 및 파트너 노드의 SSD에 대한 여러 경로가 있습니다. 이 구성은 경로 장애를 방지하고 노드가 여전히 파트너의 디스크에 원활하게 액세스할 수 있기 때문에 제어기 장애도 방지합니다. 자세한 정보는 Block Storage for Classic의 가용성 및 내구성의 내용을 참조하십시오.

내 OS에서 Block Storage for Classic 볼륨을 식별하려면 어떻게 해야 합니까?

컴퓨팅 호스트에서 첨부된 스토리지 볼륨의 LUN ID를 찾으려는 다양한 이유가 있습니다. 예를 들어, 동일한 호스트에 동일한 볼륨 크기로 마운트된 여러 스토리지 디바이스가 있을 수 있습니다. 이 중 하나를 분리하고 사용 중지하려고 합니다. 그러나 Linux® 호스트에 표시되는 내용과 콘솔에 표시되는 내용을 연관시키는 방법은 확실하지 않습니다. ESXi 서버에 연결된 여러 개의 Block Storage for Classic 볼륨이 있을 수 있습니다. 볼륨 중 하나의 볼륨 크기를 확장하려고 하는데, 이를 위해서는 스토리지의 올바른 LUN ID를 알아야 합니다. OS 특정 지시사항은 다음 링크 중 하나를 클릭하십시오.

지원팀으로부터 스토리지 성능 메트릭(IOPS 또는 지연 시간)을 받을 수 있나요?

IBM Cloud®은(는) 스토리지 성능 IOPS 및 대기 시간 메트릭을 제공하지 않습니다. 고객은 원하는 써드파티 모니터링 도구를 사용하여 Block Storage for Classic 디바이스를 모니터링해야 합니다.

다음은 성능 통계를 확인하는 데 사용할 수 있는 유틸리티의 예입니다.

  • sysstat- Linux® 운영 체제용 시스템 성능 분석 도구.
  • typeperf-성능 데이터를 명령 창 또는 로그 파일에 기록하는 Windows 명령입니다.
  • esxtop- VMware® vSphere 환경에서 자원 사용에 대한 실시간 정보를 관리자에게 제공하는 명령행 도구입니다. CPU, 메모리, 디스크, 네트워크 등 모든 시스템 리소스에 대한 데이터를 모니터링하고 수집할 수 있습니다.

복제본 볼륨, 종속 및 독립 중복 볼륨 간의 차이점은 무엇입니까?

볼륨의 스냅샷을 사용하여 복제본 또는 중복 볼륨을 작성할 수 있습니다. 복제 및 복제는 스냅샷 중 하나를 사용하여 데이터를 대상 볼륨에 복사합니다. 하지만, 그 점에서 유사성은 끝이 납니다.

복제는 서로 다른 두 위치에 동기화된 데이터를 보관합니다. 한 번에 한 쌍의 볼륨 (1차 볼륨 및 복제본 볼륨) 만 활성화할 수 있습니다. 복제 프로세스는 복제 스케줄에 따라 활성 볼륨에서 비활성 볼륨으로 정보를 자동으로 복사합니다. 복제본 볼륨에 대한 자세한 정보는 데이터 복제 를 참조하십시오.

중복은 상위 볼륨과 동일한 가용성 구역의 스냅샷을 기반으로 볼륨의 사본을 작성합니다. 복제 볼륨은 기본적으로 원래 볼륨의 용량 및 성능 옵션을 상속하며 스냅샷의 특정 시점까지의 데이터 사본을 보유합니다. 중복 볼륨은 원래 볼륨과 종속되거나 독립적일 수 있으며 상위 볼륨의 데이터로 수동으로 새로 고칠 수 있습니다. 상위 볼륨에 영향을 주지 않고 IOPS를 조정하거나 중복의 볼륨 크기를 늘릴 수 있습니다.

  • 종속 중복 볼륨은 독립적으로 되는 변환을 거치지 않으며 작성된 후 언제든지 새로 고칠 수 있습니다. 시스템은 종속 중복이 존재하는 동안 스냅샷을 삭제할 수 없도록 원래 스냅샷을 잠급니다. 종속 중복 볼륨이 있는 동안에는 상위 볼륨을 취소할 수 없습니다. 상위 볼륨을 취소하려면 먼저 종속 중복을 취소하거나 독립 중복으로 변환해야 합니다.

  • 독립 중복은 대부분의 경우 종속 중복보다 상위이지만, 긴 변환 프로세스로 인해 작성 후 즉시 새로 고칠 수 없습니다. 볼륨 크기에 따라 최대 몇 시간이 소요될 수 있습니다. 예를 들어, 12TB볼륨의 경우 최대 하루가 걸릴 수 있습니다. 그러나 분리 프로세스가 완료된 후에는 원래 상위 볼륨의 다른 스냅샷을 사용하여 데이터를 수동으로 새로 고칠 수 있습니다.

중복에 대한 자세한 정보는 중복 볼륨 작성 및 관리 를 참조하십시오.

다양한 유형의 볼륨 사본 간의 기능 비교.
이 표에는 행과 열 헤더가 있습니다. 행 헤더는 기능을 식별합니다. 컬럼 헤더는 볼륨 사본의 유형을 식별합니다.
기능 복제본 종속 중복 독립 복제
스냅샷에서 작성됨 체크표시 아이콘 체크표시 아이콘 체크표시 아이콘
복사된 볼륨의 위치 원격 가용성 구역 동일한 가용성 구역 동일한 가용성 구역
장애 조치 지원 체크표시 아이콘
다른 크기 및 IOPS 체크표시 아이콘 체크표시 아이콘
상위 볼륨과 자동 동기화됨 체크표시 아이콘
상위 볼륨에서 요청 시 새로 고치기 체크 표시 아이콘.[1] 체크 표시 아이콘.[2]
상위 볼륨에서 분리됨 체크표시 아이콘

종속 중복을 독립 볼륨으로 변환하는 데 걸리는 시간은 얼마나 걸립니까?

변환 프로세스를 완료하는 데 다소 시간이 걸릴 수 있습니다. 볼륨이 클수록 변환하는 데 시간이 더 오래 걸립니다. 12TB볼륨의 경우 24시간이 걸릴 수 있습니다. 콘솔이나 CLI에서 진행 상황을 확인할 수 있습니다.

  • UI에서 클래식 인프라로 이동하십시오. 스토리지 > Block Storage for Classic 를 클릭한 후 목록에서 볼륨을 찾으십시오. 변환 상태가 개요 페이지에 표시됩니다.

  • CLI에서 다음 명령을 사용합니다.

    slcli block duplicate-convert-status <dependent-vol-id>
    

    출력은 다음 예제와 유사하게 보입니다.

    slcli block duplicate-convert-status 370597202
    Username            Active Conversion Start Timestamp   Completed Percentage
    SL02SEVC307608_74   2022-06-13 14:59:17                 90
    

휴대용 스토리지에 대한 자세한 정보는 어디에서 찾을 수 있나요?

이동식 스토리지 볼륨(PSV)은 Virtual Servers에 대해 독점적으로 사용되는 보조 스토리지 솔루션입니다. 하나의 가상 서버에서 PSV를 분리하여 다른 가상 서버에 연결할 수 있습니다. 휴대용 스토리지 디스크를 한 번에 하나의 가상 서버에 연결할 수 있으며, 디스크에 저장된 모든 정보는 장치 간에 전송할 수 있도록 유지됩니다. 자세한 정보는 휴대용 SAN 스토리지를 참조하십시오.


  1. 종속 중복은 작성 후 즉시 새로 고칠 수 있습니다. ↩︎

  2. 분리 프로세스가 완료된 후 독립적인 중복을 새로 고칠 수 있습니다. ↩︎