como verificar se dois servidores são replicados corretamente no cluster ceph

Apenas no caso: Normalmente, a configuração de dois nós deve ser um ambiente de teste, não de produção. O cluster de dois nós é mais propenso a tais falhas que podem fazer você escolher o que vai perder: redundância ou tempo de atividade. Eles também podem incorrer em mais perda de dados, dependendo da configuração do pool.

Assumindo um cluster de dois nós, você deve criar pools para armazenar dados nele. Existem alguns padrões pré-configurados no ceph, um deles é o tamanho do pool padrão, que reflete o tamanho da replicação de seus dados. Um tamanho de pool de 3 (padrão) significa que você tem três cópias de cada objeto carregado no cluster (1 original e 2 réplicas). Você pode obter o tamanho da sua piscina com:

host1:~ # ceph osd pool get <POOL> size
size: 3
host1:~ # ceph osd pool get <POOL> min_size
min_size: 2

O parâmetro min_size determina o número mínimo de cópias em um pool e ainda pode ser operado. Por exemplo, se você tiver min_size e tamanho 3, seu cluster interromperá a E/S para esse pool se um objeto estiver em estado de erro. Se você tiver uma configuração como acima (min_size 2, size 3), seus dados serão processados ​​mesmo que uma cópia não esteja íntegra. No seu caso, você precisaria de um tamanho de pool de 2 e min_size de 1, exceto se você decidir permitir apenas gravações no pool se ele estiver íntegro; nesse caso, 2 e 2 são recomendados.

Agora, para validar se ambas as cópias estão vivas (além de um cluster no estado HEALTH_OK), você pode verificar o seguinte:

# Get PGs per pool
host1:~ # ceph pg ls-by-pool <POOL>
PG_STAT OBJECTS MISSING_ON_PRIMARY DEGRADED MISPLACED UNFOUND BYTES     LOG DISK_LOG STATE        STATE_STAMP                VERSION REPORTED  UP      UP_PRIMARY ACTING  ACTING_PRIMARY LAST_SCRUB SCRUB_STAMP                LAST_DEEP_SCRUB DEEP_SCRUB_STAMP           
3.0          24                  0        0         0       0 100663296  84       84 active+clean 2018-09-24 10:00:31.274193   86'84   182:119 [5,7,0]          5 [5,7,0]              5      86'84 2018-09-23 10:39:06.518211             0'0 2018-09-18 14:41:06.260403 
[...]

# Get mapping of a PG
host1:~ # ceph pg map 3.0
osdmap e182 pg 3.0 (3.0) -> up [5,7,0] acting [5,7,0]

Como você pode ver, este PG específico tem três cópias (tamanho = 3) nos OSDs 5, 7 e 0, e OSD.5 é o OSD primário, aquele que serve dados para o cliente.

Você construiu seu cluster no filestore ou no bluestore? Se você tiver um cluster de armazenamento de arquivos, poderá determinar a localização do arquivo de seus objetos no sistema de arquivos em seu servidor, consulte esta seção "Recuperar um objeto no cluster" para obter um exemplo de como recuperar essas informações, não tenho um cluster de armazenamento de arquivos em mãos agora. Em um cluster bluestore, isso não funcionará. Não é mais possível navegar pelos arquivos.