Sometimes you wanna play on a bigger screen 📺

#hp 3par

اگر بخوایم یه تعریف خیلی ساده از SAN Storage ها بگیم باید گفت که این دستگاهها با توجه به اینکه تعداد هاردهای زیادی دارن میتونند فضای ذخیره سازی خیلی زیادی رو برای ما داخل شبکه ها به وجود بیارن از طرفی برای متصل کردنشون به شبکه و سرورها برای مصارفی مثل ذخیره سازی یا بک آپ باید از سوییچهای مخصوصی که به نام SAN switch شناخته میشن استفاده کرد و جالبتر اینه که برای اتصال سرور ها به SAN switch ها هم باید از کارتهای مخصوصی که به اونها HBA میگن استفاده کنید بد نیست بدونید که تمامی این ارتباطها از طریق فیبر های نوری انجام میشه.

موضوع ویدئو: به روز رسانی Firmware هاردهای 3par هست.

آدرس اینستاگرام:
🌐Instagram
-----------------------------
آدرس کانال یوتیوب:
📹Youtube Channel
-----------------------------
آدرس کانال تلگرام:
🆔 Telegram Channel

کارت‌های HBA (مخفف Host Bus Adapter) سخت‌افزارهایی هستن که برای اتصال سرور یا کامپیوتر به دستگاه‌های ذخیره‌سازی استفاده می‌شن. این کارت‌ها معمولاً روی اسلات PCIe نصب می‌شن و به سرور اجازه می‌دن تا با دستگاه‌های ذخیره‌سازی ارتباط برقرار کنه.
فرق HBA با RAID Controller چیه؟
مورد اول HBA: فقط یه واسط برای اتصال سرور به هارد یا استوریجه، بدون قابلیت مدیریت RAID.
مورد دوم RAID Controller: علاوه بر اتصال، امکان مدیریت RAID و افزایش کارایی رو هم فراهم می‌کنه.

مقاله ی ساده و روان Helm در Kubernetes

ابزار Helm چیست و چرا به آن نیاز داریم؟
اگر با Kubernetes کار کرده باشی، حتماً می‌دونی که برای راه‌اندازی یه اپلیکیشن روی کلاستر باید کلی فایل YAML بنویسی. هر اپلیکیشن معمولاً شامل Deployment، Service، ConfigMap، Secret، Ingress و ... هست که مدیریت اون‌ها به‌صورت دستی واقعاً وقت‌گیر و سخته.
ابزار Helm اومده که این کار رو راحت‌تر و سریع‌تر کنه! Helm مثل یه مدیر بسته (Package Manager) برای Kubernetes عمل می‌کنه. درست همون‌طور که توی لینوکس از apt یا yum برای نصب برنامه‌ها استفاده می‌کنی، توی Kubernetes هم Helm این کار رو برات انجام می‌ده.

مزایای استفاده از Helm
✅ نصب راحت اپلیکیشن‌ها: به جای نوشتن کلی فایل YAML، فقط یک دستور اجرا می‌کنی!
✅ به‌روزرسانی ساده: می‌تونی اپلیکیشن‌ها رو راحت‌تر به نسخه‌های جدید ارتقا بدی.
✅ مدیریت نسخه‌ها (Rollback): اگه چیزی خراب شد، می‌تونی خیلی راحت به نسخه قبلی برگردی.
✅ تنظیمات سفارشی‌ سازی‌ شده: می‌تونی مقادیر مورد نیاز رو تغییر بدی بدون دست‌کاری فایل‌های YAML.
✅ استفاده از چارت‌های آماده: کلی چارت (Chart) آماده برای نصب دیتابیس‌ها، وب‌سرورها و برنامه‌های مختلف وجود داره.

چارت (Chart) در Helm چیست؟
چارت در Helm در واقع بسته‌ای از فایل‌های YAML هست که تمام اجزای مورد نیاز یک اپلیکیشن رو شامل می‌شه. مثلاً اگه بخوای Nginx رو روی Kubernetes نصب کنی، باید چندین فایل YAML بنویسی، ولی با Helm، یه چارت آماده هست که همه چیزو برات انجام می‌ده.

ساختار یک چارت Helm به این شکله:

my-chart/
  ├── charts/            # چارت‌های دیگر (در صورت وجود وابستگی)
  ├── templates/         # فایل‌های YAML که برای دیپلوی استفاده می‌شوند
  ├── values.yaml        # مقادیر پیش‌فرض که قابل تغییر هستند
  ├── Chart.yaml         # توضیحات مربوط به چارت
  └── README.md          # توضیحات و نحوه استفاده

نصب یک اپلیکیشن با Helm
مثلاً برای نصب Nginx با Helm کافیه این دستور رو بزنی:

helm install my-nginx bitnami/nginx

این دستور یه پاد Nginx رو روی کلاستر Kubernetes اجرا می‌کنه بدون اینکه لازم باشه چندین فایل YAML بنویسی.

حذف اپلیکیشن
اگه بخوای اپلیکیشنی که با Helm نصب کردی رو حذف کنی:

helm uninstall my-nginx

لیست اپلیکیشن‌های نصب‌شده
برای دیدن اپ‌هایی که با Helm روی کلاستر Kubernetes نصب شدن:

helm list

چگونه Helm را نصب کنیم؟
نصب Helm خیلی سادست! توی لینوکس می‌تونی این کار رو با دستور زیر انجام بدی:

curl https://raw.githubusercontent.com/helm/helm/main/noscripts/get-helm-3 | bash

آیا همه ی Image های مورد استفاده برای ساخت کانتینر ها ، از طریق داکر فایل ساخته میشوند؟

نه، همه‌ی ایمیج‌ها با Dockerfile ساخته نمی‌شن! روش‌های دیگه‌ای هم برای ساخت ایمیج وجود داره که بعضی پروژه‌ها و شرکت‌ها از اون‌ها استفاده می‌کنن.

روش‌های جایگزین برای ساخت ایمیج کانتینر
اول ، Dockerfile: همچنان محبوب‌ترین روشه، اما تنها روش نیست.
دوم ، Buildpacks: یه روش خودکار که Cloud Native Buildpacks و Heroku Buildpacks استفاده می‌کنن. این روش نیازی به Dockerfile نداره و خودش محیط مناسب برای اجرای اپ رو تشخیص می‌ده.
سوم ، Bazel: یه ابزار گوگل برای ساخت ایمیج بدون نیاز به Dockerfile که مخصوص پروژه‌های بزرگ و پیچیده طراحی شده.
چهارم ، Nix: یه روش دیکری برای ساخت ایمیج‌های قابل بازتولید و مطمئن.
پنجم ، Singularity: برای محیط‌های HPC و تحقیقاتی، که Dockerfile نداره ولی کانتینر می‌سازه.
ششم ، Kaniko: مخصوص محیط‌هایی که داکر نصب نیست و نیازی به Docker daemon نداره.
هفتم ، Podman & Buildah: می‌تونن بدون نیاز به Docker daemon ایمیج بسازن، حتی از روش‌هایی غیر از Dockerfile.

همه‌ی ایمیج‌ها با Dockerfile ساخته نمی‌شن، اما بیشتر ایمیج‌ها هنوز از Dockerfile استفاده می‌کنن چون رایج‌تر و ساده‌تره. ولی تکنولوژی‌هایی مثل Buildpacks، Bazel و Kaniko در حال گسترش هستن و در بعضی پروژه‌ها جایگزین Dockerfile شدن.

این ارور پرینتر هم از ویندوز ۱۰ سر و کله‌اش پیدا شد.

به خاطر یه فیچر امنیتی این موضوع پیش میاد. معمولا موقعی که پرینتر رو یه PC با ویندوز ۱۰ نصب باشه و به اشتراک گذاشته میشه ممکنه این موضوع پیش بیاد. معمولا در دو حالت زیر:

۱. در حالتی که سیستم مقصد ویندوزی پایین‌تر باشه مثل ۷
۲. موقعی که بیلد ویندوز ۱۰ از بیلدهای قدیمی باشه.

حالا راه حل چیه؟ - یه سر به ریجستری و services بزنیم.

تو کامپیوتر مبدا ( پرینتر روش نصب شده) ریجستری رو باز میکنیم و به مسیر زیر می‌ریم:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print

اینجا یه کلید از نوع DWORD-32 با اسم RpcAuthnLevelPrivacyEnabled می‌سازیم.( به کوچیک و بزرگ بودن حروف دقت بشه.)

مقدارش رو برابر 0 قرار می‌دیم. حالا services رو به صورت Run as administrator باز می‌کنیم و سرویس Print Spooler رو ریستارت می‌کنیم.

اگه سیستم SSD داشت و حوصله نداشتی دنبال سرویس بگردی کلا سیستمو ریستارت کن. اصطلاحا straight forward ئه.

منبع
Mohamad Rostami

آیا Kubernetes براش مهمه که با چه روشی ما ایمیج رو ساختیم؟

نه، Kubernetes اصلاً به این اهمیت نمی‌ده که ایمیج با Dockerfile ساخته شده یا نه!
اون فقط به یه ایمیج کانتینری نیاز داره که از فرمت OCI (Open Container Initiative) یا Docker Image Format پشتیبانی کنه.

چطوری Kubernetes ایمیج‌ها رو اجرا می‌کنه؟
در واقع Kubernetes فقط یه کانتینر Runtime نیاز داره که بتونه ایمیج‌ها رو اجرا کنه. این Runtime می‌تونه containerd، CRI-O یا حتی Docker (در نسخه‌های قدیمی) باشه. فرقی نداره ایمیج با چی ساخته شده؛ مهم اینه که در قالب استاندارد OCI-compliant باشه. وقتی توی Kubernetes یه پاد (Pod) تعریف می‌کنی، اون فقط می‌ره ایمیج مشخص‌شده رو از رجیستری (مثلاً Docker Hub، AWS ECR، یا GitHub Container Registry) می‌گیره و اجرا می‌کنه.
پس Kubernetes به فرمت نهایی ایمیج نگاه می‌کنه، نه به روش ساخت اون!

دوستی جایی قشنگ نوشته بود:

در دنیایی که سرویس های مبتنی بر هوش مصنوعی بر سر "حل مسئله" با هم رقابت می کنند، تنها رقابت معناداری که برای ما انسان‌ها باقی می‌ماند، رقابت بر سر "تعریف مسئله" است.🤝

به نظرم وارد دوره ای از زمان شدیم ، که باید رویکرد فکریمون رو از تلاش برای رسیدن به پاسخ ، به تلاش برای پیدا کردن مسئله تغییر بدهیم.
پاسخ ها با سرعت وحشتناکی بدست میان ، مهم پیدا کردن مسئله و موضوعات مجهول هست ، حالا ابزاری هست که تفکر برای پاسخ را ممکن کرده ؛ باری از روی دوش انسان برداشته و به نوعی تقسیم وظایف کردیم . تا پیش از این ، دنیا مسئله ایجاد میکرد و ما آن را حل میکردیم ، امروزه روز ، ما مسئله تعریف میکنیم و هوش مصنوعی آن را حل میکند.

تفاوت روش های ساخت ایمیج در چیست ؟

فرق اساسی ایمیج‌هایی که با Dockerfile ساخته می‌شن با ایمیج‌هایی که با روش‌های دیگه ساخته می‌شن، بیشتر به نحوه‌ی تولید و بهینه‌سازی اون‌ها برمی‌گرده، نه به فرمت نهایی‌شون. یعنی در نهایت، همه‌ی ایمیج‌ها یک چیز استاندارد می‌شن (OCI-compatible)، اما روش ساخت‌شون می‌تونه متفاوت باشه.

مثلا Dockerfile:
مرحله‌به‌مرحله (Layered) ساخته می‌شه، که به کمک Caching سرعت Build رو بالا می‌بره.
دستورات داخل Dockerfile (مثل RUN, COPY, CMD) به ترتیب اجرا می‌شن و هرکدوم یه لایه‌ی جدا می‌سازن. ممکنه لایه‌های اضافی (بیشتر از نیاز) داشته باشه، که باعث بزرگ شدن ایمیج بشه.
اما روش‌های جایگزین (مثل Buildpacks، Bazel، Kaniko):
بعضی روش‌ها (مثلاً Buildpacks) سعی می‌کنن لایه‌های غیرضروری رو حذف کنن و ایمیج‌های بهینه‌تر بسازن. برخی ابزارها (مثل Bazel) می‌تونن Dependencyهای غیرضروری رو تشخیص بدن و حذف کنن. روش‌هایی مثل Kaniko و Buildah بدون نیاز به Docker daemon ایمیج می‌سازن، که روی سیستم‌هایی که امنیت مهمه، مفیدتره.

استاندارد OCI در ساخت ایمیج ها چیه؟

در واقع OCI (Open Container Initiative) یه استاندارد که می‌گه ایمیج‌های کانتینری باید یه ساختار مشخص و یکسان داشته باشن، فارغ از اینکه چجوری ساخته شدن.

چرا مهمه؟
قبل از OCI، بیشتر ایمیج‌ها فقط برای Docker ساخته می‌شدن، ولی الان هر ابزاری که از OCI تبعیت کنه می‌تونه اون ایمیج‌ها رو اجرا کنه، بدون وابستگی به Docker!

یعنی چی؟
اول ، Kubernetes می‌تونه ایمیج‌هایی که با Docker، Buildpacks، Bazel، Kaniko یا هر چیز دیگه ساخته شدن رو اجرا کنه، چون همه‌ی این ابزارها ایمیج‌های OCI-compatible تولید می‌کنن.
دوم ، containerd و CRI-O که توی Kubernetes استفاده می‌شن، فقط کافیه یه ایمیج استاندارد OCI بگیرن و اجراش کنن، دیگه مهم نیست که این ایمیج با چی ساخته شده.

نتیجه این میشه Kubernetes دیگه نیازی به Docker نداره، فقط کافیه ایمیج‌هایی که از استاندارد OCI تبعیت می‌کنن رو اجرا کنه، همین!

دوستی در لینکدین یکسری پارمتر هایی رو اعلام کردن که برای مهاجرت به اروپا و امارات مورد نیاز است
منبع
Reza KianiSam

آشنایی با Grafana: داشبورد حرفه‌ای برای مانیتورینگ!

📌 گرافانا چیست؟
ابزار Grafana یک نرم‌افزار متن‌باز برای ساخت داشبوردهای گرافیکی و مانیتورینگ است که به شما امکان می‌دهد داده‌های مختلف را از منابع مختلف که اصطلاحا به آنها دیتا سورس میگن جمع‌آوری کرده و به‌صورت نمودار، جدول، و گراف نمایش دهید.

🎯 چرا از گرافانا استفاده کنیم؟
✔️ نمایش داده‌های زنده و تاریخچه‌ای در قالب گراف و چارت
✔️ اتصال به انواع دیتابیس‌ها مثل Prometheus, MySQL, PostgreSQL, Elasticsearch, InfluxDB و...
✔️ تنظیم هشدارها (Alerting) و ارسال نوتیفیکیشن به تلگرام، ایمیل، Slack و...
✔️ قابلیت سفارشی‌سازی داشبوردها با تم‌ها، ویجت‌ها و فیلترها
✔️ نصب و استفاده آسان روی لینوکس، ویندوز، داکر و کلاود

🛠 گرافانا را با چی ترکیب کنیم؟
با ✅ Prometheus → برای جمع‌آوری داده‌های سرور، کانتینر و سرویس‌ها
با ✅ Elasticsearch / Loki → برای نمایش و جستجوی لاگ‌ها
با ✅ MySQL / PostgreSQL → برای نمایش داده‌های پایگاه داده
با ✅ Zabbix → برای مانیتورینگ تجهیزات شبکه مثل روتر و سوییچ

نکته : تو Grafana می‌تونی چندین دیتا سورس رو تعریف کنی و داده‌های اون‌ها رو توی یک داشبورد واحد نمایش بدی!

🛠 راهنمای جامع ابزارهای مانیتورینگ و بهترین ترکیب آن‌ها

نکته؛ در این مقاله ، ما ابزار های Open Source رایگان که قابلیت انعطاف پذیری را دارند بررسی کردیم.

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

📌 دسته‌بندی ابزارهای مانیتورینگ

1️⃣ مانیتورینگ زیرساخت (سرور، شبکه و کانتینرها)
این ابزارها برای بررسی وضعیت CPU، RAM، دیسک، پهنای باند، مصرف منابع و سلامت کلی سیستم‌ها استفاده می‌شوند.
ابزار🔹 Prometheus → جمع‌آوری متریک‌ها از سرورها، کانتینرها، سرویس‌ها
ابزار🔹 Zabbix → نظارت بر سوییچ‌ها، روترها، سرورها و سرویس‌ها (مبتنی بر SNMP و Agent)
ابزار🔹 Nagios → مانیتورینگ شبکه، سرورها و سرویس‌های IT
ابزار🔹 Netdata → نمایش لحظه‌ای مصرف CPU، RAM، دیسک و شبکه

✅ بهترین انتخاب: Prometheus (برای متریک‌های مدرن) + Zabbix (برای تجهیزات شبکه)

2️⃣ مانیتورینگ لاگ‌ها (Log Monitoring)
این ابزارها برای جمع‌آوری، فیلتر کردن و نمایش لاگ‌ها استفاده می‌شوند تا مشکلات سیستم سریع‌تر شناسایی شوند.
ابزار🔹 Elasticsearch + Logstash + Kibana (ELK Stack) → بهترین انتخاب برای پردازش و نمایش لاگ‌ها
ابزار🔹 Loki + Promtail + Grafana → جایگزین سبک‌تر و بهینه‌تر برای ذخیره و نمایش لاگ‌ها
ابزار🔹 Graylog → راهکار قدرتمند برای تحلیل لاگ‌ها

✅ بهترین انتخاب: ELK (برای لاگ‌های سنگین) یا Loki (برای لاگ‌های سبک‌تر و یکپارچه با Grafana)

3️⃣ مانیتورینگ عملکرد اپلیکیشن‌ها (APM - Application Performance Monitoring)
این ابزارها برای بررسی عملکرد کدهای برنامه، درخواست‌های HTTP، دیتابیس و تأخیرهای مختلف استفاده می‌شوند.
ابزار🔹 Jaeger → مانیتورینگ توزیع درخواست‌ها و تأخیرها در سیستم‌های میکروسرویسی
ابزار🔹 Zipkin → مشابه Jaeger برای بررسی لگ و تأخیرهای درخواست‌ها
ابزار🔹 New Relic → مانیتورینگ کامل اپلیکیشن، دیتابیس و سرور

✅ بهترین انتخاب: Jaeger یا Zipkin برای میکروسرویس‌ها

4️⃣ مانیتورینگ امنیت و تهدیدات (SIEM - Security Information & Event Management)
این ابزارها برای تحلیل لاگ‌های امنیتی، شناسایی حملات و جلوگیری از تهدیدات استفاده می‌شوند.
ابزار🔹 Wazuh → مانیتورینگ امنیتی، تشخیص تهدیدات، لاگ‌ آنالیز
ابزار🔹 Splunk → تحلیل داده‌های امنیتی و لاگ‌ها
ابزار🔹 OSSEC → سیستم تشخیص نفوذ (IDS) برای بررسی امنیت سیستم‌ها

✅ بهترین انتخاب: Wazuh برای امنیت متن‌باز، Splunk برای محیط‌های سازمانی

5️⃣ نمایش داده‌های مانیتورینگ (Visualization & Dashboarding)
این ابزارها داده‌های مانیتورینگ را به نمودارها و داشبوردهای گرافیکی تبدیل می‌کنند تا تحلیل آن‌ها راحت‌تر باشد.
ابزار🔹 Grafana → بهترین ابزار برای ساخت داشبوردهای گرافیکی و مانیتورینگ زنده
ابزار🔹 Kibana → نمایش داده‌های ELK و تحلیل لاگ‌ها
ابزار🔹 Chronograf → داشبوردهای مخصوص InfluxDB

✅ بهترین انتخاب: Grafana (چندمنظوره)، Kibana (برای لاگ‌ها)

🎯 بهترین ترکیب برای مانیتورینگ حرفه‌ای
💡 بسته به نیاز، ترکیب‌های مختلفی می‌توان پیشنهاد کرد، اما یک ستاپ ایده‌آل و کامل به شکل زیر است:

———————————————————————————-
متریک‌های سرور و کانتینر Prometheus + Node Exporter
———————————————————————————-
مانیتورینگ شبکه Zabbix (SNMP-based)
———————————————————————————-
مانیتورینگ لاگ‌ها ELK یا Loki + Promtail
———————————————————————————-
مانیتورینگ اپلیکیشن Jaeger یا Zipkin
———————————————————————————-
هشدار و Alerting Grafana + Alertmanager
———————————————————————————-
داشبورد و نمایش داده‌ها Grafana + Kibana
———————————————————————————-
مانیتورینگ امنیتی Wazuh + Suricata
———————————————————————————-


در نهایت، ترکیب Prometheus + Loki + Grafana + Zabbix یکی از بهترین و بهینه‌ترین راهکارهای مانیتورینگ است.