در حالت عادی می‌توان هر ایمیلی را با هر فرستنده‌ای که دوست داشته باشید
به هر فردی ارسال کنید. اما mail server که درست تنظیم شده باشد همچون gmail و یاهو ip ایمیل دریافتی را با رکورد spf که صاحب دامین آن را تعریف کرده، تطبیق می‌دهند و در صورت ناهمخوانی ایمیل مستقیم به بخش اسپم می‌رود و غیر از آن یک نوشته را به کاربر نمایش می‌دهند که احتمال فیشینگ ایمیل وجود دارد.

برای تست همه این موارد نیاز به یک SMTP سرور (برای مثال smtp.novid.ir:587) و تعریف چند کاربر (admin@novid.ir و info@novid.ir) و همینطور ایجاد پسورد برای آنها داریم. ایمیل‌های تست به آدرس novid@protonmail.com  ارسال می‌شود. برای تست حالت‌های مختلف از ابزار قدرتمند SWAKS استفاده خواهیم کرد.

ارسال ایمیل بدون احراز هویت

اگر SMTP سرور به درستی کانفیگ نشود، هر فردی بدون احراز هویت قادر به ارسال ایمیل از طریق آن خواهد بود. به اینگونه سرورها در اصطلاح open mail relay گفته می‌شود.

با استفاده از ابزار SWAKS و بدون وارد کردن یوزر و پسورد سعی در اسال ایمیل می‌کنیم.
در صورت موفقیت در ارسال ایمیل، انتظار این رو داشته باشید که سرور به زودی در لیست سیاه قرار خواهد گرفت و تا مدت‌ها دیگر نخواهید توانست میل بفرستید.

novid@novid-salavan ~ $ swaks -t novid@protonmail.com -s smtp.novid.ir:587 -tls --from admin@novid.ir
=== Trying smtp.novid.ir:587...
=== Connected to smtp.novid.ir.
<- 250 STARTTLS
-> STARTTLS
<- 220 2.0.0 Start TLS
=== TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
=== TLS no local certificate set
=== TLS peer DN="/CN=smtp.novid.ir"
~> EHLO novid-salavan
<~ 250 AUTH PLAIN
~> MAIL FROM:<admin@novid.ir>
<~* 530 5.7.1 Authentication required
~> QUIT
<~ 221 2.0.0 Bye
=== Connection closed with remote host.

• آپشن t یا همان to ایمیل فرد دریافت کننده است.
• s یا همان server، آی‌پی یا آدرس smtp سرور مد نظر است که در اینجا از طریق پورت 587 قصد وصل شدن به آن را داریم.
  پورت ۲۵ رو بسیاری از دیتاسنترها بسته‌اند و به دلیل امن نبودن، استفاده از آن توصیه نمی‌شود.
• با استفاده از آپشن tls، کانکشن به smtp سرور به شکل STARTTLS برقرار می‌شود.
• با آپشن from ایمیل فرستنده را مشخص می‌کنیم.

معمولا خط بالای QUIT مشکل اصلی در عدم ارسال ایمیل را می‌گوید.

<~* 530 5.7.1 Authentication required

تست باز یا بسته بودن پورت ۲۵ SMTP سرور

برای تست پورت ۲۵، کامند زیر را اجرا می‌کنیم.
به شکل پیشفرض swaks از پروتکل امن esmtp جهت اتصال به سرور استفاده می‌کند.

novid@novid-salavan ~ $ swaks -t novid@protonmail.com -s smtp.novid.ir:25 --protocol smtp --from admin@novid.ir
=== Trying smtp.novid.ir:25...
*** Error connecting to smtp.novid.ir:25:
*** IO::Socket::INET6: connect: No route to host

که نشان می‌دهد دسترسی به پورت ۲۵ عملا امکانپذیر نیست.

ارسال ایمیل با احراز هویت

برای ارسال ایمیل با یوزر و پسورد کافیست که آپشن a یا همون auth رو به کامند اضافه کنیم.
بعد از زدن اینتر،  یوزر و پسورد به شکل جداگانه پرسیده می‌شود.

novid@novid-salavan ~ $ swaks -t novid@protonmail.com -s smtp.novid.ir:587 --tls -a --from admin@novid.ir
Username: admin@novid.ir
Password: 123456
<- 250 STARTTLS
-> STARTTLS
<- 220 2.0.0 Start TLS
=== TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
=== TLS no local certificate set
=== TLS peer DN="/CN=smtp.novid.ir"
~> EHLO novid-salavan
<~ 250-smtp.novid.ir
<~ 250 AUTH PLAIN
~> AUTH PLAIN AGFkbWluQG5vdmlkLmlyAHJzMm5rZ3NzNQ==
<~ 235 2.0.0 OK
~> MAIL FROM:<admin@novid.ir>
<~ 250 2.1.0 Ok
~> RCPT TO:<novid@protonmail.com>
<~ 250 2.1.5 Ok
~> DATA
<~ 354 End data with <CR><LF>.<CR><LF>
~> Date: Mon, 19 Nov 2018 16:19:41 +0300
~> To: novid@protonmail.com
~> From: admin@novid.ir
~> Subject: test Mon, 19 Nov 2018 16:19:41 +0300
~> Message-Id: <20181119161941.016258@novid-salavan>
~> X-Mailer: swaks v20170101.0 jetmore.org/john/code/swaks/
~> 
~> This is a test mailing
~> 
~> .
<~ 250 2.0.0 Ok: queued as 5203E17BEA6
~> QUIT
<~ 221 2.0.0 Bye
=== Connection closed with remote host.

ارسال ایمیل بدون فعال‌سازی tls

تست رو مجدد بدون tls انجام می‌دیم تا مطمئن شویم تنها راه اتصال به سرور از طریق امن امکان پذیر است.

novid@novid-salavan ~ $ swaks -t novid@protonmail.com -s smtp.novid.ir:587 -a --from admin@novid.ir
Username: admin@novid.ir 
Password: 123456
=== Trying smtp.novid.ir:587...
=== Connected to smtp.novid.ir.
<- 250 STARTTLS
*** Host did not advertise authentication
-> QUIT
<- 221 2.0.0 Bye
=== Connection closed with remote host.

ارسال ایمیل با پسورد اشتباه

کامند را با پسورد اشتباه اجرا و انتظار داریم که ایمیل ارسال نشود.

novid@novid-salavan ~ $ swaks -t novid@protonmail.com -s smtp.novid.ir:587 --tls -a --from admin@novid.ir
Username: admin@novid.ir
Password: 123 
=== Trying smtp.novid.ir:587...
=== Connected to smtp.novid.ir.
<- 250 STARTTLS
-> STARTTLS
<- 220 2.0.0 Start TLS
=== TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
=== TLS no local certificate set
<~ 250 AUTH PLAIN
~> AUTH PLAIN AGFkbWluQG5vdmlkLmlyADEyMw==
<~* 535 5.7.8 Authentication credentials invalid
*** No authentication type succeeded
~> QUIT
*** Remote host closed connection unexpectedly.

ارسال ایمیل با هویت یک فرد دیگر عضو سیستم

تست رو تغییر داده با یوزر و پسورد صحیح کاربر admin ایمیلی از طرف  info بفرستیم.
کافیست که from رو به info تغییر داده و یوزر و پسورد admin رو وارد به ترتیب صحبح وارد نماییم.

novid@novid-salavan ~ $ swaks -t novid@protonmail.com -s smtp.novid.ir:587 --tls -a --from info@novid.ir
Username: admin@novid.ir
Password: 123456
<~ 235 2.0.0 OK
~> MAIL FROM:<info@novid.ir>
<~ 250 2.1.0 Ok
~> RCPT TO:<novid@protonmail.com>
<~* 553 5.7.1 <info@novid.ir>: Sender address rejected: not owned by user admin@novid.ir
~> QUIT
<~ 221 2.0.0 Bye
=== Connection closed with remote host.

ارسال ایمیل با هویت فردی که عضو سیستم نیست

در آخر از طرف فردی که در سیستم وجود ندارد سعی در ارسال ایمیل می‌نماییم.

novid@novid-salavan ~ $ swaks -t novid@protonmail.com -s smtp.novid.ir:587 --tls -a --from null@novid.ir
Username: admin@novid.ir
Password: 123456
<~ 250 2.1.0 Ok
~> RCPT TO:<novid@protonmail.com>
<~* 550 5.1.0 <null@novid.ir>: Sender address rejected: User unknown in virtual mailbox table
~> QUIT
<~ 221 2.0.0 Bye
=== Connection closed with remote host.

پی‌نوشت: خروجی swaks در این مثال‌ها بخاطر حفظ IP اصلی سرور دستکاری شده است.

از اونطرف در صورت استفاده از روتر pfSense این قابلیت خوب رو خواهید داشت که بدون نصب هیچ کلاینت و برنامه‌ی جانبی از این موهبت برخوردار شوید. برای اینکار باید مراحل زیر را در pfSense دنبال نمایید.

ابتدا مطمئن شوید که به شکل عادی pfSense از دی‌ان‌اس‌های کلودفلیر استفاده می‌کند.

برای اینکار در بخش System > General Settings و در بخش DNS Servers آدرس‌های کلودفلیر را وارد می‌کنیم.

برای اینکه به pfSense بگیم که از قابلیت TLS استفاده کند به بخش  Services > DNS Resolver رفته در بخش Display Custom Options متن زیر رو بگذارید.

server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853

در صورتیکه بخواهید از Quad9 DNS servers که متعلق به IBM استفاده نمایید یا اونها رو در کنار کلودفلیر داشته باشید کافیه این دو خط رو جایگزین خطوط بالا کنید یا زیر اون اضافه نمایید.

forward-addr: 9.9.9.9@853
forward-addr: 149.112.112.112@853

منبع

راه اول تغییر برنامه‌ست و اینکه کاری کنیم که همه‌ی لینک‌ها با https شروع بشود. اما این روش همیشه مقدور نیست و خیلی وقت‌ها تغییر کد مقدور نیست. اینجاست که nginx و ماژول زیبای nginx_substitutions_filter به کار آدم میاد. با استفاده از این ماجول می‌توانیم هر نوشته‌ای رو قبل از نمایش برای کلاینت تغییر بدهیم.

برای اینکار کافیست در بخش server دو خط زیر رو وارد کنیم. در صورت حذف خط دوم،‌ فقط اولین http  به https تبدیل می‌شود.

sub_filter 'http://' 'https://';

sub_filter_once off;

اما همین دو خط زمانیکه nginx پشت یک لودبالانس مانند haproxy باشد کار نخواهد کرد. برای حل این مشکل کافیست خط زیر رو به کانفیگ nginx در بخش location اضافه نمایید.

proxy_set_header Accept-Encoding "";

root@s2:~# gluster peer probe s4.storage

اما اگر مثل من بدشانس باشید همین دستور خیلی ساده مشکل ساز میشه و عضو جدید به درستی کار نخواهد کرد.

gluster peer status

Hostname: s4.storage
Uuid: 7b4hf063-f234-4422-9ebc-53254bab90535
State: Peer Rejected (Disconnected)

وقتی لاگ مربوط به گلاستر در سرور s4 رو ببینید همچین پیغامی خواهید دید.

0-glusterd: Unable to find peerinfo for host: s2.storage (24007)

که با زبون سربسته داره میگه نود جدید که قصد اضافه کردن اون رو به کلاستر داشتیم نتونسته اطلاعات لازم رو از نود s2 بگیرد! نود s2 همون نودی بوده که از قبل عضو کلاستر بوده و از داخل اون قصد داشتیم نود جدید رو عضو کلاستر کنیم.

دلیل این اتفاق این بود  که همه نودهای کلاستر ورژن 3.12.5 بودند اما در زمانیکه قصد اضافه کردن عضو جدید به کلاستر رو داشتم، گلاستر centos به نسخه 3.12.6 آپگرید شده و دقیقا همین موضوع باعث مشکل میشه. برای اضافه کردن نود جدید به کلاستر باید دقت کنید که ورژن گلاستر سرور جدید و قدیم دقیقا یکی باشد.

پروسه‌ی دانگرید در centos برخلاف اوبونتو می‌تونه آدمیزاد رو زخم کنه و اساسا بخاطر همین موضوع شروع به نوشتن این راهنما کردم.

کاری که  برای حل این مشکل انجام دادم این بود که پکیج‌های rpm  گلاستر رو از مسیر یکی از نودهایی که عضو کلاستر بود (s2) رو به سرور جدید انتقال دادم.

cd /var/cache/yum/x86_64/7/centos-gluster312/packages

scp *3.12.5* storage@s4.storage:/home/storage/repo

بعد در سرور جدید (s4) به شکل زیر یک مخزن لوکال ساختم.

yum install createrepo -y

createrepo /home/storage/repo/

chmod -R o-w+r /home/storage/repo/

و بعد مخزن رو باید به سنت‌او‌اس به شکل زیر معرفی کنیم.

vi /etc/yum.repos.d/gluster3125.repo

[local]
name=gluster3512
baseurl=file:///home/storage/repo
enabled=1
gpgcheck=0

قبل از نصب گلاستر ورژن قدیمی، بایستی اول اون رو از کلاستر حذف کنیم
برای اینکار کافیه از یکی از سرورها که عضو کلاستر هستند (s2) کامند زیر رو بزنید.

root@s2:~# gluster peer detach s4.storage

بعد در سرور s4 که قراره ورژن اون رو دانگرید کنیم بعد از استاپ سرویس گلاستر در مسیر زیر هر چی فایل هست رو پاک کنیم.

systemctl stop glusterd

cd /var/lib/glusterd

rm -rf ./*

گلاستر برای نصب نیاز به یک پکیج به اسم userspace-rcu داره که ورژن اون  باید 0.10 به بالا باشد. برای نصب این پکیج بهتره از همونی که داخل مخزن گلاستر 3.12.6 موجوده بهره ببریم.

وقتی که میخوایم پکیج های گلاستر 3.12.6 رو پاک کنیم یادمون نمیره که userspace-rcu رو نگه داریم وگرنه به مشکل خواهیم خورد.

[root@s4 ~]# yum list installed | grep gluster | grep -v userspace | cut -d ' ' -f 1 | xargs yum remove -y

حالا نوبت به نصب دوباره گلاستر می‌رسد. چون یک مخزن اضافه کردیم که  پکیج‌های گلاستر 3.12.5 داخلش موجوده اینبار ورژن قدیمی نصب خواهد شد.

yum install glusterfs-server -y

و دوباره نود رو به کلاستر جوین میکنیم.

gluster peer probe s4.storage

و در آخر مطمئن میشیم که همه چیز خوب پیش رفته باشد.

gluster peer status

State: Peer in Cluster (Connected)

خیلی یکهوویی تصمیم گرفتم فیلم‌های خوبی رو که اکثرا در سینما پردیس قلهک باهاشون آشنا شدم و می‌شم و با اونها خیلی حال کردم رو با شما نیز به اشتراک بگذارم. نکته مهم اینه که اینها صرفا  نظر شخصی و منتقد فیلم نیستم و اصولا هم تخصصی در این زمینه ندارم :))‌ صرفا یک پیشنهاد برای اینکه شما هم اون رو ببینید، شاید مثل من از دیدنش لذت بردید.

برای شروع  هفت که ترجمه seven بهتون پیشنهاد میکنم حتما ببینید. این فیلم در لیستی هزارتایی قرار میگیره و اینطوری که میشه هزاربار این فیلم رو دید و هزاربار ناراحت شد و خسته هم نشد.

این فیلم در سال ۱۹۹۵ به کارگردانی دیوید فینچر با بازی بردپیت و مورگان فریمن ساخته شده.  اجازه ندید قدیمی بودن ساخت فیلم مانع از دیدن اون بشه! فیلم روایت فردی قاتل که آدم‌های بد رو به شکل فجیع می‌کشه. به تدریج و از قتل دوم سوم به بعد دو کارگاه اصلی متوجه میشن که قتل‌ها سریالی هستند و انتخاب اونها براساس هفت گناه کبیره‌ست. همین مورد باعث میشه ادم ناخودآگاه موردهای وطنی در ذهنش تداعی بشه. مواردی که قاتل، مجازات مقتول رو وظیفه‌ای الهی میدونه، شخصا تصمیم به مجازات فرد خاطی میگیره. برای  پنج عدد از این گناهان شامل شکم‌پرستی Gluttony، طمع Greed، کاهلی Sloth، شهوت Lust و تکبر Pride، قاتل، آدم‌های مورد دار رو انتخاب میکنه و به سزای عملشون می‌رسونه و همین باعث میشه آدم با قاتل در ابتدا خیلی همزادپنداری کنه.  در میانه قتل‌ها،‌ دو کارگاه اصلی تا دو قدمی قاتل نیز می‌رسن که همین نحوه رسیدنش هم در نوع خودش خیلی جالبه! اونها اول حدس میزنن که قاتل چه کتابی رو داخل کتابخونه میره میخونه و بعد با استفاده از اطلاعاتی که FBI به شکل غیرقانونی از کتابخونه ها جمع‌آوری میکنه، به موقعیت قاتل پی می‌برند! کتابخونه جایی که اطلاعات شخصی مثل تلفن و ادرس محل خونه رو مجبورید برای عضو شدن و گرفتن کتاب تحویل بدید اینطوری میشه از رو سلیقه فرد کتابخوان به فردی مظنون شد!

فیلم از جایی زیبا میشه و به اوج خودش میرسه که قاتل با پای خودش میاد و خودش رو معرفی میکنه! در حالیکه هنوز دو گناه بزرگ مونده که هیچ فردی بخاطرش مجازات نشده! یکی گناه خشم Wrath و دیگری گناه حسادت Envy. قاتل بعد از معرفی خودش به پلیس درخواست میکنه که به همراه دو  کارگاه اصلی فیلم به محلی بره که به گفته خودش قراره پرده از قتل ششم برداشته بشه! در انتهای فیلم اینطور میشه برداشت کرد که قاتل خودش دچار گناه حسادت شده. حسادت به کارگاه پلیس، بخاطر همسر خوبی که داشته و برای همین زن کارگاه  میلز رو  از تنش جدا میکنه و در انتها کاری میکنه که کارگاه میلز اون رو بکشه و به این ترتیب فردی که مرتکب حسادت میشه هم به سرانجام کار خودش میرسه! اما این وسط کارگاه میلز که مرتکب گناه خشم شده و قاتل رو کشته، تنها فردی که زنده می‌مونه.

یکی از بهترین دیالوگ‌های فیلم جایی که کارگاه میلز به قاتل میگه تو مسیح نیستی، در بهترین حالت فیلم برتر هفته یا یک تی‌شرت هستی که یکی دو روز تن ملت می‌شی و بعدش تمام!

You’re no messiah. You’re a movie of the week. You’re a fucking t-shirt, at best.

گاهی به دلیل یک اشتباه در برنامه و اجرای یک کوئری ناصحیح حجم انبوهی از کوئری‌ها که پاسخشون خیلی زمانبر به سمت دیتابیس سرازیر میشه. در این مواقع بهتر جای اینکه کل دیتابیس رو استاپ کنید، پروسس‌های داخلی اون رو فقط kill کنید. دلیل اینکار اینه که استاپ یک دیتابیس سنگین کار بسیار هزینه‌بری است.

mysqladmin processlist -u root -pPassword | awk '$2 ~ /^[0-9]/ {print "KILL "$2";"}' | mysql -u debian-sys-maint -pPassword

اگر همچین دستوری رو روی یک دیتابیس slave بزنید، یادتون نره که باید مجدد وارد دیتابیس بشید و کاری کنید که کارش رو ادامه بده (START SLAVE) در غیر اینصورت دیتابیس از سینک خارج خواهد شد.

در این پروسه  هیچ تضمینی برای اینکه اطلاعات از دست نره (در زمان از دست رفتن نود master)‌ وجود نداره! دلیلش اینه که شما اطلاعات رو روی node مستر می‌نویسید، نود مستر به کلاینت میگه اوکی دیتا رو دارم و بعد تازه میره دنبال اینکه دیتا  روی نود slave هم ذخیره بشه. :)‌

این رو هم بگم که برای اینکه دیتا به شکل مساوی بین node های مستر پخش بشه، کلاستر ردیس از چیزی به اسم SLOT استفاده میکنه. در مجموع 16384 اسلات ردیس کلاستر داره که بسته به تعداد node هایی که داریم میاییم اسلات ها رو بین نودها تقسیم میکنیم.

کلاینت در صورتی که به یک node (مستر) درخواست بده واطلاعات روی اون  نباشه، بجای اینکه کلید درخواستی رو بده، اطلاعات nodeی رو  که کلید داره رو میده و دوباره کلاینت باید به اون دومی درخواست بده :)  و  این میشه همون سربار یا overhead که ردیس کلاستر به ردیس معمولی داره بعلاوه اینکه یک سری محدودیت ها رو هم خواهید داشت مثل اینکه نمیشه از قابلیت Geo location ردیس استفاه کنید .

حالا نکته اینجاس که اگر کلاینت به یک نود مستر وصل شه و اون نود به هر دلیل داون بشه، هر چند slave به شکل خودکار تبدیل به مستر میشه، اما دیگه کلاینت از اون نود اطلاعی نداره!‌ برای حل این مشکل از لودبالانس HAPROXY استفاده میکنیم.

خودم haproxy رو به دلایل خیلی زیادی با داکر همیشه بالا میارم که کار رو خیلی ساده میکنه و برای اینکار هم لازم نیست همه چی رو از اول بسازیم، از یک داکر اماده استفاده میکنیم.

git clone https://github.com/nuved/docker-haproxy-letsencrypt.git

و بعد باید اون رو build کنیم.

docker build -t ha .

قبل از اجرای تنظیمات باید یک کانفیگ haproxy ایجاد کنیم که اون رو به خورد کانتینر بدیم.

vi /etc/haproxy/haproxy.cfg

global
    log /dev/log local0 info
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    group haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    maxconn 2000000
    nbproc 6
    cpu-map 1 1
    cpu-map 2 2
    cpu-map 3 3
    cpu-map 4 4
    cpu-map 5 5
    cpu-map 6 6

defaults REDIS
    log global
    mode tcp
    timeout connect  3s
    timeout client   6s
    timeout server   6s

frontend ft_redis
  bind 172.17.77.34:6379 name redis
  maxconn 2000000
  default_backend bk_redis
  mode tcp
  option tcplog

backend bk_redis
 option tcp-check
 tcp-check send PING\r\n
 tcp-check expect string +PONG
 tcp-check send info\ replication\r\n
 tcp-check expect string role:master
 tcp-check send QUIT\r\n
 tcp-check expect string +OK
 server redis-49-6380 172.17.77.49:6380 check inter 1s
 server redis-47-6379 172.17.77.47:6379 check inter 1s
 server redis-48-6379 172.17.77.48:6379 check inter 1s
 server redis-49-6379 172.17.77.49:6379 check inter 1s
 server redis-48-6380 172.17.77.48:6380 check inter 1s
 server redis-47-6380 172.17.77.47:6380 check inter 1s



listen stats
    bind 172.17.77.34:1936
    mode http
    stats hide-version
    stats enable
    stats uri /
    stats realm HAProxyStatistics
    stats auth novid:password

بخش frontend باعث میشه haproxy روی پورت  6379 لیستن کنه و هر ترافیکی هم که به سمتش بیاد رو به  backend پیشفرضی که تعریف کردیم، بفرسته.

در بخش backend که قلب اصلی سیستم، haproxy  به نودهای فقط master ترافیک رو می‌فرسته. نکته قشنگ کار اینه که در اینجا همه نود های redis چه مستر و چه slave رو میدیم و از haproxy میخوایم بره وضعیت نودها رو خوش در بیاره. haproxy هم هر یک ثانیه میره از نودهای ردیس میپرسه که شما مسترسی یا salve  و اونها هم اگر جواب بدند مستر، به رنگ سبز در میان و اگر slave باشند دیگه از دور خارج میشند و عملا ترافیکی به سمت اونها نمیره :)

در بخش stats هم که صرفا امار haproxy رو فعال کردیم و کار مهمی انجام نمیده، بخش اول nbproc هم نمایانگر تعداد core های سرور و اینجا با فرض اینکه سرور هفت core پردازشی داره، شش تا از اونها رو بدین شکل به خورد haproxy میدیم :) haproxy هم مشابه nginx میاد به تعداد core هایی که مشخص کردیم child میسازه.

root      1365  0.0  0.4 356360  4248 ?        Sl   05:15   0:00      \_ docker-containerd-shim a260b62f4a7fdc12df941a3747cda7580233c47f26a3a60b0dfa3ff2e4561665 /var/run/docker/libcontainerd/a260b62f4a7fdc12df941a3747cda7580233c47f26a3a60b0dfa3ff2e4561665 docker-runc
root      1383  0.0  0.0  17980   536 ?        Ss   05:15   0:00          \_ /bin/bash /entrypoint.sh
root      1406 17.6  0.1 184696  1312 ?        Ssl  05:15  62:43              \_ /usr/sbin/rsyslogd
root      1913 17.9  0.8 227584  8524 ?        Ss   05:27  61:25              \_ haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid -sf 44 45 46 47 48
root      1914 40.3  0.8 228788  8844 ?        Rs   05:27 137:50              \_ haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid -sf 44 45 46 47 48
root      1915  9.4  0.7 227040  8084 ?        Ss   05:27  32:25              \_ haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid -sf 44 45 46 47 48
root      1916 12.0  0.7 227312  8020 ?        Ss   05:27  41:15              \_ haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid -sf 44 45 46 47 48
root      1917 29.6  0.8 228508  8336 ?        Ss   05:27 101:15              \_ haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid -sf 44 45 46 47 48
root      1918  8.5  0.7 226068  7820 ?        Ss   05:27  29:18              \_ haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid -sf 44 45 46 47 48
root      1921  0.0  0.0   6356    84 ?        S    05:27   0:00              \_ inotifywait -q -r --exclude \.git/ -e modify,create,delete,move,move_self /etc/haproxy/haproxy.cfg /etc/letsencrypt

و در نهایت داکر ha رو با کامند زیر اجرا می‌کنیم.

docker run -d  --name=haproxy  --ulimit nofile=4500000:4500000  -v /var/lib/haproxy:/var/lib/haproxy -v /etc/haproxy/haproxy.cfg:/etc/haproxy/haproxy.cfg  -v /dev/log:/dev/log --net=host ha

یک قابلیت خوب این کانتینر اینه که میشه کانفیگ haproxy روی سرور اصلی رو ویرایش کرد، کانتینر به شکل خودکار متوجه این امر میشه و در صورتی که مشکلی در سینتکس وجود نداشته باشه، تغییر رو اعمال میکنه. برای اینکه از این قابلیت استفاده کنید باید تغییری در ادیتور vim بدیم.

vi /root/.vimrc

set backupcopy=yes

و در نهایت اینکه اگر سرورتون زیر بار خیلی زیادی حتما تنظیمات زیر داخل sysctl فراموش نشه.

vi /etc/sysctl.conf

vm.swappiness=5


fs.file-max = 10000000
fs.nr_open = 10000000
net.ipv4.tcp_mem = 786432 1697152 1945728
net.ipv4.tcp_rmem = 4096 4096 16777216
net.ipv4.tcp_wmem = 4096 4096 16777216

net.ipv4.ip_local_port_range = 1000 65535
net.nf_conntrack_max = 1200000
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 15

دو مدل اول به ریدکنترلر متصل هستند و برای دیدن نتایج واقعی  cahce ریدکنترلر خاموش است. مدل سوم روی pci express سرور سوار  است و فقط os اون رو می‌بینه.

دو  تست روی هاردهای ssd انجام می‌دیم.در تست اول برای کاری که تخصص دارند و اون نوشتن و خواندن Random هست و دیگری حالت Sequential که برای دیسک‌های معمولی هم کار راحتی و معمولا حیف برای اینجور کارها بخوایم از ssd استفاده کنیم.

هارد ssd اینتل

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [m(1)] [100.0% done] [188.4MB/64520KB/0KB /s] [48.3K/16.2K/0 iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=14143: Sun Aug  6 15:16:46 2017
  read : io=3071.7MB, bw=192038KB/s, iops=48009, runt= 16379msec
  write: io=1024.4MB, bw=64040KB/s, iops=16010, runt= 16379msec
  cpu          : usr=8.89%, sys=45.45%, ctx=361045, majf=0, minf=605
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: io=3071.7MB, aggrb=192037KB/s, minb=192037KB/s, maxb=192037KB/s, mint=16379msec, maxt=16379msec
  WRITE: io=1024.4MB, aggrb=64040KB/s, minb=64040KB/s, maxb=64040KB/s, mint=16379msec, maxt=16379msec

Disk stats (read/write):
  sdc: ios=773774/258385, merge=1358/173, ticks=794948/222572, in_queue=1017672, util=99.46%

نکته اول اینکه با fio سعی کردیم حالت واقعی سرور رو شبیه‌سازی کنیم 75 درصد read و 25 درصد write. مهمترین بخش هم iops هست.

iops=48009 برای read و iops=16010 برای رایت.

برای تست دوم از dd استفاده میکنیم. نکته مهم اینه که oflag=dsync   به ازای هر تیکه‌ای که میخواد روی هارد بنویسه (۵۱۲ بار می‌پرسه) تاییدیه از os میگره. اما conv=fdatasync تنها یکبار در انتهای نوشتن و هنگام خروج از dd تاییدیه از os گرفته میشه.

dd if=/dev/zero of=novid bs=1M count=512 oflag=dsync
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 1.96172 s, 274 MB/s

dd if=/dev/zero of=novid bs=1M count=512 conv=fdatasync
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 1.45621 s, 369 MB/s

هارد ssd سامسونگ مدل MZ7KM480

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [m(1)] [100.0% done] [266.7MB/90880KB/0KB /s] [68.3K/22.8K/0 iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=14225: Sun Aug  6 15:24:17 2017
  read : io=3071.7MB, bw=271248KB/s, iops=67811, runt= 11596msec
  write: io=1024.4MB, bw=90455KB/s, iops=22613, runt= 11596msec
  cpu          : usr=14.08%, sys=52.78%, ctx=768554, majf=0, minf=605
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: io=3071.7MB, aggrb=271247KB/s, minb=271247KB/s, maxb=271247KB/s, mint=11596msec, maxt=11596msec
  WRITE: io=1024.4MB, aggrb=90454KB/s, minb=90454KB/s, maxb=90454KB/s, mint=11596msec, maxt=11596msec

Disk stats (read/write):
  sdb: ios=771941/257788, merge=1231/167, ticks=552804/164876, in_queue=722248, util=99.45%

iops=67811 برای read و iops=22613 برای رایت. که نشون میده در میون هاردهای ssd سرور  سامسونگ از مدل اینتل پیشی گرفته.

dd if=/dev/zero of=novid bs=1M count=512 oflag=dsync
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 1.86999 s, 287 MB/s

dd if=/dev/zero of=novid bs=1M count=512 conv=fdatasync
512+0 records in
512+0 records out

در این تست هم سامسونگ برنده شده.

و اما مدل دیگه سامسونگ pro 960 که از پیش حدس می‌زنیم سرعت خیلی بالاتری داشته باشه.

سامسونگ pro 960

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.2.10
Starting 1 process
test: Laying out IO file(s) (1 file(s) / 4096MB)
Jobs: 1 (f=1): [m(1)] [75.0% done] [719.6MB/240.2MB/0KB /s] [184K/61.5K/0 iops] [eta 00m:01s]

Jobs: 1 (f=1): [m(1)] [100.0% done] [690.4MB/229.5MB/0KB /s] [177K/58.8K/0 iops] [eta 00m:00s]

test: (groupid=0, jobs=1): err= 0: pid=14313: Sun Aug  6 15:33:11 2017
  read : io=3071.7MB, bw=705402KB/s, iops=176350, runt=  4459msec
  write: io=1024.4MB, bw=235236KB/s, iops=58808, runt=  4459msec
  cpu          : usr=19.47%, sys=70.17%, ctx=27594, majf=0, minf=367
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: io=3071.7MB, aggrb=705402KB/s, minb=705402KB/s, maxb=705402KB/s, mint=4459msec, maxt=4459msec
  WRITE: io=1024.4MB, aggrb=235235KB/s, minb=235235KB/s, maxb=235235KB/s, mint=4459msec, maxt=4459msec

Disk stats (read/write):
  nvme0n1: ios=766260/255818, merge=0/0, ticks=182612/2688, in_queue=185564, util=97.90%

این هارد خوب iops=176350 برای read و iops=58808 رو برای نوشتن به ما میده که البته فاصله خیلی زیادی با اعدادی داره که سامسونگ ادعا میکنه :)‌

dd if=/dev/zero of=novid bs=1M count=512 oflag=dsync
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 3.57902 s, 150 MB/s

dd if=/dev/zero of=novid bs=1M count=512 conv=fdatasync
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 0.635125 s, 845 MB/s

و در کمال تعجب میشه دید که این ssd  در حالت sequential خیلی هم خوب کار نمیکنه :)