문제 해결

이 페이지에서는 Filestore 사용 시 문제가 발생할 경우 도움이 될 수 있는 문제 해결 단계를 보여줍니다.

느린 성능

  1. 클라이언트 VM에 권장 머신 유형을 사용 중인지 확인합니다.
  2. 클라이언트 VM이 Linux를 실행하는 경우 기본 마운트 옵션을 사용 중인지 확인합니다.

  3. 클라이언트 VM과 Filestore 인스턴스가 동일한 리전에 있는지 확인합니다. 리전 간에 마운트하면 성능이 저하될 뿐만 아니라 네트워킹 비용도 발생합니다.

  4. Filestore 인스턴스가 전체 용량에 도달했거나 거의 근접하지 않았는지 확인합니다. 용량이 거의 가득 차면 남은 공간이 심하게 조각나므로 읽기 및 쓰기 작업이 느려집니다. 이 시나리오를 방지하는 데 필요한 여유 공간 양은 경우에 따라 다릅니다. 디스크 공간 알림 부족을 설정하는 것이 좋습니다.

  5. fio 도구를 사용하여 Filestore 인스턴스의 성능을 테스트합니다.

    테스트 결과에 비정상적인 성능 저하가 나타나면 비즈니스 계정 담당자에게 문의하세요. 테스트 결과가 예상과 비슷하거나 더 나은 경우 다음 섹션을 계속 진행하세요.

성능 저하를 일으키는 사용 사례

다음은 성능 저하를 일으키는 몇 가지 사용 사례 및 시나리오입니다.

작은 파일이 대량 포함된 워크로드

Filestore 파일 공유는 데이터 안전 및 NFS 프로토콜 규정 준수를 위해 sync 내보내기 옵션을 사용합니다. 대부분의 데이터 수정 작업에 대해 Filestore 인스턴스는 데이터가 스토리지에 커밋될 때까지 기다린 후 클라이언트 VM의 요청에 회신합니다. 작업에 많은 파일이 관련되어 있으면 클라이언트에서 수행되는 동기 작업이 길어지고 누적 지연 시간이 추가됩니다.

이 시나리오의 예는 tar 파일과 같이 파일 공유에서 보관 파일을 추출하는 경우입니다. TAR은 많은 파일이 포함된 보관 파일을 추출할 때 여러 동기 작업을 연속으로 수행합니다. 이렇게 하면 성능이 저하됩니다.

많은 작은 파일을 파일 공유에 복사하려는 경우 gsutil과 같은 도구를 사용하여 파일을 동시에 생성해보세요.

mkdir -p /mnt/nfs/many_files_rsync/
time gsutil -m -q rsync -rp many_files /mnt/nfs/many_files_rsync/

Cloud Storage와 Filestore 간 데이터 복사

gsutil을 사용하여 Cloud Storage에서 Filestore 인스턴스로 데이터 복사하는 작업은 속도가 느린 것으로 알려져 있습니다. 알려진 해결 방법은 없습니다.

파일 공유 마운트 및 마운트 해제 시 지연 시간

기본 마운트 옵션을 사용하여 파일 공유를 마운트할 때 마운트 명령어가 지원되는 Filestore 인스턴스의 전송 방법을 검색하려 시도하므로 3초의 지연 시간이 발생합니다.

mountd 데몬은 먼저 Filestore가 지원하지 않는 UDP를 사용하여 시도합니다. 최초 시도 시간이 초과하면 TCP로 대체합니다. 이 검색 프로세스를 우회하고 추가적인 지연 시간을 없애기 위해서는 다음과 같이 tcp 마운트 옵션을 지정할 수 있습니다.

sudo mount -o tcp 10.0.0.2:/vol1 /mnt/nfs

이 마운트 옵션은 autofs로 자동 마운트할 때 특히 중요합니다.

Filestore가 응답하지 않음

Filestore 인스턴스가 ping 또는traceroute 요청에 응답하지 않음

Filestore는 ICMP를 허용하지 않으므로 Filestore 인스턴스는 ping 또는 traceroute 요청에 응답하지 않습니다.

Filestore 인스턴스에 대한 연결을 테스트하려면 클라이언트에서 showmount를 실행하면 됩니다.

sudo showmount -e filestore-ip

Filestore 인스턴스는 내보낸 파일 시스템을 통해 응답합니다. 예를 들면 다음과 같습니다.

Export list for 10.139.19.98:
/vol1 192.168.0.0/16,172.16.0.0/12,10.0.0.0/8

또한 다음을 실행하여 클라이언트가 Filestore의 RPC 정보에 도달할 수 있는지 확인할 수 있습니다.

sudo rpcinfo -p <filestore-ip>

응답은 다음과 같습니다.

program vers proto   port  service
 100000    4   tcp    111  portmapper
 100000    3   tcp    111  portmapper
 100000    2   tcp    111  portmapper
 100000    4   udp    111  portmapper
 100000    3   udp    111  portmapper
 100000    2   udp    111  portmapper
 100024    1   udp   2046  status
 100024    1   tcp   2046  status
 100003    3   tcp   2049  nfs
 100227    3   tcp   2049
 100021    1   udp   4045  nlockmgr
 100021    3   udp   4045  nlockmgr
 100021    4   udp   4045  nlockmgr
 100021    1   tcp   4045  nlockmgr
 100021    3   tcp   4045  nlockmgr
 100021    4   tcp   4045  nlockmgr
 100005    3   udp   2050  mountd
 100005    3   tcp   2050  mountd

예약된 유지보수

가끔 Filestore는 몇 분 동안 응답하지 않고 예약된 유지보수 이벤트로 인해 다시 응답합니다. Filestore SLA를 보려면 SLA 페이지를 참조하세요.

Filestore는 고객이 정의한 유지보수 기간을 지원하지 않습니다. Filestore의 유지보수 기간에 대한 일정도 고객에게 제공되지 않습니다.

클라이언트에 마운트되어 있는 동안 인스턴스가 삭제됨

파일 작업 또는 unix 명령어(예: df, ls) 또는 읽기/쓰기 작업이 응답하지 않는 경우 Filestore 인스턴스는 클라이언트에 마운트된 상태에서 삭제되었을 수 있습니다.

인스턴스가 존재하는지 확인합니다.

    gcloud filestore instances list

인스턴스가 더 이상 나열되지 않으면 삭제된 인스턴스와 동일한 IP 주소 및 파일 공유 이름을 사용하여 새 인스턴스를 만들어서 제어를 복구할 수 있습니다. 인스턴스가 생성된 다음에는 응답하지 않는 작업이 오류와 함께 종료됩니다. Filestore 인스턴스가 필요하지 않은 경우 파일 공유를 마운트 해제하고 삭제할 수 있습니다.

향후 이러한 일이 발생하지 않도록 하려면 먼저 Filestore 인스턴스를 마운트 해제한 다음 삭제하세요.

인스턴스에 REPAIRING 상태가 표시됨

Filestore 인스턴스가 사용자가 통제할 수 없는 내부 원인으로 인해 비정상 상태가 되며 자동으로 복구됩니다. 이 시간 동안에는 인스턴스를 사용할 수 없으며 추가 조치를 취할 필요가 없습니다.

용량 문제

'기기에 남은 공간 없음'

클라이언트 VM에서 다음 명령어를 실행하여 Filestore 인스턴스에 inode가 충분한지 확인합니다.

df -i

이 명령어는 다음과 비슷한 결과를 반환합니다.

Filesystem           Inodes        IUsed      IFree         IUse%  Mounted on
10.0.0.2:/vol1    134217728        13         134217715     1%     /mnt/test

파일 공유에 저장된 파일마다 inode 하나를 사용합니다. IUse%가 100%에 도달하면 할당된 최대 한도에 도달하지 않았더라도 파일 공유에 더 이상의 파일을 저장할 수 없습니다. inode 수는 용량에 따라 확장됩니다. inode를 추가하려면 용량을 추가해야 합니다.

'df' 명령어와 'du' 명령어는 서로 다른 여유 디스크 공간 보고

실행 중인 프로세스에 의해 열린 파일이 삭제되면 파일에서 사용하는 디스크 공간은 파일이 닫힐 때까지 해제되지 않습니다. df 명령어는 삭제된 열린 파일에서 사용한 공간을 사용하지만 du 명령어는 그렇지 않습니다. 이러한 계산 차이로 인해 du 명령어의 여유 공간이 df보다 많다고 표시되는 경우가 많습니다.

실행 중인 프로세스에 의해 아직 열려 있는 삭제된 파일을 표시하려면 다음을 실행합니다.

lsof | grep deleted

인스턴스를 만들 수 없음

Filestore 인스턴스를 만들 때 PERMISSION DENIED

  1. Filestore API가 사용 설정되었는지 확인합니다.

    gcloud services enable file.googleapis.com
    
  2. roles/file.editor 역할이 있는지 확인합니다. 자세한 내용은 IAM 역할 및 권한을 참조하세요.

  3. 오류가 계속 발생하면 Filestore 서비스 계정에서 file.serviceAgent 역할이 삭제되었을 수 있습니다. 이러한 경우인지 확인하려면 다음을 실행합니다.

    gcloud projects get-iam-policy project-id-or-number  \
        --flatten="bindings[].members" \
        --format='table(bindings.role)' \
        --filter="bindings.members:service-project-number@cloud-filer.iam.gserviceaccount.com"
    

    각 매개변수는 다음과 같습니다.

    • project-id-or-number는 Google Cloud 프로젝트의 ID 또는 번호입니다.
    • project-number는 Google Cloud 프로젝트의 번호입니다.

    이 명령어는 다음과 유사한 결과를 반환합니다.

    ROLE
    roles/file.serviceAgent
    

    roles/file.serviceAgent가 나열되지 않는 경우 다음을 실행하여 복원할 수 있습니다.

    gcloud projects add-iam-policy-binding project-id-or-number  \
        --member serviceAccount:service-project-number@cloud-filer.iam.gserviceaccount.com  \
        --role roles/file.serviceAgent
    

인스턴스를 만들 때 오류 코드 13 수신

인스턴스를 만드는 중에 오류 코드 13 오류가 발생하는 이유는 몇 가지가 있지만 가장 일반적인 원인은 Filestore가 내부 네트워크 할당량에 도달하는 것입니다.

Filestore 인스턴스를 만드는 모든 VPC 네트워크에서 Filestore는 네트워크와 피어링하는 내부 네트워크를 만들어야 합니다. 이러한 내부 네트워크는 Filestore 인스턴스 및 이와 연결된 VPC 네트워크가 삭제될 때에도 보존됩니다.

프로젝트의 내부 네트워크 수가 49개에 도달하면 Filestore는 더 이상 새 내부 네트워크를 만들 수 없으므로 새 VPC 네트워크에서 Filestore 인스턴스를 만들 수 없습니다. 그렇게 하면 오류가 발생합니다.

Error code 13, message: an internal error has occurred

내부 네트워크를 지울 수 있는 유일한 방법은 Filestore API를 사용 중지한 후 다시 사용 설정하는 것입니다. API를 사용 중지할 수 없기 전에 Filestore와 관련된 모든 Filestore 관련 리소스(예: Filestore 인스턴스 및 백업)를 삭제해야 합니다.

gcloud services disable file.googleapis.com

gcloud services enable file.googleapis.com

필요하고 삭제할 수 없는 Filestore 인스턴스가 있기 때문에 API를 사용 중지할 수 없는 경우 비즈니스 계정 담당자에게 연락하여 피어링된 네트워크를 수동으로 지워야 합니다.

VPC 네트워크 및 Filestore 인스턴스를 정기적으로 삭제하고 만들어야 하는 경우, 네트워크 할당량 부족을 피할 수 있는 두 가지 방법이 있습니다.

  • VPC 네트워크를 만들 때 이전 네트워크에서 Filestore 인스턴스 생성에 사용된 것과 동일한 이름을 사용합니다.

  • 삭제 후 다시 만드는 대신 VPC 네트워크 49개 이내에서 풀을 순환합니다.

파일 공유를 마운트할 수 없음

VM 또는 GKE pod가 Filestore에 액세스할 수 없음

다음을 실행하여 Filestore 인스턴스에 연결할 수 있는지 확인합니다(pingtraceroute은 지원되지 않음).

sudo showmount -e <filestore-ip>

이 명령어는 내보낸 파일 시스템 목록으로 응답해야 합니다. 그런 다음 다음을 실행하여 클라이언트가 Filestore의 RPC 정보에 도달할 수 있는지 확인합니다.

sudo rpcinfo -p <filestore-ip>

Filestore 인스턴스가 연결할 수 없는 경우 일반적인 원인으로는 네트워크 설정이나 ACL 설정을 잘못 구성했거나 잘못된 인스턴스를 마운트하려고 하는 경우가 해당됩니다.

  1. IP 기반 액세스 제어가 사용 설정되어 있는지 확인하고 클라이언트의 IP 주소가 제한되어 있는지 확인합니다. 자세한 내용은 여기를 참조하세요.
  2. 방화벽 설정을 확인하여 필요한 포트가 열려 있는지 확인합니다. 자세한 내용은 방화벽 규칙 구성을 참조하세요.
  3. GKE 클러스터에서 Filestore에 액세스하려고 하지만 mount.nfs: access denied by server while mounting ... 오류가 발생하면 GKE 클러스터에서 파일 공유에 액세스할 수 없음을 참조하세요.

파일 공유를 마운트하려고 시도할 때 권한이 거부됨

인스턴스에 대해 NFS 내보내기 옵션이 나열되었는지 확인합니다.

gcloud filestore instances describe instance-id \
    --zone=zone

각 항목의 의미는 다음과 같습니다.

  • instance-id는 Filestore의 인스턴스 ID입니다.
  • zone은 Filestore 인스턴스가 있는 영역입니다.

이 명령어는 다음과 비슷한 결과를 반환합니다.

createTime: '2019-10-11T17:28:23.340943077Z'
fileShares:
- capacityGb: '1024'
  name: vol1
  nfsExportOptions:
  - accessMode: READ_WRITE
    ipRanges:
    - 128.0.0.0/29
    squashMode: NO_ROOT_SQUASH
name: projects/yourproject/locations/us-central1-c/instances/nfs-server
networks:
- ipAddresses:
  - 10.0.0.2
  modes:
  - MODE_IPV4
  network: default
  reservedIpRange: 10.0.0.0/29
state: READY
tier: BASIC_HDD

nfsExportOptions가 나열된 경우 클라이언트의 IP 주소가 필요한 accessMode에 대해 ipRanges 아래에 나열된 범위 중 하나에 포함되는지 확인합니다. 그렇지 않으면 NFS 내보내기 옵션을 수정해야 합니다.

App Engine에 파일 공유를 마운트할 수 없음

Filestore는 App Engine을 지원하지 않습니다.

GKE 클러스터에서 파일 공유를 마운트할 수 없음

Filestore 파일 공유를 GKE 클러스터에 직접 마운트할 수 없습니다. 대신 PV 및 PVC를 구성해야 합니다.

GKE 클러스터에서 파일 공유에 액세스할 수 없음

Kubernetes 또는 Google Kubernetes Engine 관련 문제 해결에 대한 자세한 내용은 공식 Kubernetes 문제 해결 가이드GKE 문제 해결 가이드도 참조하세요.

오류: 출력: x.x.x.x:/file-share-name을 마운트하는 동안 서버에서 액세스가 거부되었습니다.

PV spec.nfs.pathspec.nfs.server의 값이 각각 파일 공유의 이름과 Filestore 인스턴스의 IP 주소와 일치하는지 확인합니다.

예:

파일 공유 이름이 vol1이고 Filestore 인스턴스의 IP 주소가 10.0.0.2이면 PV spec.nfs.pathspec.nfs.server는 다음 값과 일치해야 합니다.

apiVersion: v1
kind: PersistentVolume
metadata:
 name: fileserver
spec:
 capacity:
   storage: 2T
 accessModes:
 - ReadWriteMany
 nfs:
   path: /vol1
   server: 10.0.0.2

Filestore API를 사용 중지할 수 없음

Filestore 인스턴스 및 백업과 같은 모든 Filestore 관련 리소스가 삭제되었는지 확인합니다. Filestore 인스턴스가 배포되는 동안에는 Filestore API를 중지할 수 없습니다.

오류: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges.

특정 비공개 연결에 할당된 IP 주소 공간이 소진된 경우 Google Cloud가 Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. 오류를 반환합니다.

이 문제를 해결하는 방법에 대한 자세한 내용은 IP 주소 범위 소진을 참조하세요.