Com que frequência você reinicia um servidor de área de trabalho remota (VM) do Windows Server 2008R2?


17

Nota: Li com que frequência os servidores Windows precisam ser reiniciados? mas esta pergunta se refere especificamente ao nosso servidor de área de trabalho remota .

Temos um servidor Windows Server 2008R2 - VM VMware ESX - licenciado para Serviços de Área de Trabalho Remota, 25 usuários que também fazem RRAS (SSTP). Em um dia médio da semana, durante o horário de trabalho, há entre 8 e 12 usuários ativos e com 4-6 usuários "desconectados" adicionais. Ele possui uma reserva rígida de CPU de 12 GHz e 16 GB de RAM, também totalmente reservada. A reserva da CPU é expansível até 24 GHz no máximo, quando necessário.

Muitos de nossos usuários confiam exclusivamente no servidor para trabalhar. Eles também se queixam amargamente de seu desempenho, mas muitos não estão dispostos a mudar hábitos de trabalho ou software para melhorar seu desempenho. Especificamente:

  • Os usuários se recusam a fazer logoff em vez de desconectar
  • Os usuários insistem em usar o Lync 2013 em vez do Lync 2010 (o Lync 2013 é um famoso recurso)

Não posso exagerar o significado da recusa deles em fazer logoff. Usuários desconcertados continuam monopolizando a RAM enquanto desconectados, o que significa que, a qualquer momento, temos até 16 instâncias de determinados programas em execução.

Também notei por experiência que vazamentos / zumbis tendem a aumentar quanto mais tempo um servidor de Área de Trabalho Remota estiver em execução. Após uma reinicialização, o servidor é novo e muito mais rápido, mesmo quando se compara o desempenho depois que muitos usuários efetuam login. Também li que reinicializações regulares podem ser úteis.

Por isso, propus reinicializações regulares da VM - gostaria de fazê-lo semanalmente, digamos, no sábado à noite -, pois sinto que essas reinicializações resolveriam grande parte do problema.

Gostaria de saber, se você é um administrador do Windows,

  • Estou certo sobre o fato de que lixo / zumbis / vazamentos se acumulam com o tempo da sessão, mesmo após um usuário desconectar / reconectar?

  • Com que frequência você reinicia um Windows Server de uso semelhante com os Serviços de Área de Trabalho Remota?


10
Por que não usar uma política para forçar o logoff de sessões inativas?
Massimo

@Massimo porque eles considerariam isso muito pesado ... eles perdem o trabalho toda vez que eu reinicio sem aviso prévio, ou seja, para reiniciar tudo o que eles precisam saber até o meio dia desse dia, e mesmo assim é só depois de alguns resmungando e de discussão, etc.
tacos_tacos_tacos

12
Você precisará ajustar as expectativas de seus usuários. Na IMO, não é razoável que eles esperem que possam sair com segurança de uma sessão inativa com dados não salvos por qualquer período de tempo. Um acidente inesperado, falha no equipamento, falta de energia ou algum outro ato do Caos poderia facilmente destruir seu trabalho não salvo.
Zoredache

2
Não me importo com a pergunta, mas as respostas conforme a pergunta é formulada serão baseadas em opções. Tente reformular para obter mais informações ou (ou pelo menos com base no desempenho) respostas.
22715 Jim

1
@tacos_tacos_tacos é a minha experiência. O que exatamente deve entupir um sistema operacional em execução? É uma noção vaga que não tem fundamento. O sistema operacional não faz muito isso. Os processos do usuário fazem coisas. Quando eles se foram, a lousa está limpa novamente. O sistema operacional geralmente fica fora do caminho e faz o que os processos do usuário solicitam. Ele não inicia o uso de recursos por si só.
usr

Respostas:


23

Geralmente, sou contra a idéia de que um servidor Windows deve ser reinicializado regularmente, EXCETO em relação aos servidores TS / RDS. Reiniciamos o nosso todos os dias. Ele limpa sessões antigas, libera recursos em uso (CPU, RAM, manipuladores de arquivos etc.). Portanto, minha opinião e sugestão é que você configure uma reinicialização programada diariamente de seus servidores RDS.

Note que esta resposta é apenas minha opinião. Não há nenhuma declaração de fato aqui.


Onde trabalhei, também reiniciamos o nosso todas as noites. Algumas vezes o servidor não volta, mas acontece tão raramente que valeu a pena.
Frederik Nielsen

Quantas vezes você o reinstalou?
Konrad Gajewski

4
+1 Citrix, Microsoft e eu recomendamos a reinicialização regular dos servidores TS. Essas são essencialmente caixas de computação do usuário final e normalmente executam aplicativos que não são otimizados para servidores - isso significa vazamentos de memória, não liberando recursos e assim por diante. Semanalmente, no mínimo absoluto, mas diariamente, sempre que possível - facilitará sua vida.
Dan

@ Existe algum link para a recomendação da Microsoft mencionada (reinicialização regular)?
Tacos_tacos_tacos

17

Os usuários se recusam a fazer logoff em vez de desconectar

Configure as políticas de grupo apropriadas para fazer logoff automático delas. Você pode controlar separadamente um tempo limite inativo e logoff. Isso certamente deve minimizar parte do problema durante o dia.

Eu reinicio meu farm TS de 3 servidores diariamente às 3:00. Porque, sim, a porcaria pode se acumular ao longo do tempo quando você tem muitas pessoas usando um único sistema. Temos 3 servidores compartilhados entre 60 a 90 pessoas, dependendo do dia, época do ano.

Provavelmente não preciso reinicializar isso com frequência, mas começamos a usar os serviços de terminal com o Windows 2000 e nossos drivers de impressora eram horríveis na época. O spooler de impressão basicamente falharia após um ou dois dias de funcionamento. Por isso, começamos a reinicializar todas as noites, já que não tínhamos nenhuma alavanca para fazer com que os fabricantes de impressoras corrigissem seus drivers ruins.


em relação aos drivers de impressora, etc: li aqui ou em algum outro local respeitável que a MS fez grandes avanços neste departamento - e na redução da necessidade de reinicialização em geral - entre o Windows 2000 Server e o Windows Server 20032R2 SP3. Portanto, não tenho certeza de que o problema dos drivers tenha relevância. Na verdade, notei que versões mais recentes do Windows (Server) parecem lidar com drivers de impressão e spool surpreendentemente bem.
Tacos_tacos_tacos

Na verdade, não reinicio o servidor TS com muita frequência, mas todas as noites eu paro o spooler de impressão, excluo os trabalhos de impressão e o reinigo. Isso também cura incidentes quando os usuários não conseguem fazer login usando o RDP. (Windows Server 2003)
Randy Orrison

6

Dependendo do dinheiro, do tempo e da conveniência dos usuários, outra idéia pode ser a de suportar um segundo servidor. Você ainda precisará reiniciar ocasionalmente, mas parece estar atingindo os limites de um único servidor.

Você deve poder usar as mesmas CALs de cliente (o licenciamento não é minha área mais forte) e, dependendo da sua solução de virtualização, uma VM adicional já pode estar coberta pelo licenciamento existente.

Mesmo sem recursos adicionais da VM e com a sobrecarga extra do sistema operacional, você pode achar que o sistema lida melhor como duas VMs separadas de CPU de 6 GHZ e memória de 8 GiB, supondo que você possa dividir a carga uniformemente. Existem três métodos possíveis:

  1. A maneira mais limpa é usar uma solução de balanceamento de carga baseada em rede adequada, como as fornecidas pela F5 Networks, Cisco Systems e empresas similares. Se você já comprou uma solução como essa, vale a pena usá-la aqui. Em seguida, você pode ignorar o restante da resposta, pois o f5 poderá analisar adequadamente todas as consultas do FQDN usadas para acessar o servidor de RD atual e retornar um IP apropriado com base no menos utilizado dos servidores.
  2. O DNS Round-Robin é uma solução aceitável. Ele não garante uma carga perfeitamente uniforme, mas pode ser uma interrupção útil enquanto você educa seus usuários (consulte 3) se não puder usar um balanceador de carga de rede. Substitua o nome DNS atual que os clientes estão usando por dois registros de host com o mesmo nome, mas com IPs diferentes (seus dois servidores), idealmente, também configure registros de host separados (de preferência com base no nome do host do servidor) vinculados a cada servidor individual.

Defina um TTL longo nas entradas round-robin se não desejar que os clientes saiam de sessões desconectadas em um servidor quando o cache DNS expirar e eles adquirirem o IP do outro servidor. Como alternativa, torne óbvio o nome do host do computador ao qual eles se conectaram (por exemplo, faça parte do plano de fundo) e peça que eles se reconectem a esse nome do host se quiserem ressuscitar a sessão.

  1. Faça com que seus clientes distribuam a carga. Com ~ 25 usuários, pode ser possível simplesmente pedir (por e-mail ou uma mensagem de login no servidor) que certos usuários acessem um servidor e o restante para outro. Como alternativa, se você controlar a plataforma da área de trabalho ou acessar o servidor via citrix ou outro dispositivo de virtualização de aplicativo, basta configurar o arquivo de hosts † para que eles sempre atinjam o mesmo servidor (área de trabalho) / garanta que o mesmo usuário seja sempre enviado ao mesmo servidor ( utensílio).

† Se eles sempre usarem a mesma área de trabalho, simplesmente modifique o arquivo de hosts na área de trabalho local. Se eles se moverem entre máquinas, escreva um script (distribuído via diretiva de grupo) para analisar o arquivo host, de modo que a entrada DNS atualmente usada no servidor aponte para o IP do servidor que esse usuário em particular deve estar usando. Substitua a linha que contém esse nome DNS, se ele já existir, ou adicione-o ao final do arquivo, se não existir.


2
+1 para criatividade. Posso configurar um balanceador de carga e esse é honestamente o caminho a seguir.
Tacos_tacos_tacos 14/05

4

Estou familiarizado com o "tipo de usuário" que se recusa a fazer logoff. No entanto, eles pareciam não ter nenhum problema em entender que o servidor seria reiniciado todas as noites, para que qualquer trabalho não salvo fosse perdido. Isso está no Server 2008 R2 TS, suportando cerca de 20 usuários em uma única máquina.


1

> Os usuários se recusam a fazer logoff em vez de desconectar

Você tem um problema de gerenciamento / RH aqui e não técnico. Se as pessoas que estão conectadas estão afetando o trabalho de outras pessoas (reduzindo o desempenho desnecessariamente), existem apenas duas soluções:

  1. Torne-o um problema técnico e organize um aumento de recursos (mais RAM, SSD no lugar de metal giratório, ...) se possível, para que o problema desapareça dessa maneira. É claro que existem limites para o que você pode alcançar lançando novos recursos em uma única máquina, mas pode funcionar.

  2. Persiga-o como um problema de gestão de pessoas e encontre alguma maneira de incentivar (ou falhar nessa imposição ) a disciplina apropriada. É claro que isso pode estar fora de sua responsabilidade direta, por isso pode ser bastante complicado, dependendo da política do seu escritório ...

Tivemos um problema semelhante com as pessoas nunca reiniciando suas máquinas de desktop, o que significa que as atualizações de segurança às vezes ficavam na fila por meses. A política de segurança afirmou que "os patches para problemas de segurança conhecidos devem ser instalados em tempo hábil, imediatamente nos casos em que já existem explorações em estado selvagem, a menos que atenuações suficientes possam ser comprovadas"; portanto, no final, ela foi simplesmente aplicada pela política de grupo: todas As máquinas Windows de servidor serão reinicializadas durante a noite de terça-feira, se houver atualizações pendentes, sem exceções. Se alguém argumentar contra isso, existem dois contadores fáceis: se não seguirmos essa política, perderemos nosso credenciamento ISO-este-aquele-e-outro na próxima vez que houver qualquer auditoria que seja importante para os negócios,

> Os usuários insistem em usar o Lync 2013 em vez do Lync 2010 (o Lync 2013 é um recurso famoso)

Existe uma razão específica para isso, além de quererem coisas mais brilhantes e novas? Se houver um recurso que eles realmente precisam, pode haver pouco que você possa fazer sobre esse ângulo.

Se um aplicativo de bate-papo é o principal problema de recurso, pergunto-me se existe uma maneira de matar apenas instâncias desse programa nas sessões inativas, em vez de matar as sessões inteiras?

> eles perdem o trabalho toda vez que eu reinicio sem aviso prévio, ou seja, para reiniciar tudo o que eles precisam saber até o meio dia desse dia

Você não declara a natureza do trabalho, portanto isso depende muito do que é, mas eles podem estar falhando na devida diligência (por exemplo, não estão fazendo seu trabalho adequadamente ).

Se eles não estão salvando documentos regularmente, então eles estão colocando seu trabalho em risco, não você. O que aconteceria se houvesse uma falta de energia ou outra falha que derrubasse o servidor? Eles te culpariam também?

Obviamente, se eles estiverem trabalhando ativamente no momento da reinicialização ou precisarem deixar os processos de execução prolongada sem supervisão, pode haver um problema genuíno de agendamento que você precisa resolver entre si.


0

Com o risco de parecer um vendedor - usamos o ShutdownPlus Rolling Restart . Nós o configuramos para tentar reiniciar nossos servidores todas as noites. Funciona muito bem - você pode configurá-lo para reiniciar apenas os servidores depois que todos forem desconectados. Ele reiniciará o loop se alguém ainda estiver usando o servidor RD várias vezes. As ferramentas também podem fazer logoff de usuários, se você desejar. Ou mesmo ligue suas VMs @ ESXi.

Estou usando-o com alguns GPOs que desconectam usuários desconectados após algumas horas. E desconecta as sessões ativas após um certo tempo ocioso, é claro. É um método bastante elegante, além do programa nocivo ocasional que impede as sessões de fechar. Nós trabalhamos com eles. Da maneira que configuramos agora, todos os servidores tentam reinicializar a cada hora das 22:00 às 7:00, até que seja bem-sucedido. Efetivamente, os usuários reiniciam pelo menos 2/3 vezes por semana, o que é bom para mim.

Infelizmente, este não é um programa gratuito, mas faz um bom trabalho. Estou implementando um script do PowerShell que esperamos atualizar os servidores antes de reiniciar também.


0

A resposta direta ao servidor da Microsoft reinicia SIM / NÃO. Oh, se a vida fosse assim tão fácil! Depende dos aplicativos em execução no servidor. Mas aqui está um guia simples, mas NÃO uma regra rígida e rápida.

Servidor físico executando o servidor Windows ** x Versão ** ( reinicialização automática e agendamento ) 95% pode ser reiniciado uma vez a cada quinzena sem preocupações reais. (Verifique se o patch que está sendo aplicado é relevante e necessário). Certifique-se de testar completamente o patch no (s) servidor (es) de teste antes de liberar para os sistemas ativos / de produção.

Servidores Virtuais VMWare executando o Windows Server x Versão - Reinicie uma vez a cada quinzena ( veja o comentário acima se os patches forem aplicados )

Servidor físico VMWare NUNCA / Raramente e somente se necessário, nunca agendado. (Normalmente muito estável, se mantido atualizado) As atualizações / patches do VMWare exigirão uma reinicialização.

VMWare executando o Windows SQL (limitar reinicializações, aplicar patches do Windows APENAS MANUALMENTE! Reiniciar se o patch exigir e somente depois de interromper todas as conexões dos clientes) Verifique se as conexões foram reconectadas após o backup do servidor. Os servidores SQL podem demorar um pouco para reiniciar, portanto planeje isso fora de horas.

Lembrete: Antes de fazer QUALQUER alteração para um INSTANTÂNEO do VMWare (Windows Server)! se o sistema travar após o Service Patch ou atualizações aplicadas ou aplicativos falharem no início, você poderá obter rapidamente o backup e a execução do servidor com tempo de inatividade limitado. Lembre-se de anotar os erros para que você possa encontrar a correção que não deixa o sistema em paz, porque falhou, pois pode falhar no futuro.

Espero que ajude e faça um pequeno caminho para esclarecer as coisas.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.