12.2. Crimson과 Classic Ceph OSD 아키텍처의 차이점

클래식 ceph-osd 아키텍처에서는 전달자 스레드가 OP 큐에 메시지를 배치하는 유선에서 클라이언트 메시지를 읽습니다. 그런 다음 osd-op thread-pool은 메시지를 선택하고 트랜잭션을 생성하고 현재 기본 ObjectStore 구현인 BlueStore에 대기열에 넣습니다. BlueStore의 kv_queue 는 이 트랜잭션과 큐의 다른 항목을 선택하고, 동시에 rocksdb 가 트랜잭션을 커밋할 때까지 기다린 다음 완료 콜백을 완료자 큐에 배치합니다. 그런 다음 완료자 스레드는 완료 콜백 및 큐를 선택하여 보낼 enger 스레드를 대체합니다.

이러한 각 작업에는 큐의 콘텐츠에 대한 스레드 간 협업이 필요합니다. pg 상태 의 경우 하나 이상의 스레드가 경합을 잠그려면 모든 PG의 내부 메타데이터에 액세스해야 할 수 있습니다.

프로세서 사용량이 증가한 이러한 잠금 경합은 작업 및 코어 수에 따라 빠르게 확장되며 모든 잠금 지점이 특정 시나리오에서 확장 병목 현상이 될 수 있습니다. 또한 이러한 잠금 및 큐는 조정되지 않은 경우에도 대기 시간 비용이 발생합니다. 이 대기 시간으로 인해 예약 유지 작업이 작업자 스레드와 잠금 간의 작업을 위임하면 컨텍스트가 강제될 수 있으므로 스레드 풀과 작업 대기열이 저하됩니다.

ceph-osd 아키텍처와 달리 Crimson은 컨텍스트 전환 없이 단일 I/O 작업을 완료할 수 있으며 기본 스토리지 작업에 필요하지 않은 경우 차단하지 않고 단일 I/O 작업을 완료할 수 있습니다. 그러나 일부 작업은 복구 또는 기본 장치와 같은 시스템의 상태에 따라 비동기 프로세스가 완료될 때까지 기다릴 수 있어야 합니다.

Crimson은 일반적으로 각 코어에 고정된 하나의 스레드를 사전 할당하는 고도의 비동기 엔진인 Seastar라는 C++ 프레임워크를 사용합니다. 이러한 분할 작업은 코어와 잠금 간에 상태를 분할할 수 있도록 코어 간에 분할되는 것을 방지할 수 있습니다. Seastar를 사용하면 대상 개체를 기반으로 한 스레드 그룹으로 I/O 작업이 분할됩니다. I/O 작업을 서로 다른 스레드 그룹으로 분할하는 대신 단일 스레드 내에서 모든 파이프라인 단계를 실행합니다. 작업을 차단해야 하는 경우 코어의 Seastar reactor가 다른 동시 작업으로 전환되고 진행됩니다.

이상적으로는 모든 잠금 및 context-switches는 실행 중인 비차단 작업이 완료되거나 공동으로 발생할 때까지 CPU를 소유하므로 더 이상 필요하지 않습니다. 다른 스레드가 동시에 작업을 선점할 수 없습니다. 데이터 경로의 다른 shard와의 통신이 필요하지 않은 경우 이상적인 성능은 I/O 장치가 제한에 도달할 때까지 코어 수와 함께 선형으로 확장됩니다. OSD 수준에서 PG shard 모든 IO가 있기 때문에 이 설계는 Ceph OSD에 적합합니다.

ceph-osd 와 달리crimson-osd 는 daemonize 옵션이 활성화된 경우에도 자체적으로 데몬링하지 않습니다. 지원되는 Linux 배포판 이후 crimson-osd 를 데몬화하지 마십시오. 이 경우 애플리케이션을 데몬화할 수 있는 systemd 를 사용합니다. sysvinit 에서는 start-stop-daemon 을 사용하여 crimson-osd 를 데몬화합니다.

Crimson에서 세 가지 ObjectStore 백엔드가 지원됩니다.

다음은 다른 두 가지 일반 OSD ObjectStore 백엔드입니다.