VestaCP: ārējā MySQL servera pievienošana (remote DB)
Ārēja MySQL (vai MariaDB) datubāzes servera izmantošana ir tipisks solis, kad viena servera resurss sāk kļūt par šauru vietu: web serveris un PHP aplikācija patērē CPU/RAM, bet datubāze paralēli prasa savus resursus, diska IOPS un kešatmiņu. Atdalot datubāzi uz atsevišķu serveri, jūs iegūstat labāku veiktspēju, vienkāršāku mērogošanu un skaidrāku drošības modeli. VestaCP ļauj strādāt ar “ārējo DB hostu” scenāriju, bet pareizai darbībai svarīgi ir arī tīkla un MySQL drošības iestatījumi.
Šī pamācība parāda praktisku ceļu: ko sagatavot datubāzes serverī, ko iestatīt VestaCP pusē, kā atvērt piekļuvi tikai vajadzīgajam IP, kā pārbaudīt savienojumu un kā izvairīties no biežākajām kļūdām. Visbiežāk šādu arhitektūru būvē uz VPS: vienu VPS web/aplikācijai un otru VPS datubāzei. Ja slodze ir augsta vai nepieciešama maksimāla I/O veiktspēja, var izvēlēties serveru īri. Ja jums vēl nav domēna un vajag sakārtotu vidi, kurā aplikācija tiek hostēta, noder arī domēnu reģistrācija (un pēc tam DNS/hostinga piesaiste).
1) Kad ir jēga pārcelt MySQL uz atsevišķu serveri
Ārēju DB parasti izvēlas, ja: (1) lapas kļūst lēnas pie pīķa slodzēm un redzams, ka MySQL “ēd” CPU vai I/O, (2) jums ir vairākas aplikācijas, kurām ērti izmantot vienu DB klasteri vai atsevišķu DB serveri, (3) jums vajag drošības segmentāciju (web serveris publiski, DB tikai privātajā tīklā), (4) vēlaties vienkāršāku backup politiku DB līmenī. Ja jūsu vietne maza, šis solis var būt pāragrs, jo palielina sarežģītību.
Atcerieties: atdalīta DB ievieš tīkla latentumu. Ja aplikācija veic tūkstošiem mazu vaicājumu, attālums līdz DB var ietekmēt. Tāpēc bieži izmanto privāto tīklu (iekšējais VLAN, VPN, vai datu centra iekšējā saite), nevis publisko internetu. Ja DB ir publiski pieejams, drošība kļūst kritiski svarīga.
2) Datubāzes servera sagatavošana: bind, lietotājs, atļaujas
Pirmais solis DB serverī ir pārliecināties, ka MySQL klausās pareizajā interfeisā. Pēc noklusējuma tas bieži klausās tikai uz 127.0.0.1 (lokāli). Lai atļautu pieslēgšanos no web servera, jāiestata bind-address uz servera privāto vai publisko IP (vai 0.0.0.0, ja kontrolējat piekļuvi ar ugunsmūri). Konkrētā faila atrašanās vieta atšķiras (mysqld.cnf, my.cnf), bet princips ir viens.
# piemērs: /etc/mysql/mysql.conf.d/mysqld.cnf (Debian/Ubuntu) bind-address = 0.0.0.0
Pēc izmaiņām pārstartējiet MySQL/MariaDB servisu. Nākamais solis: izveidojiet DB lietotāju, kuram ir tiesības pieslēgties no konkrēta IP (web servera). Tas ir svarīgi drošībai: nelietojiet '%' (jebkurš hosts), ja varat precīzi norādīt IP.
CREATE USER 'appuser'@'WEB_SERVER_IP' IDENTIFIED BY 'StrongPasswordHere'; GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'WEB_SERVER_IP'; FLUSH PRIVILEGES;
Ja jums ir vairāki web serveri, varat izveidot atsevišķus lietotājus katram IP vai izmantot IP diapazonu (piesardzīgi). Pārliecinieties, ka parole ir unikāla un pietiekami gara. Nekad nelietojiet MySQL root lietotāju attālai pieslēgšanai no aplikācijas.
3) Ugunsmūris un tīkla piekļuve: atveriet tikai nepieciešamo
MySQL ports parasti ir 3306. Ja DB atrodas publiskā tīklā, atveriet 3306 tikai no web servera IP (vai no jūsu privātā tīkla). Tas samazina risku, ka DB tiks bruteforce skenēts. Dažos gadījumos drošākais ir vispār neatvērt 3306 publiski un savienot serverus ar VPN vai privātu tīklu.
Praktiski piemēri (atkarībā no jūsu ugunsmūra): ļaut 3306 no WEB_SERVER_IP un aizliegt pārējo. Papildus varat izmantot fail2ban vai rate limit, bet pirmais aizsardzības slānis ir IP ierobežojums. Ja izmantojat mākoņa ugunsmūri vai datu centra ACL, iestatiet to tur — tas bloķē trafiku vēl pirms tas sasniedz OS.
4) VestaCP pusē: ārējā DB hosta izmantošana
VestaCP standarta plūsmā datubāzes tiek veidotas lokāli uz tā paša servera. Lai strādātu ar ārēju DB, jums ir jānorāda aplikācijai (piem., WordPress wp-config.php vai .env failā), ka DB host ir ārējā servera hostname/IP. VestaCP pats par sevi var izveidot DB lietotājus lokāli, bet ārējā DB gadījumā lietotājs un datubāze tiek veidoti DB serverī. Tāpēc galvenais “VestaCP solis” ir pareizi ievadīt datus aplikācijas konfigurācijā.
Praktisks piemērs: WordPress gadījumā DB_HOST jābūt “DB_SERVER_HOST:3306” (ja ports nav noklusējuma vai ja vēlaties skaidrību). Lietotājvārds un parole ir tie, ko izveidojāt DB serverī, un DB nosaukums ir attiecīgā datubāze. Ja izmantojat vairākas vietnes, katrai ieteicams atsevišķa datubāze un atsevišķs lietotājs (vismaz atsevišķas privilēģijas), lai izolētu riskus.
Ja jums tomēr vajag VestaCP interfeisā “skaistu” DB pārvaldību, bieži izvēlas: VestaCP nodrošina phpMyAdmin uz web servera, bet tas pieslēdzas ārējam DB hostam. Tas ir ērti, taču atcerieties, ka phpMyAdmin pats par sevi kļūst par kritisku punktu: aizsargājiet to ar IP ierobežojumu vai papildus autentifikāciju un vienmēr izmantojiet HTTPS.
5) Šifrēšana starp serveriem un “privātais tīkls”
Ja web un DB sazinās pa publisko internetu, apsveriet savienojuma šifrēšanu. MySQL atbalsta TLS, bet konfigurācija atkarīga no jūsu distro un sertifikātu pārvaldības. Vienkāršāks variants bieži ir savienot serverus caur VPN (piem., WireGuard) un izmantot privāto IP. Tas samazina gan risku, gan arī bieži dod stabilāku latentumu datu centra iekšienē.
Ja izmantojat TLS MySQL līmenī, pārliecinieties, ka klients verificē sertifikātu, nevis vienkārši “encrypt without verification”. Pretējā gadījumā jūs iegūstat šifrēšanu, bet ne autentiskumu. Biznesa vidē tas ir būtiski, īpaši ja pārraidāt sensitīvus datus.
6) Testēšana un diagnostika
Vispirms pārbaudiet savienojumu no web servera uz DB serveri ar vienkāršu klienta komandu. Ja tas strādā, problēma parasti ir aplikācijas konfigurācijā. Ja tas nestrādā, vaina ir tīklā, ugunsmūrī vai MySQL lietotāja host atļaujās.
mysql -h DB_SERVER_HOST -P 3306 -u appuser -p
Ja saņemat “Access denied”, pārbaudiet, vai lietotājs ir izveidots tieši no WEB_SERVER_IP (vai pareizā hosta), un vai parole ir pareiza. Ja saņemat “Can’t connect”, pārbaudiet ugunsmūri, bind-address un to, vai ports klausās (ss -lntp | grep 3306). Tāpat pārbaudiet DNS, ja izmantojat hostname.
Veiktspējas testam skatieties MySQL slow query log un aplikācijas vaicājumu skaitu. Atdalīta DB parasti dod ieguvumu, ja problēma ir resursu konkurencē un I/O, bet, ja problēma ir slikti optimizēti vaicājumi, to vajag risināt ar indeksiem, kešu un koda uzlabojumiem. Ārējais DB nav burvju nūjiņa, bet labs arhitektūras instruments.
Labākā prakse, drošības punkti un biežākās kļūdas
Galvenā drošības kļūda ir atvērt MySQL uz visu internetu un atļaut lietotājus ar '%' hostu. Pareizais modelis: DB nav publisks, vai arī 3306 ir atvērts tikai no konkrētiem IP, un katrai aplikācijai ir savs lietotājs ar minimālajām nepieciešamajām privilēģijām. Otrs risks ir izmantot root vai vienu kopīgu lietotāju visām vietnēm. Tas sarežģī incidentu analīzi un palielina “sprādziena” zonu, ja kaut kas tiek kompromitēts.
No veiktspējas puses: izvairieties no tā, ka DB serveris ir daudz vājāks nekā web serveris, citādi jūs vienkārši pārvietosiet šauro vietu. Plānojiet RAM (InnoDB buffer pool), diska IOPS un backup logiku. Ja jums vajag augstāku garantētu veiktspēju, apsveriet dedicated serveri DB slānim. Un pirms migrācijas izveidojiet rollback plānu: kā atgriezīsieties uz lokālo DB, ja kaut kas neizdodas.
Ja jūs ievērojat šos principus, ārējais MySQL serveris var būt ļoti stabils risinājums: vieglāk mērogot, vienkāršāk auditēt, un bieži arī ātrāk pie reālām slodzēm. Svarīgākais ir disciplinēti iestatīt piekļuves kontroli un vienmēr sākt ar testu no web servera uz DB, pirms maināt aplikācijas konfigurāciju.