pgoetz's questions

Para ambas as máquinas:

• Ubuntu 20.04
• Placas Mellanox MT28908 ConnectX-6 em modo ethernet
• Módulo do kernel: mlx5_core (de MLNX_OFED_LINUX-24.04-0.6.6.0-ubuntu20.04-x86_64)

As placas ConnectX-6 são conectadas diretamente umas às outras usando um DAC Nvidia usando endereços RFC1918; ou seja, uma pequena rede de 2 nós. As máquinas são sistemas de montagem em rack de nível de servidor, com uma tendo uma CPU Intel Xeon Gold 5318Y e a outra 2 CPUs Intel Xeon Platinum 8358. Essas placas devem fornecer conectividade de 100 Gb/s. No entanto

root@zakynthos:~# iperf3 -c 192.168.101.1
Connecting to host 192.168.101.1, port 5201
[  5] local 192.168.101.2 port 45974 connected to 192.168.101.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  3.17 GBytes  27.2 Gbits/sec  227    912 KBytes       
[  5]   1.00-2.00   sec  2.58 GBytes  22.1 Gbits/sec  1382    755 KBytes       
[  5]   2.00-3.00   sec  2.36 GBytes  20.3 Gbits/sec  2459   1.08 MBytes       
[  5]   3.00-4.00   sec  3.07 GBytes  26.4 Gbits/sec  3433    723 KBytes       
[  5]   4.00-5.00   sec  3.36 GBytes  28.9 Gbits/sec  3004   1.05 MBytes       
[  5]   5.00-6.00   sec  2.83 GBytes  24.3 Gbits/sec  1692    942 KBytes       
[  5]   6.00-7.00   sec  2.47 GBytes  21.2 Gbits/sec  1819   1022 KBytes       
[  5]   7.00-8.00   sec  3.03 GBytes  26.0 Gbits/sec  1578    841 KBytes       
[  5]   8.00-9.00   sec  3.37 GBytes  28.9 Gbits/sec  1920   1024 KBytes       
[  5]   9.00-10.00  sec  2.91 GBytes  25.0 Gbits/sec  1239   1.06 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  29.1 GBytes  25.0 Gbits/sec  18753             sender
[  5]   0.00-10.04  sec  29.1 GBytes  24.9 Gbits/sec                  receiver

Estou acostumado a ver o iperf3 entregar cerca de 90% da largura de banda nominal para uma placa, então para mim isso parece terrível e inaceitável. Alguém tem alguma ideia de por que não estou vendo pelo menos 80-90 Gb/s de desempenho aqui?

Eu tenho um sistema de backup Arch linux ZFS que não foi atualizado por um longo tempo porque estava funcionando perfeitamente e não havia motivo para se preocupar. Após uma atualização recente, porém, meus conjuntos de dados ZFS não são mais montados automaticamente quando eu reinicio. Infelizmente, os serviços não indicam nenhuma mensagem de erro e posso executar

# zfs mount -a

após o sistema ser inicializado sem problemas. Alguns detalhes:

[root@elephant etc]# uname -a
Linux elephant 4.16.11-1-ARCH #1 SMP PREEMPT Tue May 22 21:40:27 UTC 2018 x86_64 GNU/Linux
[root@elephant etc]# pacman -Q | grep spl
spl-dkms 0.7.9-1
spl-utils 0.7.9-1
[root@elephant etc]# pacman -Q | grep zfs
zfs-dkms 0.7.9-1
zfs-utils 0.7.9-1

root@elephant etc]# zfs get mountpoint backup/www
NAME                              PROPERTY    VALUE                              SOURCE
backup/www  mountpoint  /backup/www  default
[root@elephant etc]# zfs get mountpoint backup/data
NAME                               PROPERTY    VALUE                               SOURCE
backup/data  mountpoint  /backup/data  default
[root@elephant etc]# zfs get mountpoint backup/metadata
NAME             PROPERTY    VALUE             SOURCE
backup/metadata  mountpoint  /backup/metadata  default

Observe em particular que o serviço zfs-mount parece estar perfeitamente satisfeito:

[root@elephant ~]# systemctl -l status zfs*
● zfs.target - ZFS startup target
   Loaded: loaded (/usr/lib/systemd/system/zfs.target; enabled; vendor preset: enabled)
   Active: active since Mon 2018-05-28 15:30:18 CDT; 1min 32s ago

May 28 15:30:18 elephant systemd[1]: Reached target ZFS startup target.

● zfs-import-cache.service - Import ZFS pools by cache file
   Loaded: loaded (/usr/lib/systemd/system/zfs-import-cache.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mon 2018-05-28 15:30:18 CDT; 1min 32s ago
  Process: 659 ExecStart=/usr/bin/zpool import -c /etc/zfs/zpool.cache -aN (code=exited, status=0/SUCCESS)
  Process: 656 ExecStartPre=/sbin/modprobe zfs (code=exited, status=0/SUCCESS)
 Main PID: 659 (code=exited, status=0/SUCCESS)

May 28 15:30:12 elephant systemd[1]: Starting Import ZFS pools by cache file...
May 28 15:30:18 elephant systemd[1]: Started Import ZFS pools by cache file.

● zfs-zed.service - ZFS Event Daemon (zed)
   Loaded: loaded (/usr/lib/systemd/system/zfs-zed.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2018-05-28 15:30:18 CDT; 1min 32s ago
     Docs: man:zed(8)
 Main PID: 1586 (zed)
    Tasks: 3 (limit: 4915)
   Memory: 5.6M
   CGroup: /system.slice/zfs-zed.service
           └─1586 /usr/bin/zed -F

May 28 15:30:18 elephant systemd[1]: Started ZFS Event Daemon (zed).
May 28 15:30:18 elephant zed[1586]: ZFS Event Daemon 0.7.9-1 (PID 1586)
May 28 15:30:18 elephant zed[1586]: Processing events since eid=0
May 28 15:30:18 elephant zed[1591]: eid=1 class=history_event pool_guid=0x7314E37F1A1C0088
May 28 15:30:18 elephant zed[1593]: eid=2 class=config_sync pool_guid=0x7314E37F1A1C0088
May 28 15:30:18 elephant zed[1595]: eid=3 class=pool_import pool_guid=0x7314E37F1A1C0088
May 28 15:30:18 elephant zed[1618]: eid=5 class=config_sync pool_guid=0x7314E37F1A1C0088

● zfs-mount.service - Mount ZFS filesystems
   Loaded: loaded (/usr/lib/systemd/system/zfs-mount.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mon 2018-05-28 15:30:12 CDT; 1min 38s ago
  Process: 657 ExecStart=/usr/bin/zfs mount -a (code=exited, status=0/SUCCESS)
 Main PID: 657 (code=exited, status=0/SUCCESS)

May 28 15:30:12 elephant systemd[1]: Starting Mount ZFS filesystems...
May 28 15:30:12 elephant systemd[1]: Started Mount ZFS filesystems.
[root@elephant ~]#

No entanto:

[root@elephant ~]# zfs mount
[root@elephant ~]# 
[root@elephant ~]# zfs mount -a
[root@elephant ~]# zfs mount
backup                          /backup
backup/data  /backup/data
backup/metadata                 /backup/metadata
backup/www  /backup/www

Estou sem tempo disponível para lidar com isso e vou mudar todos os conjuntos de dados para a montagem herdada, mas ainda estou curioso por que isso funcionou para o zfs 0.6.x, mas não está funcionando para o 0.7.9 - - possivelmente algum tipo de incompatibilidade do systemd?

Este problema está basicamente me deixando louco, neste momento. Eu tenho um servidor Ubuntu 16.04 NFS que estava funcionando bem com esta configuração:

/etc/fstab:
UUID=b6bd34a3-f5af-4463-a515-be0b0b583f98  /data2  xfs  rw,relatime  0  0
/data2  /srv/nfs/cryodata    none    defaults,bind    0  0
/usr/local       /srv/nfs/local    none    defaults,bind    0  0

e

/etc/exports
/srv/nfs  192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata  192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local      192.168.159.31(rw,sync,no_subtree_check)

Tudo isso tem funcionado bem por meses no cliente nfs usando esta configuração até agora usando estas entradas /etc/fstab do lado do cliente:

kraken.bio.univ.edu:/local  /usr/local  nfs4  _netdev,auto  0  0
kraken.bio.univ.edu:/cryodata  /cryodata  nfs4  _netdev,auto  0  0

No entanto, como este é um servidor de armazenamento muito grande, foi decidido que ele precisa acomodar vários laboratórios. Então, movi todas as coisas que estavam espalhadas pela partição /data2 para um subdiretório /data2/cryodata e atualizei /etc/fstab no servidor e /etc/exports da seguinte forma:

/etc/fstab:
...
/data2/cryodata  /srv/nfs/cryodata    none    defaults,bind    0  0
/data2/xray      /srv/nfs/xray    none    defaults,bind    0  0
/data2/EM        /srv/nfs/EM    none    defaults,bind    0  0
/usr/local       /srv/nfs/local    none    defaults,bind    0  0

e

/etc/exports
/srv/nfs  192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata  192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/EM  192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/xray  192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local  192.168.159.31(rw,sync,no_subtree_check)

Isso simplesmente não funciona! Quando tento montar a nova montagem no cliente usando a mesma entrada /etc/fstab do cliente:

{nfs client} /etc/fstab:
...
kraken.bio.univ.edu:/local  /usr/local  nfs4  _netdev,auto  0  0
kraken.bio.univ.edu:/cryodata  /cryodata  nfs4  _netdev,auto  0  0

.

# mount -v /cryodata
mount.nfs4: timeout set for Sat Feb 24 09:24:38 2018
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=128.83.41.171,clientaddr=129.116.159.31'
...

O /usr/local continua a ser montado sem problemas. A primeira vez que tentei isso, esqueci de desexportar/exportar os sistemas de arquivos usando exportfs -varantes de fazer alterações, mas desde então mudei para frente e para trás, tomando cuidado para desexportar e desmontar tudo, com várias reinicializações de servidor no meio. A montagem original de uma montagem de ligação de toda a partição sempre funciona, e a montagem de ligação de um subdiretório falha com a mensagem de manipulação nfs obsoleta todas as vezes. Eu tentei habilitar outros clientes nfs que nunca montaram essas partições e obtive exatamente a mesma mensagem de erro: neste caso, é definitivamente um problema do lado do servidor. Eu verifiquei /var/lib/nfs/etab para ter certeza de que está limpo entre tentativas de montagem, etc.

Eu pensei que a técnica de montagem de ligação em um diretório raiz do servidor nfs resolveu todos esses tipos de problemas, mas aparentemente não? O estranho é que /usr/local é um subdiretório de outra partição e sempre monta bem. Está em um ext3 md raid 1, embora eu não consiga imaginar que isso importe.

Passei horas nisso e quase quebrei o google procurando uma solução sem sucesso.

Estou tentando instalar a função RDS em um servidor Windows 2012R2 extremamente genérico. Não importa como eu faça isso (digamos, usando o Assistente para adicionar funções e recursos), a instalação falha com a seguinte mensagem de erro:

Session Collection

    Unable to create the session collection.

Uma captura de tela pode ser encontrada aqui: http://imgur.com/RXyLhNQ

Esta máquina é um Dell Poweredge R730 colocado com 256 GB de RAM e 2 processadores Xeon E5-2680 v3 (total de 16 núcleos).

Após a instalação falhar, o Gerenciador do Servidor mostra que a função Serviços de Área de Trabalho Remota foi instalada, fornecendo um painel para ela, mas se você clicar no painel e selecionar visão geral, receberá esta mensagem:

A Remote Desktop Services deployment does not exist in the server pool.
To create a deployment, run the Add Roles and Features Wizard and select
the Remote Desktop Services installation option.

Se eu tentar a mesma instalação, usando exatamente o mesmo arquivo ISO do Windows 2012 Server em uma área de trabalho i5 em meu escritório e seguindo exatamente as mesmas etapas de instalação, a instalação será bem-sucedida sem problemas.

Eu não tenho ideia de por que isso está acontecendo. O servidor possui 185 GB de disco SSD RAID 1 (deve ser suficiente, o desktop possui um disco de 225 GB). Tentei adicionar a função antes de aplicar os patches, depois de aplicar os patches, usando o PowerShell de um servidor Windows 2012 remoto etc., e nada parece funcionar. Estou instalando todas as funções RDS em uma única máquina de acordo com uma dúzia de tutoriais na web, então tenho certeza de que estou seguindo as etapas de instalação corretamente; de qualquer forma, a instalação funciona na área de trabalho do meu escritório.

Além disso, não consigo encontrar nada útil nos arquivos de log de eventos do Windows.

Estou começando a me perguntar se a Microsoft tem algum tipo de gancho que impede que a função RDS seja instalada em uma máquina com muita RAM ou muitos núcleos humanos.

Tenho lido tudo o que posso encontrar no PAM (por exemplo , http://wpollock.com/AUnix2/PAM-Help.htm ), no entanto, ainda estou confuso sobre a precisão com que as opções avançadas devem funcionar. Por exemplo, toda referência diz isso:

Each of the four control-flag keywords (required, requisite, sufficient, and
optional) have an equivalent expression in terms of the [...] syntax:

required
    [success=ok new_authtok_reqd=ok ignore=ignore default=bad]

Meu entendimento é que os módulos podem retornar uma variedade de tokens e que a ação associada a cada token é descrita no arquivo de configuração. Com base nesse entendimento, o que

new_authtok_reqd=ok

tem a ver com o sinalizador de controle necessário ? Qual é o significado/propósito de

ignore=ignore ?

Isso por si só:

success=ok

é o que eu acho que corresponde ao comportamento exigido , mas não

default=bad

significa que se o módulo retornar qualquer outro token de ação, o módulo falhará? O token action=value success=ok é substituído por default=bad ou vice-versa? Qual tem precedência? Não está claro em nada que li.

Mais geralmente, suponha que eu tenha algo como

[success=done default=die]

O que acontece se o módulo retornar sucesso e um outro token?

Por fim, também não consigo encontrar a resposta para esta pergunta: todo valor pode ok, done, bad, die, ignore, reset, Nser associado a qualquer ação? O que significaria mesmo dizer

[default=done] ?