Estamos usando discos de 15 TB em nossos servidores RHEL 8.6 Linux. Esses discos são para o sistema de arquivos HDFS. Em comparação com outros discos, como 4 TB ou 8 TB, notamos alguma degradação nos logs do nó de dados. Verificamos vários aspectos para entender a diferença entre clusters Hadoop que usam discos de 4 TB ou 8 TB e o cluster Hadoop mais recente com discos de 16 TB. Após pesquisar no Google, notamos que o sistema de arquivos criado nos discos é ext4. Gostaria de saber se o ext4 pode ser usado em discos grandes, como 15 TB. Então, minha pergunta é: o ext4 suporta discos muito grandes, como 15 TB, ou é melhor usar o XFS em discos de 15 TB?
Primeiro, não estou usando IPv6 no meu servidor, e o IPv6 está sendo desabilitado.
Entretanto, se eu executar firewall-cmd --list-all-policies, posso ver que há uma política padrão chamada allow-host-ipv6.
O que ele realmente faz? Também não tenho ideia de onde vem essa política. Tenho quase certeza de que o /etc/firewalld/policies/diretório está vazio. Como posso me livrar dele?
# firewall-cmd --list-all-policies
allow-host-ipv6 (active)
priority: -15000
target: CONTINUE
ingress-zones: ANY
egress-zones: HOST
services:
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv6" icmp-type name="neighbour-advertisement" accept
rule family="ipv6" icmp-type name="neighbour-solicitation" accept
rule family="ipv6" icmp-type name="router-advertisement" accept
rule family="ipv6" icmp-type name="redirect" accept
Não tenho iotop, atop ou qualquer ferramenta que não seja Redhat no Redhat 7.9.
Existe uma maneira de investigar qual processo está consumindo todo o acesso ao disco rígido?
Não tenho o gnome instalado, então não tenho acesso à ferramenta monitor disponível com o gnome. Estou usando apenas o ssh e a ferramenta de linha de comando.
Usando o SAR, detectei que o SDA do disco rígido está 99% ocupado, mas não sei o porquê.
Tenho uma VM RHEL9 registrada e recentemente clonei uma cópia dela restaurando a partir do backup mais recente do Veeam.
Depois alterei o IP, o gateway, também /etc/hostso arquivo e regenerei /etc/machine-ido arquivo (também /var/lib/dbus/machine-id)
Então eu executei subscription-manager unregistere subscription-manager cleanem ambas as VMs. Também fiz login no console web do Redhat Hybrid Cloud Console para verificar se não há sistemas relevantes registrados.
Então eu executei subscrption-manager registerpara ambas as VMs, e esperava que houvesse duas novas entradas no Redhat Hybrid Cloud Console. No entanto, descobri que sempre há apenas uma entrada, e parece que as VMs estavam sobrescrevendo uma à outra.
Verifiquei se eles têm dois IPs, IDs de máquina e identidade de gerenciador de assinaturas diferentes, mas parece que quando tento registrar os dois, o Redhat os vê como o mesmo sistema.
Minha pergunta é: qual é a possível causa desse comportamento e como posso resolvê-lo corretamente?
2025-01-06 Atualização rápida:
Seguindo a resposta sugerida, tento atualizar o MAC Address, mas o Redhat parece ainda não conseguir dizer que são duas VMs diferentes. Abaixo está minha configuração atual da VM original e da VM restaurada.
- VM original:
Endereço IP e MAC
/etc/machine-id e /var/lib/dbus/machine-id
identidade do gerenciador de assinaturas
- VM restaurada:
Endereço IP e MAC
/etc/machine-id e /var/lib/dbus/machine-id
identidade do gerenciador de assinaturas
Tenho um servidor RHEL 7.9. Estou tentando criar uma conta local chamada sysadmin. Eu executei
useradd sysadminusermod -aG wheel sysadminpasswd sysadmin
Quando olho, /homevejo a pasta sysadmin, mas ela tem um proprietário diferente. O proprietário é uma conta de serviço que não está relacionada. Se eu executar chown sysadmin:sysadmin, ele não altera o proprietário, ele permanece a mesma conta de serviço. Não vejo nenhum log relacionado em secure ou messages. Não há /var/log/auth.logarquivos syslog ou syslog. Alguém viu esse comportamento?
Estou tentando entender como o systemd-journald e o rsyslog funcionam juntos. Os logs são armazenados em/var/logs? Faz
du -h /var/log/journal/
é suficiente para o que eu preciso?
Após atualizar alguns servidores de RHEL8 para RHEL9 usando o utilitário Leapp, há alguns avisos após a atualização em dnfe rpm: aviso: Assinatura não suportada. Algoritmo de hash SHA1 não disponível.
Toda vez que executei qualquer um desses comandos, recebi este aviso:
[root@web ~]# rpm -q kernel
warning: Signature not supported. Hash algorithm SHA1 not available.
warning: Signature not supported. Hash algorithm SHA1 not available.
kernel-5.14.0-362.18.1.el9_3.x86_64
kernel-5.14.0-427.18.1.el9_4.x86_64
kernel-5.14.0-427.20.1.el9_4.x86_64
[root@web ~]# dnf repolist
warning: Signature not supported. Hash algorithm SHA1 not available.
warning: Signature not supported. Hash algorithm SHA1 not available.
Updating Subscription Management repositories.
repo id repo name
rhel-9-for-x86_64-appstream-rpms Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs)
rhel-9-for-x86_64-baseos-rpms Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs)
Não sei de qual pacote ou o que desencadeia esse problema. A maioria das soluções disponíveis na web envolve reativar o SHA1, o que não é efetivamente uma solução.
Além disso, todos os pacotes estão marcados com, el9exceto alguns gpg-pubkeypacotes, então acho que não há nada do RHEL9 por aí.
[root@web ~]# rpm -qa | grep -v el9
warning: Signature not supported. Hash algorithm SHA1 not available.
warning: Signature not supported. Hash algorithm SHA1 not available.
gpg-pubkey-fd431d51-4ae0493b
gpg-pubkey-a14fe591-578876fd
gpg-pubkey-d4082792-5b32db75
Como posso rastrear o problema real para me livrar desses avisos?
Temos 8 servidores Cisco com 12 discos giratórios para dados e 2 SSDs para sistema operacional. Os 2 SSDs estão no software Linux RAID 1. Todos os SSDs têm seu indicador de desgaste em um dígito e alguns daqueles que atingiram o valor 1 falharam. Estou trocando todos eles pelas peças sobressalentes (um processo longo e cansativo), mas notei que o indicador de desgaste está caindo 1 ou 2% por semana (não fiz medições exatas). Há um único aplicativo em execução nesses servidores e o fornecedor me deu algumas ideias vagas, mas eu realmente preciso encontrar os diretórios nos quais ele está gravando. Dessa forma, posso realmente destacar o problema e pressionar o fornecedor para uma solução. Pesquisei um pouco, mas não consegui encontrar muito. iotop, por exemplo, mostra a taxa de transferência completa do disco, incluindo os 12 discos giratórios. O SO é Redhat 7.9
Em resposta a algumas das perguntas:
- os discos são "SSD SATA de 480 GB e 2,5 polegadas Enterprise Value 6 Gb"
- o ID do produto é "UCS-SD480GBKS4-EB"
- os discos foram fornecidos como padrão com os servidores em 2018
- O desgaste parece ter acelerado recentemente (agora estou registrando o desgaste, então terei uma resposta melhor sobre isso em alguns dias)
- Substituí a maioria dos discos por discos idênticos adquiridos talvez alguns anos depois.
- iotop está mostrando uma gravação constante de 8 MB/s.
- o sistema está executando o hadoop em 8 servidores. O sistema de arquivos hadoop está em discos giratórios, portanto não deve tocar nos SSDs
- Reduzi consideravelmente o IO do disco por sugestão do fornecedor, embora ainda pareça alto (8 MB/s)
Estamos executando uma loja Rocky Linux 8.9 (essencialmente RHEL 8.9) e recebi a tarefa de investigar ACLs em sistemas de arquivos montados via NFS. Também estamos usando FreeIPA/IdM.
Configurei uma máquina de teste, inscrevi-a no IdM, exportei um compartilhamento NFS e montei-a localmente, mas a parte ACL parece estar faltando:
[root@example ~]# cat /etc/exports
/export/ *(rw,acl,no_root_squash)
[root@example ~]# mount | grep /export
localhost:/export on /mnt type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,clientaddr=::1,local_lock=none,addr=::1)
[root@example ~]# cd /mnt/
[root@example mnt]# touch testfile
[root@example mnt]# getfacl testfile
# file: testfile
# owner: root
# group: root
user::rw-
group::r--
other::r--
[root@example mnt]# setfacl -m u:user:r testfile
setfacl: testfile: Operation not supported
Algumas perguntas:
- Foi entendido corretamente que eu deveria usar
getfaclesetfaclem vez de seus equivalentes nfs4_, já que tanto o cliente quanto o servidor são Linux/POSIX? - Eu preciso do idmapd? Eu tenho um serviço chamado nfs-idmapd em execução com sucesso.
- Li em algum lugar que
sec=sysdeveria ser substituídoseckrb5durante a montagem.
ATUALIZAR:
Investiguei um pouco mais e tive um pequeno avanço: nfsv4_set*aclfunciona bem no compartilhamento NFS, desde que se use UIDs ou GIDs numéricos. É o acoplamento à IdM/Kerberos que está causando problemas.
Eu tenho um servidor redhat 7.9 com cerca de 30 usuários, 64 núcleos e 512 Go de RAM. Eu tenho vários processos de zumbis, não sei exatamente o que o usuário criou para criá-los, mas tenho a sensação, depois de ler coisas na internet, que quando a sessão deles for encerrada, todos os zumbis serão mortos porque o processo "pai" será eliminado.
então vamos imaginar que se um usuário criar cerca de 30 zumbis durante sua sessão, eu poderia ter no máximo 900 processos de zumbis, é apenas uma aproximação porque quanto mais durar a sessão de um usuário, maior será o número do processo de zumbi. Preciso monitorar esse número para evitar falha no servidor ou algo assim?
Eu sei que processos zumbis não consomem nenhum recurso (RAM, CPU, etc.) mas também é uma evidência de que esse valor não pode ser superior a um limite...
Eu sei também que às vezes o usuário desconecta e os processos zumbis são limpos, então o número de processos zumbis pode diminuir ...