하드웨어 요구 사항

하드웨어 요구사항:
ceph는 상품 하드웨어에서 설계하고 운행함으로써 PB 등급의 집단을 구축하고 유지하는 것이 경제적으로 가능하다.집단 하드웨어를 선택할 계획을 세울 때 고장 영역과 잠재적인 성능 문제를 포함한 일련의 조건을 균형 있게 해야 한다.하드웨어 계획은 분포식의ceph프로세스와 다른ceph프로세스를 사용하는 호스트를 포함합니다.

CPU

CPU
ceph 메타데이터 서버는 동적 부하를 조정하여 CPU 집약 응용에 속한다.따라서 메타데이터 서버는 계산 능력이 비교적 강해야 한다(쿼드 코어 또는 더 강한 CPU).Ceph OSD 노드에서 RADOS 서비스를 실행하려면 CRUSH를 사용하여 데이터 저장 위치를 계산하고 데이터를 복제하며 그룹맵 정보를 유지해야 합니다.따라서 OSD 노드에는 듀얼 코어 CPU와 같은 합리적인 컴퓨팅 리소스가 필요합니다.모니터는 주로 집단 맵을 유지하고 CPU 밀집 응용에 속하지 않는다.현재 호스트가 다른 CPU 집약형 응용 프로그램을 실행하는 것도 고려해야 한다. 예를 들어 VM의 계산 노드(nova).다른 호스트에서ceph 이외의 CPU 밀집 응용 프로그램을 실행하는 것을 권장합니다.
ceph 메타데이터 서비스: 4core 이상;OSD: 2 core 이상

RAM

RAM:
메타데이터 서버와 모니터는 데이터를 신속하게 검색할 수 있는 능력이 필요하기 때문에 더 많은 메모리가 필요합니다.OSD 노드는 이렇게 많은 메모리를 필요로 하지 않지만 데이터 복구 기간에 더 많은 메모리가 필요합니다. (프로세스당 1T 데이터는 1G 메모리가 필요합니다.)전체적으로 말하면 메모리가 클수록 좋다.
ceph 메타데이터 서비스,monitors: 실례당 1G OSD: 실례당 500M이지만 복구 기간에 메모리가 많이 필요합니다.

DATA STORAGE

데이터 스토리지:
스토리지를 조심스럽게 구성해야 합니다.이것은 비용과 성능 사이에서 따져야 한다.동시에 실행되는 운영체제와 서로 다른 프로세스가 동시에 읽기와 쓰기를 하는 것은 한 디스크의 성능에 불리하다.여기에서도 파일 시스템의 제한을 고려해야 한다. btrfs는 생산 환경에서 충분히 안정적이지 않지만, xfs와 ext4가 갖추지 못한 로그와 동시에 쓰는 능력을 가지고 있다.
중요: ceph는 쓰기를 확인하기 전에 로그journal(xfs, ext4)에 데이터를 쓰기 때문에 로그와 OSD 성능의 균형이 매우 중요하다
하드 드라이브:
OSD는 데이터를 저장하기 위해 큰 하드디스크가 필요합니다.ceph 권장 하드디스크 크기는 1T 이상입니다.단일 하드 드라이브의 크기는 GB당 비용과 관계가 있기 때문에 균형을 잡아야 한다.큰 하드디스크일수록 단일ceph OSD 프로세스에 필요한 메모리도 크다. 특히 재부하 균형, 메우기, 복구할 때.간단한 규칙으로 1TB 스토리지의 경우 일반적으로 1G RAM이 필요합니다.
알림: 같은 하드디스크의 다른 구역에서 여러 개의 OSD 실례를 실행하는 것을 권장하지 않습니다.같은 하드디스크의 다른 구역에서 OSD와 모니터나 메타데이터 서비스를 실행하는 것을 권장하지 않습니다
하드디스크는 검색 시간(seek time), 접근 시간(access time), 읽기와 쓰기 시간(read and write times), 흡수량(total throughput)에 제한을 받는다.이러한 물리적 제한은 전체 시스템의 성능, 특히 회복할 때 영향을 줄 수 있다.운영 체제와 소프트웨어를 설치하는 데 전용 디스크를 사용하고 각 디스크마다 OSD 프로세스를 설정하는 것이 좋습니다.많은 osd가 느린 문제는 한 디스크에서 시스템, OSD 실례와 로그를 실행하기 때문이다.소규모 그룹에서 성능 문제를 검사하는 비용은 추가 디스크의 비용보다 많기 때문에 그룹을 설계할 때 OSD 디스크의 과부하를 최대한 피해야 한다.
동일한 디스크에서 여러 OSD 프로세스를 실행하면 리소스 경합이 발생하고 총 처리량이 감소할 수 있습니다.마찬가지로 같은 디스크에 로그와 데이터 대상을 저장하면 로그를 쓰는 데 더 많은 시간이 걸리고 ACK를 클라이언트로 되돌릴 수 있습니다.ceph는 로그를 다 쓴 후에야 쓰기 완료를 확인해야 합니다.btrfs는 로그와 데이터를 동시에 쓸 수 있지만 xfs, ext4는 안 됩니다.
ceph의 가장 좋은 건의는 운영 체제, OSD 데이터 디스크, OSD 로그 디스크를 다른 디스크에 실행하는 것이다.
SSD
성능을 개선할 수 있는 기회는 무작위 접근 시간을 줄이고 읽기 대기 시간을 줄여 삼키기를 향상시키는 것이다.SSD는 GB당 하드 드라이브보다 약 10배의 비용이 들지만 성능은 100배나 향상됩니다.
SSD는 기계적 구조가 없기 때문에 기계 하드디스크와 제한 요소가 다르다.SSD에도 한계가 있습니다.SSD를 평가할 때 중요한 성능 요인 중 하나는 순서대로 읽고 쓰는 것이다.여러 개의 SSD가 여러 OSD의 로그로 사용될 때 400MB/S 순서로 작성된 SSD는 120MB/S 순서로 읽기와 쓰기가 가능한 SSD보다 성능 표현이 좋습니다.
중요: SSD를 사용하여 성능을 향상시키는 것이 좋습니다.그러나 SSD에 많은 비용이 들어가기 전에 SSD의 성능 지표를 평가하고 테스트 시 SSD를 설정하여 성능을 테스트하는 것을 강력히 권장합니다.
SSD는 물리적 구조가 없기 때문에ceph에서 대량의 데이터 (예를 들어 로그 저장) 를 저장하는 데 사용되지 않습니다.비교적 저렴한 SSD를 사용하면 비교적 많은 비용을 절약할 수 있다.그러나 ceph에서 IOPS만 고려할 때 부족하다는 것을 주의해야 한다.다음은 로그와 SSD에 대한 성능 고려 지표의 일부입니다.

쓰기 집약형(Write-intensive semantics): 로그는 집약형 쓰기를 포함하기 때문에 배치된 SSD는 데이터를 쓰는 데 있어서 디스크보다 같거나 우수해야 합니다.저렴한 SSD는 읽기 시간을 단축할 수 있지만 쓰기 지연을 증가시킬 수 있습니다. 왜냐하면 고성능 하드 드라이브가 일부 저렴한 SSD보다 쓰기 성능이 좋을 수 있기 때문입니다

순서 쓰기(Sequential Writes): 같은 SSD에 여러 개의 로그를 저장할 때, 여러 개의 로그를 동시에 쓸 수 있기 때문에 SSD의 순서 읽기와 쓰기 제한을 고려해야 합니다

파티션 정렬(Partition Alignment): 일반적인 성능 문제는 사람들이 SSD에서 파티션을 나누기 때문이다. 그러나 그들은 항상 정확한 파티션 정렬을 소홀히 하여 SSD의 성능을 떨어뜨린다.SSD의 파티션이 올바른지 확인..

SSD는 대상 저장에 비용이 많이 들지만 OSD의 로그를 작성하여 하나의 SSD에 데이터를 하드디스크에 저장함으로써 OSDs의 성능을 뚜렷하게 향상시킬 수 있다.osdjournal 설정은 기본적으로/var/lib/ceph/osd/$cluster-$id/journal입니다.이 경로 아래에 SSD나 SSD 구역을 마운트할 수 있습니다.
CephFS 파일 시스템을 향상시키는 방법은 CephFS metadata와 CephFS 파일 내용을 분리하는 것이다.Ceph는 CephFS metadata를 저장하기 위한 기본 metadata 풀을 제공합니다.CephFS metadata를 위한 풀을 만들 필요는 없지만, CephFS metadata를 위한 CURSH 맵을 만들어서 SSD에 저장할 수 있습니다.
컨트롤러
디스크 컨트롤러는 쓰기 삼키기에도 큰 영향을 미친다.디스크 컨트롤러를 선택할 때 컨트롤러가 성능 병목을 일으키지 않도록 해야 한다.
별도의 고려
각 노드에서 여러 개의 OSDs를 실행할 수 있지만, 클라이언트에게 읽기와 쓰기를 제공하는 네트워크 대역폭을 초과하지 않도록 해야 합니다.너도 모든 노드가 저장할 수 있는 공간을 고려해야 한다.만약에 어떤 노드의 공간이 매우 넓으면 이 노드가 오프라인 상태가 되면 그룹이fullratio의 제한을 초과하여ceph가 데이터를 잃어버릴 수 있습니다.
각 노드가 여러 개의 OSDs를 실행할 때, 코어가 최신이라는 것을 보증해야 한다.OS 요구 사항을 보십시오. glibc와syncfs에 대한 요구는 하드웨어 성능이 기대에 도달할 수 있도록 합니다.
호스트에 많은 수의 OSD(예: 20 이상)가 있으면 특히 복구와 균형 과정에서 대량의 프로세스가 발생할 수 있습니다.많은 Linux 호스트의 기본 제한 프로세스 수는 32k와 같은 작은 값입니다.만약 당신이 OSD를 시작할 때 문제가 필요하다면kernel을 설정하는 것을 고려할 수 있습니다.pid_max에서 비교적 큰 값으로.이론의 최대치는 4194303이다.너는/etc/sysctl에 있을 수 있다.conf 다음 구성 추가:

kernel.pid_max=4194303

NETWORKS

인터넷
노드당 최소 2개의 1G NIC가 필요합니다.대부분의 상업용 하드디스크는 대략 100MB/s의 삼키기 때문에, 네트워크 카드는 충분한 대역폭을 제공할 수 있어야 한다.우리는 퍼블릭 네트워크와cluster 네트워크를 탑재하기 위해 최소 두 개의 네트워크 카드를 요구합니다.하나의 집단 네트워크 (cluster 네트워크, 인터넷에 연결할 필요가 없음) 는 추가 부하를 싣고 데이터 복제를 진행하며 다른 요소가 집단 pg 상태를 active+clean 상태로 유지하는 것을 막는다.10G NIC 사용을 고려하다.1G NIC를 통해 1TB 데이터를 복제하는 데 3시간, 3TB는 9시간 걸릴 수 있습니다.상대적으로 10G NIC를 사용할 경우 복제에 걸리는 시간은 20분과 1시간입니다.PB 수준의 클러스터에서 OSD 디스크의 이상이 정상입니다.시스템 관리자는 가능한 한 빨리 degraded 상태에서active+clean 상태로 가기를 기대합니다.또한 많은 배포 도구(Dell Crowbar)가 5개의 서로 다른 네트워크를 배치하여 VLAN을 사용하여 네트워크를 더욱 잘 관리할 수 있습니다.VLAN은 802.1q 프로토콜을 사용할 수 있도록 NIC와 스위치를 요구합니다.VLANS를 사용하여 VM 네트워크 및 스토리지 클러스터 네트워크를 실행할 때 (예: OpenStack) 10G NIC 사용을 고려해야 합니다.핵심 스위치는 40Gbps 또는 100Gbps를 사용하는 스위치와 같은 더 나은 병합이 필요합니다.
하드웨어 서버에는 BMC(Baseboard Management Controller)가 필요합니다.관리 및 배포에 BMC가 필요할 수 있습니다.

FAILURE DOMAINS

실효역
하나의 실효역은 임의로 하나 이상의 osd에 접근하는 것을 막을 수 있습니다.이것은 정지된 프로세스일 수 있다.손상된 하드 드라이브시스템 붕괴;고장난 네트워크 카드;전원 실효;네트워크 중단;전원 공급 장치 중단 등.하드웨어를 계획할 때, 하드웨어가 증가하는 비용과 실효역을 균형 있게 해야 한다.

MINIMUM HARDWARE RECOMMENDATIONS