그리드의 크기가 초당 바이트 수로 표시된 처리량인 경우 이 사이징을 초당 S3 작업으로 변환하여 추정 공식을 사용해야 합니다. 그리드 처리량을 변환하려면 먼저 평균 개체 크기를 확인해야 합니다. 이 크기는 기존 감사 로그 및 메트릭의 정보(있는 경우)를 사용하거나 StorageGRID를 사용할 애플리케이션에 대한 지식을 사용하여 확인할 수 있습니다. 예를 들어, 그리드의 크기가 2,000 MB/s의 처리량을 달성할 수 있도록 조정되었고 평균 오브젝트 크기가 2MB인 경우, 그리드는 초당 1,000 S3 작업(2,000MB/2MB)을 처리할 수 있도록 크기가 조정되었습니다.

그리드에서 지원해야 하는 초당 S3 작업 수 이외의 S3 작업 부하에 대한 정보가 없는 경우 외부 syslog 서버가 다음 공식을 사용하여 처리해야 하는 감사 로그 볼륨을 예측할 수 있습니다. 감사 수준을 기본값으로 설정했다고 가정합니다(오류 로 설정된 스토리지를 제외한 모든 범주는 보통 으로 설정됨).

예를 들어, 그리드가 초당 1,000개의 S3 작업용으로 사이징된 경우 외부 syslog 서버는 초당 2,000개의 syslog 메시지를 지원하도록 크기를 조정해야 하며 초당 1.6MB의 속도로 감사 로그 데이터를 수신(일반적으로 저장)할 수 있어야 합니다.

당신이 당신의 업무량에 대해 더 알고 있다면, 더 정확한 예측들이 가능합니다. 감사 로그의 경우 가장 중요한 추가 변수는 다음 S3 필드의 값(GET 대비)과 평균 크기(바이트)입니다(표에 사용된 4자 약어는 감사 로그 필드 이름입니다).

P를 사용하여 S3 작업 중 위치, 0 ≤ P ≤ 1(100% put 워크로드, P=1 및 100% get 워크로드, P=0)의 비율을 표시하겠습니다.

K를 사용하여 S3 계정 이름, S3 버킷 및 S3 키의 합계에 대한 평균 크기를 나타내겠습니다. S3 계정 이름이 항상 -s3-계정(13바이트)이고, 버킷에는 /my/application/bucket-12345(28바이트)와 같은 고정 길이 이름이 있고, 오브젝트에는 5733a5d7-f069-411f-8fbd-13247494c69c(36바이트)와 같은 고정 길이 키가 있다고 가정해 보겠습니다. 그런 다음 K 값은 90(13+13+28+36)입니다.

P와 K의 값을 결정할 수 있는 경우 감사 수준을 기본값으로 설정했다는 가정 하에 외부 syslog 서버가 처리해야 하는 감사 로그 볼륨을 다음 공식을 사용하여 추정할 수 있습니다(스토리지를 제외한 모든 범주는 Normal로 설정됨). 오류 로 설정된 경우):

예를 들어, 그리드가 초당 1,000개의 S3 작업용으로 사이징된 경우, 작업 부하의 크기는 50%이고 S3 계정 이름, 버킷 이름은 개체 이름의 평균 90바이트는 외부 syslog 서버가 초당 1,500개의 syslog 메시지를 지원하도록 사이징되어야 하며, 일반적으로 초당 약 1MB의 속도로 감사 로그 데이터를 수신(및 저장)할 수 있어야 합니다.

감사 로그에 제공된 수식에서는 기본 감사 수준 설정(오류 로 설정된 스토리지를 제외한 모든 범주가 보통으로 설정됨)을 사용한다고 가정합니다. 기본값이 아닌 감사 수준 설정에 대한 감사 메시지의 비율 및 평균 크기를 추정하는 자세한 공식은 사용할 수 없습니다. 그러나 다음 표를 사용하여 요율을 대략적으로 추정할 수 있습니다. 감사 로그에 제공된 평균 크기 수식을 사용할 수 있지만 "추가" 감사 메시지는 평균적으로 기본 감사 메시지보다 작기 때문에 과대 평가로 이어질 수 있습니다.

보안 이벤트는 S3 운영과 관련이 없으며 일반적으로 최소한의 로그 및 데이터 볼륨을 생성합니다. 이러한 이유로 추정 공식은 제공되지 않습니다.

그리드에서 지원해야 하는 초당 S3 작업 수 이외의 S3 작업 부하에 대한 정보가 없는 경우 외부 syslog 서버에서 다음 공식을 사용하여 처리해야 하는 애플리케이션 로그 볼륨을 예측할 수 있습니다.

예를 들어, 그리드가 초당 1,000개의 S3 작업용으로 사이징된 경우 외부 syslog 서버는 초당 3,300개의 애플리케이션 로그를 지원할 수 있도록 사이징되어야 하고 초당 약 1.2MB의 속도로 애플리케이션 로그 데이터를 수신 및 저장할 수 있어야 합니다.

당신이 당신의 업무량에 대해 더 알고 있다면, 더 정확한 예측들이 가능합니다. 애플리케이션 로그의 경우 가장 중요한 추가 변수는 데이터 보호 전략(복제 대 삭제 코딩), S3 작업의 백분율(GET/기타) 및 평균 크기(바이트)입니다(표에서 사용되는 4자 약어는 감사 로그 필드 이름입니다).

P는 S3 작업의 비율을, 여기서 0 ≤ P ≤ 1(100% put 워크로드의 경우 P=1, 100% get 워크로드의 경우 P=0)을 나타냅니다.

K는 S3 계정 이름, S3 버킷 및 S3 키의 합계에 대한 평균 크기를 나타냅니다. S3 계정 이름이 항상 -s3-계정(13바이트)이고, 버킷에는 /my/application/bucket-12345(28바이트)와 같은 고정 길이 이름이 있고, 오브젝트에는 5733a5d7-f069-411f-8fbd-13247494c69c(36바이트)와 같은 고정 길이 키가 있다고 가정해 보겠습니다. 그런 다음 K의 값은 90(13+13+28+36)입니다.

P와 K의 값을 확인할 수 있는 경우, 외부 syslog 서버가 다음 공식을 사용하여 처리할 수 있어야 하는 애플리케이션 로그 볼륨을 예측할 수 있습니다.

예를 들어, 그리드가 초당 1,000개의 S3 작업에 맞게 사이징된 경우 작업 부하가 50%이고 S3 계정 이름, 버킷 이름 및 오브젝트 이름이 평균 90바이트인 경우, 외부 syslog 서버는 초당 1800개의 애플리케이션 로그를 지원하도록 크기여야 합니다. 그리고 애플리케이션 데이터를 초당 0.5MB의 속도로 수신(일반적으로 저장)할 것입니다.

P는 S3 작업의 비율을, 여기서 0 ≤ P ≤ 1(100% put 워크로드의 경우 P=1, 100% get 워크로드의 경우 P=0)을 나타냅니다.

K는 S3 계정 이름, S3 버킷 및 S3 키의 합계에 대한 평균 크기를 나타냅니다. S3 계정 이름이 항상 -s3-계정(13바이트)이고, 버킷에는 /my/application/bucket-12345(28바이트)와 같은 고정 길이 이름이 있고, 오브젝트에는 5733a5d7-f069-411f-8fbd-13247494c69c(36바이트)와 같은 고정 길이 키가 있다고 가정해 보겠습니다. 그런 다음 K의 값은 90(13+13+28+36)입니다.

P와 K의 값을 확인할 수 있는 경우, 외부 syslog 서버가 다음 공식을 사용하여 처리할 수 있어야 하는 애플리케이션 로그 볼륨을 예측할 수 있습니다.

예를 들어, 그리드가 초당 1,000개의 S3 작업에 대해 사이징된 경우 워크로드는 50%가 되고 S3 계정 이름, 버킷 이름 객체 이름은 평균 90바이트로, 외부 syslog 서버는 초당 2,250개의 애플리케이션 로그를 지원하도록 크기를 조정하고 초당 0.6MB의 속도로 애플리케이션 데이터를 수신(일반적으로 저장)할 수 있어야 합니다.