Naprawa typowego uszkodzenia APC Back-UPS RS 500

Rozpoznanie i podłoże usterki

Ze względu na błędną aplikację układu UC3842B w przetwornicy zasilacza awaryjnego APC Back-UPS RS 500, po dłuższym czasie użytkowania (>3 cykle wymiany baterii, 10 lat od produkcji) ulega uszkodzeniu układ ładowania akumulatora.
Objawy – pulsowanie wszystkich trzech diód – wskazywałyby raczej na konieczność wymiany akumulatora.

Niestety, bez wymiany może się nie obejść – jeżeli reakcja na ten stan nie wystąpi wystarczająco wcześnie, może dojść do głębokiego jego rozładowania, bezpowrotnego uszkodzenia i konieczności zakupu nowego modułu bateryjnego. Zapobiec temu możemy przez monitorowanie stanu zasilacza awaryjnego przez Nagios korzystając z wtyczki check_apcupsd.

Celem naprawy uszkodzonego zasilacza konieczna jest wymiana uszkodzonego kondensatora oznaczonego C7, nie spełniającego już swojej funkcji ze względu na długotrwałą pracę przy wysokiej częstotliwości oraz na granicy parametrów.

Naprawa uszkodzenia

Naprawa wymaga podstawowej umiejętności posługiwania się lutownicą, pewnej ręki oraz dozy zdrowego rozsądku. Ze względu na możliwość kontaktu z napięciem niebezpiecznym dla zdrowia i życia, w przypadku braku jednego z nich – lepiej skorzystać z pomocy serwisu APC bądź pozwolić zasilaczowi przejść na zasłużoną emeryturę i wybrać młodszy model zasilacza awaryjnego o zbliżonych parametrach.
Po uprzednim odłączeniu zasilania sieciowego, podtrzymywanych urządzeń oraz akumulatora (najpierw czarny zacisk) oraz chwili poświęconej przez nas na kontemplacji dalszej części instrukcji, a przez kondensatory na utracie ładunku, możemy przystąpić do otwarcia obudowy przez odkręcenie śrub z tyłu UPS, ostrożne wysunięciu tylnej ścianki i rozchylenie bocznych. Gorąco polecam wykonanie dokumentacji (najłatwiej fotograficznej) połączeń – konieczne do wygodnej pracy będzie odłączenie wszystkich kabli od płyty głównej zasilacza awaryjnego.

\"\"

W rewizji 3 tego zasilacza, jest to czarny kondensator na prawo od układu UC3842B w prawym górnym rogu płyty głównej.
Poniższe zdjęcie, ze względu na wyraźniej widoczną polaryzację przedstawia wymieniony już kondensator.
Wykorzystać do tego powinniśmy przewlekany kondensator elektrolityczny dobrej jakości o pojemności 22 mikrofaradów i napięciu min. 16V.

\"\"

Weryfikacja poprawności naprawy

Przed ponownym podłączeniem akumulatora, a po ponownym zamknięciu obudowy powinno się sprawdzić napięcie ładowania na zaciskach modułu bateryjnego. Korzystając z multimetru mierzymy jego poziom po włączeniu zasilacza – poprawny stan to ok. 14V.

Kompilacja Custombuild PHP z Percona Server

O Percona Server

Używamy jest Percona Server w wersji 5.5 jako serwera baz danych MySQL rozszerzając tym samym funkcjonalność standardowego serwera MySQL od Oracle o NoSQL-owy sposób komunikacji przez HandlerSocket oraz silnik składowania XtraDB.
Zoptymalizowany do korzystania z dysków SSD dla cache pozwala na znaczne zwiększenie wydajności bazy danych oraz dzięki dodatkowym INFORMATION_SCHEMA nadzorowanie wydajności i obciążenia per użytkownik bazy danych. W czasie restartów po aktualizacji oprogramowania Percona przechowuje indeksy i cache nie pozwalając nawet na tymczasową utratę wydajności.

Instalacja Percona Server

  1. Konfiguracja repozytorium
    Na Debianie Squeeze serwer został zainstalowany z pakietów pochodzących z repozytorium Percona:

    deb http://repo.percona.com/apt/ squeeze main

    Dostępne są również pakiety pod inne wersje systemu – Hardy, Lenny – jak i inne dystrybucje – np. Ubuntu.

  2. Zatrzymanie i wyłączenie obecnego serwera MySQL

    service mysqld stop
    mv /etc/init.d/mysqld /etc/init.d/mysqld-dis

  3. Instalacja pakietów, w tym pakietu deweloperskiego na potrzeby kompilacji PHP

    apt-get install percona-server-server-5.5 libmysqlclient18 libmysqlclient-dev

  4. Podmiana baz danych na pochodzące ze starego serwera MySQL

    service mysql stop
    rm -Rf /var/lib/mysql/*
    echo \”/home/mysql /var/lib/mysql none bind\” >> /etc/fstab
    mount /var/lib/mysql
    service mysql start

  5. Stworzenie lokalnej kopii konfiguracji pakietu custombuild

    cd /usr/local/directadmin/custombuild
    mkdir -p custom/suphp
    cp configure/suphp/configure.php5 custom/suphp/configure.php5

  6. Zmiana przełączników konfiguracji PHP
    /usr/local/directadmin/custombuild/custom/suphp/configure.php5

    \”–with-mysql\” \\
    \”–with-mysqli=/usr/bin/mysql_config\” \\
    \”–with-pdo-mysql=/usr/bin/mysql\” \\

  7. Rekompilacja PHP

    ./build php n

  8. Ustawienie danych debian-sys-maint. Tworzymy w bazie użytkownika z pełnymi uprawnieniami o poświadczeniach z /etc/mysql/debian.cnf

Konfiguracja Vyatta na serwerach OVH

Wykorzystując serwery OVH do wirtualizacji sprzętowej VMware ESXi pojawia się problem konfiguracji sieci na maszynach wirtualnych korzystających z IP failover. Prezentujemy kilka podejść, przy czym obecnie stosujemy równolegle dwa ostatnie z nich.

Podejście 1 – routing OVH bezpośrednio na maszynę

  1. Tworzymy adres MAC wirtualny w Usługi -> MAC wirtualny ustawiając typ \”vmware\” i ustawiamy go konfigurując adres sprzętowy interrface\’u sieciowego maszyny w vSphere Client.
  2. Konfigurujemy go z maską /32 jako adres IP hosta, dodajemy statyczne trasy do oraz przez gw serwera fizycznego (jego IP z końcówką .254)

    ip addr add 178.32.231.141/32 dev eth0
    route add  172.31.223.254 via eth0
    route add default gw 172.31.223.254

Podejście 2 – routing przez Vyatta, DNAT+SNAT

  1. Podobnie jak w 1, przypisujemy IP failover, ale do istniejącego adresu MAC interface\’u WANowego Vyatty (eth0).
  2. Konfigurujemy podsieć NATowaną na interface\’ie LANowym, NAT i DNS forward.

    set interfaces ethernet eth1 address 192.168.0.1/24
    set service nat rule 1 type destination
    set service nat rule 1 inbound-interface eth0
    set service nat rule 1 destination address 178.32.231.141
    set service nat rule 1 inside-address address  192.168.0.100
    set service nat rule 2 type source
    set service nat rule 2 outside-address 178.32.231.141
    set service nat rule 2 source address 192.168.0.100
    set service dns forwarding system

  3. Konfigurujemy sieć na serwerze wirtualnym podpiętym do LAN

    ip addr add 192.168.0.100/24 dev eth0
    ip route add default gw 192.168.0.1
    echo \”nameserver 192.168.0.1\” >> /etc/resolv.conf

Podejście 3 – routing przez Vyatta, static route

  1. Podobnie jak w 1, przypisujemy IP failover, ale do istniejącego adresu MAC interface\’u WANowego Vyatty (eth0).
  2. Konfigurujemy na obu interface\’ach Vyatty ten sam IP routera

    set interfaces ethernet eth0 address 178.33.137.225/32
    set interfaces ethernet eth1 address 178.33.137.225/32

  3. Ustawiamy domyślną trasę dla routera

    set protocols static route 0.0.0.0/0 next-hop 176.31.233.254

  4. Tworzymy trasę statyczną do serwera wirtualnego (directly connected)

    set protocols static interface-route 178.32.231.141/32 next-hop-interface eth1

  5. Konfigurujemy sieć na serwerze wirtualnym podpiętym do LAN

    ip addr add 178.32.231.141/32 dev eth0
    ip route add 178.33.137.225/32 dev eth0
    ip route add default via 178.33.137.225

Podejście 4 – routing przez Vyatta, failover RIPE

  1. Podobnie jak w 1, przypisujemy IP failover, ale do istniejącego adresu MAC interface\’u WANowego Vyatty (eth0).
  2. Konfigurujemy na obu interface\’ach Vyatty ten sam IP routera – z zewnątrz z maską /32, wewnątrz z maską podsieci

    set interfaces ethernet eth0 address 178.33.137.225/32
    set interfaces ethernet eth1 address 178.33.137.225/29

  3. Ustawiamy domyślną trasę dla routera

    set protocols static route 0.0.0.0/0 next-hop 176.31.233.254

  4. Konfigurujemy sieć na serwerze wirtualnym podpiętym do LAN

    ip addr add 178.33.137.226/29 dev eth0
    ip route add default via 178.33.137.225

Wiele wersji PHP w DirectAdmin używając mod_suphp i mod_macro

Integracja z Directadmin

Od strony DirectAdmina użyliśmy modułu phpsv specjalnie zaadaptowanego dla potrzeb używanej konfiguracji.
Pozwala on na ustawianie osobno wersji PHP dla każdej domeny.

Jeżeli taka możliwość okaże się dla klienta niewystarczająca, możliwe jest ustawienie dla każdej subdomeny, a nawet katalogu osobnej wersji używając opisanego poniżej makra.

 Instalacja wielu wersji PHP

Poszczególne wersje PHP zostały ręcznie skompilowane z różnymi prefiksami, np.:

\”–prefix=/usr/local/php52\”
\”–with-config-file-path=/usr/local/etc/php52/cgi\”

oraz podlinkowane z wygodnymi nazwami w celu uproszczenia używania zadań cron

/usr/local/bin/php-5.2 -> /usr/local/php52/bin/php

Dostępne są php-4.4.9, php-5.2.17, php-5.3.14, php-5.4.4, php-6.0.0.

Każda z nich została zlinkowana z bibliotekami libmysql dla Percona Server oraz w miarę możliwości wyposażona w Zend Optimizer albo Zend Guard Loader oraz ionCube Loader.

Instalacja mod_macro

Dla Apache/2.2.22 używamy modułu w wersji 1.1.11.
Instalacja ogranicza się do pobrania pliku ze strony mod_macro Fabiena Coelho i kompilacji przez apxs zgodnie z plikiem INSTALL.

Dla potrzeb konfiguracji wersji PHP udostępniamy dla użytkowników globalnie następujące macro.

/home/.htaccess:

<Macro php $version>
<FilesMatch \”\\.(inc|php|php3|php4|php5|php6|phtml|phps)$\”>
AddHandler x-httpd-php$version .inc .php .php3 .php4 .php5 .phtml
</FilesMatch>
</Macro>

Którego można użyć w pliku .htaccess wybierając stosowną wersję PHP:

Use php 4
Use php 52
Use php 53
Use php 54
Use php 6

 Konfiguracja mod_suphp

Po standardowej instalacji mod_suphp z custombuild dodajemy stosowne handlery.
W pliku /usr/local/suphp/etc/suphp.conf:

[handlers]
;Handler for php-scripts
x-httpd-php4=\”php:/usr/local/php4/bin/php\”
x-httpd-php52=\”php:/usr/local/php52/bin/php-cgi\”
x-httpd-php53=\”php:/usr/local/php53/bin/php-cgi\”
x-httpd-php54=\”php:/usr/local/php54/bin/php-cgi\”
x-httpd-php6=\”php:/usr/local/php6/bin/php-cgi\”

/etc/httpd/conf/extra/httpd-suphp.conf:

<IfModule mod_suphp.c>
Use php 53
<Location />
suPHP_Engine on
#suPHP_ConfigPath /usr/local/etc/php5/cgi/
suPHP_AddHandler x-httpd-php4
suPHP_AddHandler x-httpd-php52
suPHP_AddHandler x-httpd-php53
suPHP_AddHandler x-httpd-php54
suPHP_AddHandler x-httpd-php6
</Location>
</IfModule>

 

Instalacja Piwik z import_logs.py z Nginx

Chcąc z powodzeniem monitorować ruch na stronie warto przyjrzeć się także wizytom automatycznym klientów nie wspierających JavaScript. W tym celu uzupełnimy statystyki Piwik o wizyty importowane z access log Nginx.

W poprzednim wpisie odnośnie Nginx skonfigurowano go jako reverse proxy dla Apache – w tym artykule przyjmujemy te same ścieżki.

Instalacja Piwik

Instalacja nie powinna sprawić większego problemu – ogranicza się do rozpakowania pobranego archiwum, ustawienia odpowiednich uprawnień i podania poświadczeń do bazy danych. W razie trudności chętnie pomożemy z instalacją skryptu zarówno na własnym hostingu jak i u obcego usługodawcy.

Konfiguracja import_logs.py

Importer dzienników jest uruchamianym cyklicznie skryptem Python dodającym odwiedziny do bazy Piwik.
Jego konfiguracja odbywa się za pomocą licznych przełączników linii poleceń.

Opcję –recorders ustawiamy na pożądaną liczbę wątków (<= ilość rdzeni), –url na pełny URL do instalacji Piwika.

Jeżeli korzystamy z wspólnego access loga dla wielu witryn  (lub uruchamiamy skrypt podając wiele plików)  warto ustawić opcję –add-sites-new-hosts bądź –idsite-fallback aby obsłużyć wizyty dla nieznanych stron.
Jeżeli access log jest oddzielny dla każdej z witryn – możemy wymusić ID strony przełącznikiem –idsite.

Aby śledzić wszystkie wywołania użyliśmy opcji  –enable-http-errors –enable-http-redirects –enable-static –enable-bots  oraz włączyliśmy debug -dd uzyskując finalnie poniższą komendę:

 python /srv/vhosts/aboo.pl/piwik/misc/log-analytics/import_logs.py –url=http://www.aboo.pl/piwik –idsite=3 –recorders=2 –enable-http-errors –enable-http-redirects –enable-static –enable-bots -dd /var/log/nginx/aboo.pl.access.log 

Testowo należy uruchomić ją z powłoki (polecamy opcje –dry-run –show-progress), następnie dodać do crontaba przed wywołaniem logrotate dla Nginx.

Nginx jako reverse proxy dla Apache z Zend Platform

Na naszych serwerach hostingowych  powszechnie wykorzystujemy wysokowydajny serwer http Nginx do serwowania treści statycznych. Zapytania o treści dynamiczne są kierowane przez tzw. reverse proxy do serwera Apache (tutaj: na porcie 8080).

Podstawowa konfiguracja vhosta Nginx dla tych potrzeb będzie wyglądać podobnie do poniższej.
Domyślnie kieruje ona zapytania na adres 127.0.0.1:8080 przekazując dane o kliencie oraz domenę z żądania.
Treści potencjalnie statyczne są serwowane bezpośrednio z odpowiedniego katalogu, przy czym zostało zablokowane hotlinkowanie.

server {
server_name aboo.pl *.aboo.pl

access_log /var/log/nginx/aboo.pl.access.log;
error_log /var/log/nginx/aboo.pl.error.log;
location ~ /\\.ht {
deny all;
}

location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
client_max_body_size 1000m;
client_body_buffer_size 512k;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 32k;
proxy_buffers 16 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
proxy_connect_timeout 60s;
proxy_pass http://127.0.0.1:8080;
}

location ~* ^.+.(jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|iso|doc|
xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|mp3|ogv|ogg|
flv|swf|mpeg|mpg|mpeg4|mp4|avi|wmv|js|css)$ {
expires 24h;
root /srv/vhosts/aboo.pl;
valid_referers none blocked aboo.pl *.aboo.pl;
if ($invalid_referer) {
return 403;
}
}

W konfiguracji Apache (/etc/apache2/ports.conf) zmieniamy port, po czym ew. poprawiamy konfigurację vhostów:

NameVirtualHost 127.0.0.1:8080
Listen 8080

Przy tej konfiguracji access log Nginx trafi do /var/log/nginx/aboo.pl.access.log.