O primeiro protótipo de servidor solar com controlador de carga. Foto:
Em setembro de 2018, um entusiasta da Low-tech Magazine . O objetivo era reduzir o consumo de energia o suficiente para que um servidor self-hosted doméstico pudesse sobreviver com um único painel solar. Isso não é fácil, já que o site precisa operar 24 horas por dia. Vamos ver qual foi o resultado.
Você pode acessar o servidor , verificar o consumo atual de energia e o nível de carga da bateria. O site foi otimizado para um número mínimo de solicitações por página e tráfego reduzido, então deve aguentar um pico de visitantes do Habr. De acordo com os cálculos do desenvolvedor, o consumo de energia por visitante único é de 0,021 Wh.
Pouco antes do amanhecer em 31 de janeiro de 2020, ele tinha 42% de carga da bateria restante. O amanhecer em Barcelona é às 8h04 no horário local; depois disso, deverá passar corrente do painel solar.
Por quê?
Há dez anos, especialistas que o desenvolvimento da internet promoveria a "dematerialização" da sociedade, a digitalização universal — e, como consequência, uma redução no consumo total de energia. Eles estavam errados. Na verdade, a internet exigiu , e essas quantidades continuam a crescer.
As empresas de TI iniciaram iniciativas para migrar para fontes de energia alternativas, mas isso é impossível agora. Todos os data centers consomem três vezes mais energia do que todas as instalações solares e eólicas do mundo geram. Pior ainda, a produção e a substituição regular de painéis solares e turbinas eólicas , por isso é simplesmente impossível abrir mão de combustíveis fósseis (petróleo, gás, urânio) hoje em dia. Mas essas reservas não durarão para sempre, por isso inevitavelmente precisaremos pensar em como viver com fontes renováveis. Incluindo a operação de infraestrutura computacional, como servidores web.
A Low-tech Magazine o inchaço excessivo das páginas web. De 2010 a 2018, o tamanho médio da página aumentou , e em sites móveis — de 0,15 MB para 1,6 MB, segundo uma estimativa conservadora.
O aumento do tráfego (a energia necessária para transmitir 1 megabyte de informação), o que resulta em um aumento constante do consumo de energia da internet. Sites mais pesados e sobrecarregados não apenas aumentam a pressão sobre a infraestrutura de rede, mas também reduzem o "ciclo de vida" de computadores e smartphones, que precisam ser descartados e substituídos com mais frequência. .
E, claro, o aumento da carga é gerado pelo próprio estilo de vida: as pessoas passam quase todo o tempo na internet e dependem muito de diferentes serviços da web. É difícil imaginar a sociedade moderna sem uma infraestrutura de TI baseada em nuvem (redes sociais, mensageiros, e-mail, etc.)
A configuração do servidor e do site
Em detalha a configuração de hardware e a pilha de software do servidor web.
Computador de placa única escolhido por seu baixo consumo de energia e funções adicionais úteis, como um chip de gerenciamento de energia . Ele permite solicitar estatísticas sobre a tensão e a corrente da placa e da bateria. O chip alterna automaticamente a alimentação entre a bateria e a porta DC, onde a corrente flui do painel solar. Dessa forma, é possível garantir a alimentação ininterrupta do servidor com suporte a bateria.
Olimex Olinuxino A20 Lime 2
Inicialmente, foi escolhida uma bateria de polímero de lítio com capacidade de 6600 mAh (cerca de 24 Wh), depois foi instalado um acumulador de chumbo-ácido de 84,4 Wh.
O sistema operacional é carregado a partir de um cartão SD. Embora o SO ocupe no máximo 1 GB, e um site web estático cerca de 30 MB, não havia sentido econômico em comprar um cartão menor que Class 10 16 GB.
O servidor se conecta à rede através de uma conexão de 100 megabits em Barcelona com um roteador consumidor padrão. Um endereço IP estático é reservado para ele. Quase qualquer pessoa pode configurar um site assim em seu apartamento, basta ajustar um pouco a configuração do firewall para encaminhar as portas ao IP local:
Porta 80 para 80 para HTTP Porta 443 para 443 para HTTPS Porta 22 para 22 para SSH
Sistema operacional baseado na distribuição Debian e no núcleo , desenvolvido para placas únicas com chips AllWinner.
Um painel solar de 50 watts para o servidor web e um painel de 10 watts para a iluminação da sala do apartamento do autor
O site estático foi gerado pelo sistema (gerador de sites em Python). Sites estáticos carregam mais rápido e não criam carga no CPU, portanto são muito mais eficientes do que páginas geradas dinamicamente, do ponto de vista do consumo de energia. O código-fonte do tema .
Um ponto muito importante é a compressão de imagens, pois sem essa otimização praticamente é impossível tornar as páginas da web menores que 1 megabyte. Para a otimização, decidiu-se converter as fotos em imagens em tons de cinza. Por exemplo, aqui está uma foto de operadoras de telefone em uma central no século passado, .
Aqui está uma imagem em tons de cinza otimizada com tamanho com três cores (preto, branco e cinza). Graças à ilusão óptica, parece ao espectador que o número de cores é maior que três.
As fotos em tons de cinza foram escolhidas não apenas para otimizar o tamanho (uma decisão bastante questionável), mas também por razões estéticas. Esta antiga técnica de processamento de imagens possui certas características estilísticas, fazendo com que o site tenha um design, de certa forma, único.
623 ilustrações no site da revista Low-tech Magazine, após otimização, diminuíram de tamanho de 194,2 MB para 21,3 MB, ou seja, uma redução de 89%.
Todos os artigos antigos foram convertidos para Markdown para facilitar a escrita de novos artigos, bem como para facilitar o backup através de . Todos os scripts e rastreadores foram removidos do site, assim como os logotipos. Utiliza-se a fonte padrão do navegador do cliente. Como “logotipo” — o nome da revista em letras maiúsculas com uma seta para a esquerda: LOW←TECH MAGAZINE. Apenas 16 bytes em vez de uma imagem.
Em caso de inatividade, foi organizada a possibilidade de “leitura offline”: textos e imagens são exportados para um feed RSS. O cache de 100% do conteúdo foi ativado, incluindo HTML.
Mais uma otimização — habilitação da configuração HTTP2 no nginx, o que reduz um pouco o tráfego e diminui o tempo de carregamento das páginas, em comparação com HTTP/1.1. A tabela compara os resultados para cinco páginas diferentes.
| | FP | WE | HS | FW | CW | |----------|-------|-------|-------|-------|-------| | HTTP/1.1 | 1.46s | 1.87s | 1.54s | 1.86s | 1.89s | | HTTP2 | 1.30s | 1.49s | 1.54s | 1.79s | 1.55s | | Imagens | 9 | 21 | 11 | 19 | 23 | | economia | 11% | 21% | 0% | 4% | 18% |
Configuração completa do nginx:
root@solarserver:~/var/log/nginx# cat /etc/nginx/sites-enabled/solar.lowtechmagazine.com
# Mapa de expiração
map $sent_http_content_type $expires {
default off;
text/html 7d;
text/css max;
application/javascript max;
~image/ max;
}
server {
listen 80;
server_name solar.lowtechmagazine.com;
location / {
return 301 https://$server_name$request_uri;
}
}
server{
listen 443 ssl http2;
server_name solar.lowtechmagazine.com;
charset UTF-8; #melhoria da velocidade da página ao enviar o charset com a primeira resposta.
location / {
root /var/www/html/;
index index.html;
autoindex off;
}
# Cache (salvar páginas html por 7 dias, o restante pelo máximo possível, sem cache na página inicial)
expires $expires;
location @index {
add_header Last-Modified $date_gmt;
add_header Cache-Control 'no-cache, no-store';
etag off;
expires off;
}
#error_page 404 /404.html;
# redirecionar páginas de erro do servidor para a página estática /50x.html
#error_page 500 502 503 504 /50x.html;
#location = /50x.html {
# root /var/www/;
#}
# Compressão
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
# Cache (salvar página html por 7 dias, o restante pelo máximo possível)
expires $expires;
# Logs
access_log /var/log/nginx/solar.lowtechmagazine.com_ssl.access.log;
error_log /var/log/nginx/solar.lowtechmagazine.com_ssl.error.log;
# Configurações de SSL:
ssl_certificate /etc/letsencrypt/live/solar.lowtechmagazine.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/solar.lowtechmagazine.com/privkey.pem;
# Melhoria de desempenho HTTPS com ressuprimento de sessão
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
# Ativar proteção do lado do servidor contra ataques BEAST
ssl_prefer_server_ciphers on;
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
# Desativar SSLv3
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# Reduzir o tamanho do buffer para aumentar o TTFB
ssl_buffer_size 4k;
# Parâmetro Diffie-Hellman para conjuntos de cifras DHE
# $ sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096
ssl_dhparam /etc/ssl/certs/dhparam.pem;
# Ativar HSTS (https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security)
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
# Ativar OCSP stapling (http://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox)
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/solar.lowtechmagazine.com/fullchain.pem;
resolver 87.98.175.85 193.183.98.66 valid=300s;
resolver_timeout 5s;
}Resultados de 15 meses de operação
No período de 12 de dezembro de 2018 a 28 de novembro de 2019, o servidor apresentou . Isso significa que, devido ao mau tempo, o tempo de inatividade no ano foi de 399 horas.
Mas se não levar em consideração os últimos dois meses, o tempo de operação ininterrupta foi de 98,2%, com um total de apenas 152 horas de inatividade, afirmam os desenvolvedores. O tempo de operação ininterrupta caiu para 80% nos últimos dois meses, quando o consumo de energia aumentou devido a uma atualização de software. Todas as noites, o site era desligado por algumas horas.
Segundo as estatísticas, no período de um ano (de 3 de dezembro de 2018 a 24 de novembro de 2019), o consumo de energia do servidor foi de 9,53 kWh. Perdas significativas foram registradas no sistema fotovoltaico devido à conversão de tensão e ao descarregamento da bateria. O controlador solar mostrou um consumo anual de 18,10 kWh, o que significa que a eficiência do sistema é de cerca de 50%.
Diagrama simplificado. Não mostra o conversor de tensão de 12 para 5 volts e o medidor de ampere-horas da bateria.
Durante o período estudado, o site recebeu 865.000 visitantes únicos. Incluindo todas as perdas de energia na instalação solar, o consumo de energia por visitante único foi de 0,021 Wh. Assim, um kilowatt-hora de energia solar gerada é suficiente para atender quase 50.000 visitantes únicos.
Durante a experiência, foram testados painéis solares de diferentes tamanhos. A tabela apresenta os cálculos de quanto tempo levará para carregar baterias de diferentes capacidades utilizando painéis solares de diferentes tamanhos.
A potência média consumida pelo servidor web durante o primeiro ano, incluindo todas as perdas de energia, foi de 1,97 W. O cálculo mostra que para manter o site durante a noite mais curta do ano (8 horas e 50 minutos, 21 de junho), são necessários 17,40 watt-horas de armazenamento, enquanto na noite mais longa (14 horas e 49 minutos, 21 de dezembro), são necessários 29,19 Wh.
Uma vez que as baterias de chumbo-ácido não devem ser descarregadas abaixo de metade de sua capacidade, o servidor requer uma bateria de 60 Wh para sobreviver à noite mais longa com iluminação diurna ótima (2×29,19 Wh). A maior parte do ano, o sistema funcionou com uma bateria de 86,4 Wh e um painel solar de 50 watts, alcançando assim a disponibilidade mencionada de 95-98%.
Disponibilidade 100%
Para uma disponibilidade de 100%, é necessário aumentar a capacidade das baterias. Para compensar um dia de clima muito ruim (sem geração significativa de eletricidade), são necessários 47,28 watt-horas (24 horas × 1,97 watts) de armazenamento.
De 1 de dezembro de 2019 a 12 de janeiro de 2020, o sistema recebeu uma bateria de 168 watts, com uma capacidade prática de armazenamento de 84 watt-horas. Esse armazenamento é suficiente para manter o site funcionando durante duas noites e um dia. A configuração foi testada no período mais escuro do ano, mas o clima estava relativamente bom - e durante o período indicado, o tempo de funcionamento sem falhas foi de 100%.
Mas para garantir um tempo de atividade de 100% durante vários anos, é necessário prever o pior cenário, quando o mau tempo persiste por vários dias. O cálculo mostra: para manter o site online durante quatro dias com geração de energia baixa ou nula, será necessária uma bateria de chumbo-ácido com capacidade de 440 watt-horas, ou seja, do tamanho de uma bateria de carro.
Na prática, com bom tempo, uma bateria de chumbo-ácido com 48 Wh sustenta o funcionamento do servidor durante a noite de março a setembro. Uma bateria de 24 Wh suportará o servidor por no máximo 6 horas, ou seja, ele desligará a cada noite, embora em horários diferentes, dependendo do mês.
Em grande parte, alguns sites não precisam funcionar à noite, quando o número de visitantes é mínimo, acreditam os pessoal da Low-tech Magazine. Por exemplo, se for uma publicação regional de uma cidade, onde não há visitantes de outros fusos horários, apenas moradores locais.
Ou seja, sites com diferentes níveis de tráfego e diferentes tempos de atividade necessitam de baterias de diferentes capacidades e painéis solares de tamanhos variados.
O autor apresenta um cálculo de quanta energia é necessária para a produção dos próprios painéis solares (energia incorporada) e quanto isso representa se dividir essa quantidade pela expectativa de vida de 10 anos.
Dessa forma, é possível calcular o equivalente a combustíveis fósseis que foram gastos na produção e operação dos painéis. A Low-tech Magazine descobriu que, no primeiro ano de operação, seu sistema (painel de 50 W, bateria de 86,4 Wh) "gerou" aproximadamente 9 kg de emissões ou o equivalente à queima de 3 litros de gasolina: aproximadamente a mesma quantidade que um carro de passeio consome em 50 km de percurso.
Se o servidor não for alimentado por painéis solares, mas pela rede elétrica geral, a equivalência das emissões parece ser seis vezes menor: 1,54 kg (na energia espanhola, a participação de fontes alternativas e usinas nucleares é alta). No entanto, essa comparação não é totalmente correta, conforme menciona o autor, porque leva em conta a energia incorporada da infraestrutura solar, mas não considera esse indicador para a rede elétrica geral, ou seja, os custos para sua construção e manutenção.
Melhorias Futuras
Desde então, uma série de otimizações foram realizadas, reduzindo o consumo energético do servidor. Por exemplo, em algum momento, o desenvolvedor percebeu que 6,63 TB do total de 11,15 TB de tráfego eram gerados por uma implementação incorreta do feed RSS, que puxava conteúdo a cada poucos minutos. Após corrigir esse erro, o consumo energético do servidor (sem contar as perdas de energia) caiu de 1,14 W para aproximadamente 0,95 W. A economia pode parecer pequena, mas a diferença de 0,19 W significa 4,56 watt-horas por dia, o que corresponde a mais de 2,5 horas de operação autônoma do servidor.
Durante o primeiro ano, a eficiência foi de apenas 50%. Perdas ocorreram durante o carregamento e descarregamento da bateria (22%), bem como na conversão de tensão de 12 V (sistema fotovoltaico solar) para 5 V (USB), onde as perdas podem chegar a 28%. O desenvolvedor reconhece que tem um conversor de tensão não ideal (controlador sem USB embutido), portanto, esse aspecto pode ser otimizado ou pode-se passar para uma instalação solar de 5V.
Para aumentar a eficiência do armazenamento de energia, pode-se substituir as baterias de chumbo-ácido por baterias de íon de lítio mais caras, que têm menores perdas de carga/descarregamento (<10%). Atualmente, o projetista está considerando um (CAES), que tem uma vida útil de décadas, o que significa uma menor "pegada de carbono" em sua produção.
Uma bateria compacta de energia a ar comprimido,
Está sendo considerada a instalação de uma turbina eólica adicional (que pode ser ) e a instalação de um rastreador solar para girar os painéis em direção ao sol. O rastreador permite aumentar a produção de eletricidade em 30%.
Outra maneira de aumentar a eficiência do sistema é sua escalabilidade. Hospedar mais sites no servidor e executar mais servidores. Assim, o consumo de energia por site será reduzido.
Empresa de hospedagem solar. Ilustração: Diego Marmolejo
Se cobrir toda a varanda do apartamento com painéis solares e abrir uma empresa de hospedagem web solar, os custos por cliente serão significativamente menores do que para um único site: economias de escala.
No geral, este experimento demonstra que, sob certas limitações, a infraestrutura computacional pode operar com fontes de energia renováveis.
Teoricamente, esse servidor pode até mesmo funcionar sem bateria, se estiver espelhado em outras partes do mundo. Por exemplo, colocar espelhos na Nova Zelândia e no Chile. Lá, os painéis solares estarão funcionando quando for noite em Barcelona.
Fonte: habr.com
