Analisa Sistem dan Infrastruktur untuk pemecahan masalah ( khusus pemula )

halo semua, seperti biasa, nulis untuk kebutuhan catatan saja bagi saya. atau bisa juga sebagai Portofolio, kali aja artikel saya ini di lirik sama seseorang yang sedang membutuhan jasa saya. hehehe wkwkwk. judulnya itu analisa sistem dan infrastruktur untuk pemecahan masalah.

oiya, artikel ini khusus pemula, untuk yang sudah Pro = Profesional, jangan dibaca. karena saya bisa diketawain. wkwkwkwkw begitu. karena ini analisa abal-abal alias sembarangan. saya sendiri baru pertama kali melakukan analisa se kompleks ini. permasalah ini sudah beberapa bulan terjadi, dan saya baru sempat nulisnya sekarang.

berawal dari laporan client, bahwa aplikasinya lambat di akses. errornya itu lo yang bikin menarik. :

error tcp

error tcp

dari error diatas, rata-rata mahluk hidup di muka bumi ini pasti menduga ada masalah dengan jaringan, lalu mereka akan berasumsi bahwa bandwith di servernya bermasalah. karena mereka buka yutub aman kok, dan web-web lain aman. bandwith servernya nih pasti. gitchu~~~

btw, wait… eh, itu di akses jam 11 malam loh, (lihat pojok kiri atas). harusnya, jam segitu bandwith server gak tinggi. oke deh, untuk memanstikan, saya terpaksa hubungi pihak provider, apakah benar, pada jam segitu bandwith mentok. dan jawabannya, tidak. mentoknya kalo siang wkwkwkw.

oke, kita bahas yang benerannya, error tersebut terjadi karena ada lost koneksi dari client (HP) ke server aplikasi. penyebabnya ? bisa jaringan di client, jaringan di server, query, bandwith, daaaaaaaann server yang terlalu sibuk, gak tau deh ngapain dan lain-lain, banyak deh. oke, kita eliminasi masalah, ini yang penting, bisa eliminasi. seperti indonesian idol aja ya. wkwkkw

A. eliminasi permasalahan

  1. internet client bermasalah? tidak mungkin. karena doi bisa buka yutub dan web web lain
  2. trafik network server bermasalah, ? tidak mungkin juga. karena itu diakses jam 11 malam, yang begitu di konfirmasi ke pihak provider juga aman.
  3. logic dari aplikasi, ? bisa jadi. mari kita cek untuk memastikan.
  4. utilitas server bermasalah ? bisa jadi, mari kita cek untuk memastikan.

B. cek utilisasi server

kemudian, saya akses server. hal pertama yang dilakukan adalah ketik htop . wkwkw, ini perintah paling lazim dilakukan untuk liat kondisi server.

dan ternyata, benar… resourcenya CPU nya tinggi banget. nah, ada apa ini ? wah wah.. kok bisa. ini yang bikin error disisi usernya

mentok cuk

mentok cuk

wealah, kok bisa ya CPU 16 core mentok. ini server ngapain ya ? seperti sedang dipakai mining Bitcoin ajah, wkwkkw. sek. kok ya jadi kepikiran ya mining Bitcoin pake server, lumayan juga buat nambah asupan gizi dimasa pandemi gini, wkwkwkw. wes wes sadar.

agak aneh bagi saya, dan bagi teman-teman yang saya tanyai. apalagi setelah melihat dari fungsi aplikasi, kegunaan, jumlah user akses, dan logicnya. 16 core VCPU harusnya udah lebih dari cukup.

nah, bagi orang yang panikan, biasanya langsung buru-buru untuk menjustifikasi masalah pada cpu yang penuh, dan harus di tambah, tidak main-main, 4 kali lipat sekaligus. wew, emangnya mau bikin Data Center Bos pakai 64 core ??? 😀 lagian, belum tentu kan masalahnya teratasi ????. tenang, mari kita cari tau masalahnya lebih dalam.

C. cek aplikasi yang memakan resource

ada dua aplikasi yang tertinggi memakan resource dari server tersebut, yang pertama database, yang kedua web server. saya melakukan penangkapan slow query log pada kedua aplikasi tersebut. yang pertama backend web server hasilnya :

Screenshot_2

benar, aplikasi tersebut menggunakan engine php untuk menjalankannya. perlu diingat, php itu bukan akronim dari Pemberi Harapan Palsu , ya.

dari error php tersebut mengarah ke database.

Screenshot_1

benar, satu query di eksekusi sampai dengan 15 -20 detik, panteslah error disisi clientnya TCP error.karena server gagal melayani permintaan dari client.

sampai disini, sysadmin harus berkomunikasi dengan Programmer dan Database Engineer. harus ada hubungan yang harmonis antara ketiga elemen tersebut.

hubungan ini tidak akan terjadi jika sebuah project hanya di handle oleh satu orang saja. biasa di sebut Full Stack Developer. dia programmernya, dia database enginernya, dia juga sysadminnya. bisa mabok darat doi. wkwkwkw

sysadmin menanyakan kepada Database engineer, apakah query pada aplikasi sudah di sederhanakan secara maksimal. jika jawabannya sudah, namun masih terdapat error slow query log. maka harus mencari penyebab lainnya.

D. pengecekan di sisi perangkat.

pengecekan dilanjutkan disisi perangkat. yang berhubungan dengan itu adalah perangkat Input Output. ada dua, NIC dan Disk. saya cek NIC terlebih dahulu. setelah di cek, NIC dalam kondisi baik. NIC dengan 10 Gbps dapat dilewati dengan mulus oleh data-data yang di transfer.

kemudian say cek Disk. untuk cek disk, bisa menggunakan hdparm, fdisk, dll, banyak toolsnya, disini saya menggunakan fio. yaitu aplikasi untuk mengecek Read & Write pada Disk. dan, setelah di cek ini hasilnya :

iops

iops

FYI, server ini masih menggunakan HDD , IOPS segitu untuk digunakan aplikasi yang trafik dan Read Write datanya tinggi, sangat jelek, bahkan bisa dikatakan jeblok. lihat saja Readnya, hanya 38.

beberapa orang yang pasrah dengan keadaan, maksudnya ya hanya punya server itu dan gak mungkin upgrade, maka akan mengakali dengan memecahnya menjadi banyak bagian aplikasi pada server.

untuk aplikasi, bisa menggunakan teknologi kekinian yang biasa di kenal Microservices. bisa di baca disini : https://medium.com/codelabs-unikom/microservices-apaan-tuh-b9f5d56e8848

untuk database, bisa upgrade ke yang lebih mumpuni untuk pengolahan data besar, Postgresql, atau Monggo DB lebih sangat bagus. setelah itu di cluster. Read dan Write database di pisah, menggunakan Proxy. pasti akan jadi pekerjaan berat nan keren. ya gimana lagi, adanya server itu. wkwkwkw

solusi yang kedua, upgrade SSD, maka masalah IOPS beres. begini penampakan IOPS yang menggunakan SSD

iops2

jauh banget kan ya ? hehehe

oke. lanjut.

pada kasus ini, server sudah upgrade menggunakan SSD, dan ternyata, aplikasi sudah beres, aman dan kenceng.

coba deh di lihat CPU nya, pasti tidak load mentok lagi. karena query yang di Read dan Write di Dsik tidak antri, tidak lama lagi waktunya, otomatis, CPU juga tidak bekerja keras lagi. dan loadnya menurun.

sampai disini saya tidak cek server lagi dari sisi sistem Operasi, karena sudah di handle oleh sysadminnya. saya hanya menyediakan SSD.

jadi, tidak perlu upgrade CPU kan ? bayangkan saja jika harus upgrade CPU, larang regone Rekkkkkk. dan kerjaannya ribet Rekkkk. kudu backup data, matiin server, bongkar, halah, mumet. semetara aplikasi diburu kudu running dan yang lebih kacau, bisa jadi setelah upgrade CPU masalah tidak teratasi.

Mal Praktek Rekkkk jenenge neng dunia kedokteran. 😀

yoweslah, sekian aja, yang penting client udah tersenyum lebar karena aplikasinya udah aman. disitu saya merasa dipuasin oleh client . walaupun clientnya LANANGAN.

Bagikan saja, itu tidak berat

High avaibility moodle server using nginx load balancer and nfs server

nah loh, judulnya pakai bahasa inggris , yaitu High avaibility moodle server using nginx load balancer and nfs server , biar keren aja sih, karena saya akan tetap menulisnya dalam bahasa indonesia, saya kan cinta negeri ini, hehehe

oiya, hari ini saya sedang cukup bahagia, sebabnya saya iseng-iseng cek judul artikel, eh, muncul di page one nya google. gimana gak bahagia coba, artikel saya bersaing paling banyak di lihat dengan website-website kelas kakap di dunia. hahaha.

http://mandrivaputri.info

http://mandrivaputri.info

artikel yang mana ? yang ini http://mandrivaputri.info/2018/07/cara-load-balancing-web-server-dengan-haproxy-dan-glusterfs/

nah, artikel yang saya tulis ini adalah sambungan dari artikel diatas, hanya berbeda metode dan kebutuhan. maksudnya tetap sama.

selamat membaca dan selamat berbahagia untuk kalian yang sedang berlibur panjang dengan keluarga. salam hangat dari saya yang tersandar sendirian di kamar kosan. apalah daya, keluarga jauh. semoga harapan kita semua bisa tercapai 🙂 🙂 🙂 🙂 🙂 😉 😉 🙁 🙁 ;'(

jadi, saya mendapatkan tugas, ya sekalian saya anggap sebagai tantangan, sejauh mana kemampuan otak dan tenaga saya mampu menyelesaikan tugas tersebut.

tugasnya adalah : membangun dan mengoptimasi website learning manajement system dengan moodle

sebelumnya, website ini sudah ada, tapi diaksesnya lambat, dan terdapat beberapa trouble yang lumayan bikin bingung untuk mengatasinya.

sebelum melakukan aksi, terlebih dahulu saya menggali informasi tentang aplikasi tersebut, khususnya user akses. yang perlu di ketahui adalah :

  1. berapa banyak user yang akan mengakses aplikasi tersebut ?
  2. apakah random, atau concurrent ?
  3. berapa besar BW internet yang tersedia?
  4. berapa besar resource server yang tersedia ?

dari analisa diatas, dapat dihitung kebutuhannya. misalnya BW yang dibutuhkan, jumlah core CPU, jumlah RAM dan disk. disini saya memutuskan awal menggunakan total RAM 15 GB , CPU 4 core pada setiap server.

setelah melakukan analisa, saya mulai mengeksekusi tugas tersebut. oh, hal ini yang dinamakan analis sistem. tugasnya seorang sistem analis, tapi pada kasus kebanyakan, yang analis juga yang mengeksekusi, wkwkwkw. ya gapapalah, yang penting nambah ilmu, minimal jadi portofolio kali aja saya ditendang dari sini dan pindah ke tempat baru hahahaha

solusi dari permasalah diatas adalah saya menawarkan load balancing server. karena menggunakan moodle, yaitu sebuah aplikasi open source, maka kita tidak terlalu banyak bisa mengoptimasi sari sisi codingnya.

nah, mahalnya disini. ketika ada solusi. 😀 , kalau eksekusi kan hanya tinggal jalankan saja.

load balancing adalah membagi beban aplikasi yang di distribusikan ke beberapa server. 

begini diagramnya.

begini diagramnya.

metode diatas menggunakan tiga buah server apps, satu buah server load balancer, satu buah server database, dan satu buah server NFS. akan lebih baik jika server databasenya juga ada tiga, di cluster. tapi ya itu nantilah, dipengembangan berikutnya, dan seberapa penting ini aplikasi digunakan :p

senjata yang saya gunakan adalah :

  1. nginx
  2. nfs
  3. postgresql
  • server load balancer IP 192.168.85.10
  • server A IP 192.168.85.1
  • server B IP 192.168.85.2
  • server C IP 192.168.85.3
  • server NFS IP 192.168.87.3
  • server database IP 192.168.87.4

A. install dan konfig server load balancer

yang pertama adalah instalasi nginx load balancer pada server load balancer. ini instalasi nginx seperti biasa, hanya script untuk configurasinya menggunakan load balancer dengan metode round robind. yang pernah kuliah harusnya tau nih :p . ada beberapa metode, seperti least conn, ya tergantung kebutuhan aja sih, silangkan di explore.

ant@loadbalancer:~$ yum update -y

ant@loadbalancer:~$ yum install -y nginx

ant@loadbalancer:~$ systemctl enable nginx

ant@loadbalancer:~$ systemctl start nginx

ant@loadbalancer:~$ systemctl status nginx

 

nginx

nginx

membuat script configurasi vhost pada nginx

ant@loadbalancer:~$ vi /etc/nginx/conf.d/loadbalancer.conf

isinya :

upstream backend {

server 192.168.85.1;
server 192.168.85.2;
server 192.168.85.3;
}

server {
listen 80;
server_name xxxx.id;
return 301 https://$server_name$request_uri;
location / {
proxy_buffering on;
proxy_buffer_size 1k;
proxy_buffers 24 4k;
proxy_busy_buffers_size 8k;
proxy_max_temp_file_size 2048m;
proxy_temp_file_write_size 32k;
proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass https://backend;
}
}

upstream backendssl {

server 192.168.85.1:443;
server 192.168.85.2:443;
server 192.168.85.3:443;
}

server {
listen 443 ssl;
server_name xxxx.id;
ssl_certificate /etc/nginx/serti/bundle.crt;
ssl_certificate_key /etc/nginx/serti/priv.key;

location / {
proxy_buffering on;
proxy_buffer_size 1k;
proxy_buffers 24 4k;
proxy_busy_buffers_size 8k;
proxy_max_temp_file_size 2048m;
proxy_temp_file_write_size 32k;
proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass https://backendssl;
}
}

 

disini, SSL dari aplikasi akan di handle oleh server loadbalancer.

B. Instalasi nginx pada semua server A,B,C

ant@server-A:~$ yum update -y

ant@server-A:~$ yum install -y nginx

ant@server-A:~$ systemctl enable nginx

ant@server-A:~$ systemctl start nginx

ant@server-A:~$ systemctl status nginx

membuat konfigurasi vhost pada server A,B dan C

server {
listen *:443 ssl;
listen [::]:443 ssl;
root /usr/share/nginx/html/moodle/moodle/;
index index.php index.html index.htm;
server_name 192.168.85.1;

ssl_certificate /etc/nginx/serti/bundle.crt;
ssl_certificate_key /etc/nginx/serti/priv.key;

location / {
try_files $uri $uri/ =404;
}

location /dataroot/ {
internal;
alias /data/moodledata/;
}

location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_index index.php;
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;
include fastcgi_params;
proxy_buffering on;
proxy_buffer_size 1k;
proxy_buffers 24 4k;
proxy_busy_buffers_size 8k;
proxy_max_temp_file_size 2048m;
proxy_temp_file_write_size 32k;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

}

disini, moodledata diarahkan pada server NFS.

C. instalasi postgresql server.

ant@db-server:~$ rpm -Uvh https://yum.postgresql.org/11/redhat/rhel-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm

ant@db-server:~$ yum -y install postgresql11-server postgresql11

ant@db-server:~$ /usr/pgsql-11/bin/postgresql-11-setup initdb

ant@db-server:~$ systemctl enable postgresql-11.service

ant@db-server:~$ systemctl start postgresql-11.service

konfigurasi agar server database postgresql dapat di akses dari luar server. tutorialnya banyak di google, hehe

D. instalasi dan konfigurasi server NFS ke server A,B,C

ant@nfs-server:~$ yum install nfs-utils

ant@nfs-server:~$ mkdir /data/moodledata

ant@nfs-server:~$ vi /etc/exports

/data/moodledata 192.168.85.1(rw,sync,no_root_squash,no_all_squash)
/data/moodledata 192.168.85.2(rw,sync,no_root_squash,no_all_squash)
/data/moodledata 192.168.85.3(rw,sync,no_root_squash,no_all_squash)

ant@nfs-server:~$ systemtl enable nfs-server

ant@nfs-server:~$ systemctl start nfs-server

disini, saya membuat folder /data/moodledata untuk di mount ke server A,B,C

E. mounting disk pada server NFS ke server A,B,C

ant@nfs-server:~$ mkdir /data

ant@nfs-server:~$ mount 192.168.87.3:/data/moodledata /data

tambahkan script ini agar auto mount saat server restart

ant@nfs-server:~$ vi /etc/fstab

192.168.87.3:/data/moodledata /data nfs  defaults    0       0

cek, apakah disk server NFS sudah termount dengan perintah df -h

Screenshot_24

fuih,, capek ya. selanjutnya, siap untuk instalasi moodle nya.

oiya, saya males nulis tutorial install moodle, karena sudah banyak di internet, bisa di pelajari disini : https://docs.moodle.org/39/en/Installing_Moodle

yang perlu diperhatikan pada saat instalasi moodle :

  1. pastikan database sudah di buat di server database postgresql
  2. arahkan moodledata pada folder /data
  3. arahkan database pada IP 192.168.87.4

udah, sekian dulu, kalau tidak berhasil alias gagal, coba di perhatikan gagalnya dimana, atau bisa bertanya pada kolom komentar ya. capek banget saya nulisnya wkwkwkwk.

sekian dulu tulisan tentang High avaibility moodle server using nginx load balancer and nfs server.

sampai bertemu di lain artikel…. :*

 

 

Bagikan saja, itu tidak berat

Postgresql database auto restore

Halo, hari yang lelah, setelah membuat automation dump restore database mariadb/mysql, kali ini membuat script untuk auto dump dan restore untuk database Postgresql.

saya tidak akan mengulang, saya mau merujuk dari artikel saya sebelumnya : http://mandrivaputri.info/2020/08/membangun-data-ware-house-yang-aman/

artikel diatas memang sulit di pahami, karena basic nya saya memang bukan penulis apalagi pengajar, wkwkwkw, tapi setidaknya ini catatan bagi saya jika suatu saat ada pekerjaan serupa, jadi saya bisa lihat lagi dokumentasi saya. atau catatan ini bisa jadi portofolio saya jika saya hendak melamar pekerjaan di tempat lain :p

langsung saja ke script yah, script ini di jalankan di server :

{DATA WARE HOUSE}

yang pertama, kamu pastikan dulu kalau database server untuk postgresqlnya sudah terinstall.

bisa membaca artikel disini : https://computingforgeeks.com/how-to-install-postgresql-12-on-centos-7/

setelah itu, jalankan script dan cronjobnya pada user postgres

[root@db-warehouse ~]# su postgres

bash-4.2$ vi importpostgre.sh
#import db postgre
echo “halo bos”
dropdb database
createdb database
echo “buat db selesai”
cd /home/postgre/db
tar -xf *.tar.bz2
echo “extrac rampung”
rm -rf *.tar.bz2
echo “tar bz sudah di hapus”
for i in `find /home/postgre/db -type f -ctime -1`
do
psql database < $i
done
cd /home/postgre/db
rm -rf *
echo “rampung”

nah, jadi seperti itu scriptnya. jalankan di cronjob pada user postgres.

bash-4.2$ crontab -e

ya pokoknya gitulah, hehehe :*

Bagikan saja, itu tidak berat

Membangun data Ware House yang aman

Halo, kebetulan saat ini saya sedang membangun sebuah data Ware House.

apa itu data ware house ? yaitu sekumpulan database dari bermacam aplikasi yang di kumpulkan dalam satu server.

tujuan adalah untuk melakukan pengolahan data yang sumber datanya di ambil dari bermacam aplikasi tersebut. besar dong ? tentu, namanya juga ware house = gudang data.

kenapa tidak dilakukan pengolahan langsung di aplikasinya ? -sudah, tapi terkadang ada kebutuhan khusus diluar dari aplikasi. karena untuk melakukan perubahan di Production aplikasi sangat tidak di sarankan. SANGAT TIDAKKKKKKKK. JANGAN, TIDAK BOLEH. TITIK.

caranya bagaimana, ? logikanya simple, implementasinya yang gak simple wkwkwkwk

bahan-bahan yang di butuhkan :

1. server Production Aplikasi

2. server backup

3. server data ware house

tahapannya adalah :

{SERVER PRODUCTION}

  1. melakukan backup rutin pada server aplikasi production, caranya : http://mandrivaputri.info/2019/07/membuat-auto-backup-database-server-mariadb/

hal diatas dilakukan di semua server aplikasi yang ingin ditarik databasenya. oh ya, tutorial diatas adalah server dengan database mysql. jika databasenya berbeda, postgre misalnya, lakukan backup dengan cara yang ada di gugel, gampang, asalkan mau.

{SERVER BACKUP}

2. menarik ( get ) database hasil backup di server aplikasi production ke server backup, ini pakai rsync. contohnya seperti ini :

rsync -rzhav –update -e ‘ssh -p 220’ root@192.168.10.3:/home/centos/backupdb/ /data/192.168.10.3/db/

script diatas adalah contoh. jalankan ini di server backup, jalankan di cronjob secara rutin pakai bash script. cara nya cari di google, banyak.

kemudian, mengirim file hasil tarikan di server backup ke server Data ware house.

Screenshot_71

oh iya, siapa bilang sysadmin itu gak perlu ngerti programming. sysadmin harus ngerti programming, komunikasi antar mesin, itu perlu programming, bahasa pemograman yang sering digunakan untuk mesin adalah Python dan Shell Script. diatas adalah sedikit contoh bahasa pemograman shell script dengan bash command.

soalnya saya nyari-nyari di google gak nemu, akhirnya saya bongkar kitab lama saya. hahaha

saya jabarkan code diatas :

untuk i , temukan file yang modifikasi waktunya -1 hari di dalam folder /data/192.168.10.3/db

lalu

kirim data yang di temukan tersebut ke user root yang berada di server 192.168.11.4 di folder /root/db

selesai

{SERVER DATA WARE HOUSE}

setelah server Data ware house menerima kiriman backup database server Production dari server Backup, server Data Ware House bertugas untuk melakukan import database kiriman itu ke database server di Server Data Ware House. bingung ? ngopi dulu gih~~

saya membuat sebuah bash script yang saya jalankan secara rutin. oiya, timing waktu sangat penting, antara :

-server production melakukan backup internal

-server backup menarik data dari server production

-server backup mengirim data ke server data ware house

-server data ware house melakukan import database

timing waktu harus di perhatikan agar tidak miskom. hehehe

begini scriptnya :

Screenshot_72

penjabaran :

baris pertama : melakukan penghapusan database

baris kedua : membuat database baru

baris ketiga : untuk i , temukan file yang modifikasi waktunya -1 hari di dalam folder /root/xxx

baris ke empat : maka

baris ke lima : import file database hasil backupan di folder i ke database server

baris ke enam : selesai

baris ke tujuh : masuk ke folder /root/xxx

baris ke delapan : hapus semua file di folder tsb.

sampai disini, data ware house sudah selesai di bangun, kamu bebas mengolah data di data ware house tersebut tanpa harus menyentuh database aplikasi production. lebih aman bukan ?

disini kamu bisa mengolah data dengan melakukan query, terserah, mau pakai PHP, atau pun tools pengolah data seperti tableau.

sistem ini berjalan secara automatic, data di update sesuai dengan data asli di aplikasi production dengan waktu yang di tentukan oleh cronjob.

kamu tinggal bobok manis, biarkan tim pengolah data yang menggunakan layanan ini, kamu paling tinggal troubleshoot tipis-tipis aja kalau ada masalah. 🙂

Bagikan saja, itu tidak berat