کتاب لینوکس برای همه ، نسخه 0.3



پیشنهاد میشود فصل اول اون را که در مورد اقتصاد متن باز و اقتصاد دیجیتال نوشتم را مطالعه فرمایید .


https://www.dropbox.com/s/kv845pwcw0l6uxq/linux_for_all_yashar_esmaildokht_0.3.pdf?dl=0


#linux #yashar_esmaildokht

#دانستنی های #گنو/ #لینوکس :


در واقع Tuned در لینوکس یک سرویس و مجموعه ابزار برای بهینه‌سازی خودکار عملکرد و مصرف انرژی سیستم است که می‌تواند پروفایل‌های آماده یا سفارشی را روی سخت‌افزار اعمال کند.

ایده اصلی Tuned این است که بسته به سناریوی کاری (سرور دیتابیس، ماشین مجازی، لپ‌تاپ، سیستم گرافیکی، ذخیره‌سازی و غیره)، سیستم را به‌طور پویا بهینه کند، بدون اینکه کاربر هر بار دستی پارامترها را تغییر دهد.

این تنظیمات می‌توانند شامل:

CPU governor و فرکانس پردازنده

زمان‌بندی I/O (I/O scheduler)

تنظیمات شبکه (TCP stack)

سیاست مصرف انرژی دستگاه‌ها (PCIe ASPM، SATA link power)

تنظیمات kernel sysctl

پارامترهای NUMA و حافظه


توی دنیای لینوکس، tuned-ppd یک "دیمنت پیاده‌سازی پل" (compatibility daemon) است که برای همگام‌سازی دو سیستم مدیریت پروفایل مصرف انرژی طراحی شده:

تعریف و هدف tuned-ppd

ا tuned-ppd وظیفه دارد تا API مورد استفاده توسط power-profiles-daemon (PPD) را به API سیستم TuneD ترجمه کند



نحوه عملکرد

برنامه‌هایی که با API قدرت قبلی (PPD) کار می‌کردند، اکنون از طریق tuned-ppd به TuneD متصل می‌شوند.



برای نمونه : من در لپ تاپ خودم با این ابزار میتونم . تنظیم کنم . تا چند درصد باطری را شارژ کامل کنه . تا باطری عمر بیشتری داشته باشه .

نکته : این قابلیت ها سخت افزاری هستند وباید تولید کننده لپ تاپ این قابلیت را بده .


برای مثال : لپ‌تاپت من Lenovo Ideapad هست و با درایور ideapad_laptop کار می‌کنه.

این درایور فقط یک حالت conserve mode (روشن/خاموش) داره، یعنی:

0 → خاموش، باتری تا 100٪ شارژ میشه.

1 → روشن، باتری حداکثر تا حدود ~55–60٪ شارژ میشه (محدوده دقیق وابسته به مدل و firmware هست)


--- TLP 1.7.0 --------------------------------------------



+++ Battery Care

Plugin: lenovo

Supported features: charge threshold

Driver usage:

* vendor (ideapad_laptop) = active (charge threshold)

Parameter value range:

* STOP_CHARGE_THRESH_BAT0: 0(off), 1(on) -- battery conservation mode

اما tlp :



یک ابزار تخصصی مدیریت مصرف انرژی در لینوکس است که برخلاف Tuned که بیشتر روی بهینه‌سازی کلی سیستم (CPU، I/O، Network، Memory) تمرکز دارد، بیشتر تمرکزش روی بهینه‌سازی مصرف باتری و افزایش طول عمر آن است، مخصوصاً برای لپ‌تاپ‌ها.

هدف TLP این است که:

عمر باتری لپ‌تاپ را افزایش دهد (Battery Longevity)

زمان کارکرد روی باتری را بیشتر کند (Battery Runtime)

بدون نیاز به تغییر دستی تنظیمات، بهترین تعادل بین مصرف انرژی و کارایی را پیدا کند.

ا TLP بعد از نصب و فعال‌سازی، به‌صورت خودکار با توجه به وضعیت سیستم (وصل بودن به برق یا کار روی باتری) تنظیمات بهینه را اعمال می‌کند.


تنظیم CPU frequency scaling governor

تنظیم PCI Express ASPM برای کاهش مصرف برق قطعات PCIe

خاموش‌کردن پورت‌های USB در حالت بیکار (USB autosuspend)

خاموش یا کم‌کردن توان Wi-Fi و Bluetooth در حالت باتری

تنظیم پارامترهای SATA link power management

کنترل GPU power saving (برای Intel، NVIDIA و AMD)

مدیریت Battery charge thresholds (در لپ‌تاپ‌هایی که پشتیبانی می‌کنند، مثل Lenovo/Dell/ASUS)

تغییر تنظیمات kernel power management



unixmens

#linux #kernel #tlp #tuned #performance
#tune


https://t.iss.one/unixmens

من نزدیک ۲ سال هست روی موضوع market researching حوزه کاری خودم یعنی it و لینوکس (مشتقات آن یعنی : devops - platform- storage - database - cloud - iot -) و enterprise open sorce و technology-driven های hi -tech بصورت تخصصی فعالیت میکنم . در واقع روی تاکسونومی آنها و سرمایه گذاری روی آنها .

به طوری که امروزه شاهد شغل هایی به نام strategist planner هستیم که براساس این داده ها برای سازمان ها طرح راهبردی اعلام میکند .
اینجا من مقاله ای را معرفی میکنم که در سال 2012 نوشته شده و مارکت را برای 2024 پیش بینی کرده . حال میبینیم تمام این ها درست بوده و تمامی محقق شده است .

https://softwarestackinvesting.com/first-look-at-gitlab-the-one-devops-platform/

این بخش کوچک و مثال ساده آن هست که درمورد بخشی از مقوله devops هست .

حال ای را بست دهید برای بیزینس های پیچیده تر .

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

حال اگر ما ۲- ۳ سال آینده و مارکت آن را امروز پیش بینی کنیم و روی آن سرمایه گذاری کنیم . چه میشود ؟

با این تصور ادامه دهید و مزایای آن را برای سازمان خود و یا خود ببینید .

عمیق تر بیاندیشیم ./

ایا کشور هایی که این موضوع را سریعتر بفهمند . سریعتر پیشرفت نمیکنند ؟

عمیق تر بیاندیشیم .

حال افراد و سازمان ها بدانند از چه ابزار هایی استفاده کنند چقدر میتوانند سود کنند . و چقدر می توانند از over engineering را کاهش دهند ؟

عمیق تر بیاندیشیم

و ...

#economy #market #yashar_esmaildokht
#linux #it #driven #technology #hitech #hi_tech

https://t.iss.one/unixmens

داده ها عنصر اصلی . دنیای امروز هستند . از داده ها و kpi ها در دواپس گرفته تا مارکتینگ مبتنی بر داده یا data driven . در همه اینها داده ها حرف میزنند .

در این بین سازمان ها به این راحتی سمت داده نمیروند . و در این maturity یا بلوغ مرتبه و مرحله هایی را داریم تا به data driven برسیم .

(خوشحالم در جهانی زندگی میکنم . که فکت و آمار و تحلیل و داده ها اهمیت دارند -- ایران هم میرسه به این روند . نگران نباشید . ما در گذر هستیم . و البته در بسیاری از جاها هم رسیدن و خوشحال بودم من نیز نقشی در این روند داده محور شدن داشتم . )

خب عزیزان گفتیم مراحلی برای رسیدن و بلوغی برای رسیدن آن وجود دارد :

برای داده محور شدن باید 5 مرحله را طی کرد:

1- مقاومت در برابر داده ها:
در ابتدا سازمان در برابر داده ها مقاومت می کند. اغلب می گویند: "ما همیش ه این کار را انجام داده ایم" - این یک امتناع دردناک هر یک از مدیران اجرایی است.

2- کنجکاوری در مورد داده ها:
در این مرحله سازمان از وجود داده ها اطلاع دارد و می داند که داده ها دارای ارزش ذاتی هستند ، حتی اگر ارزش آنها واضح نباشد. در این سازمان ها روی جمع آوری داده ها تمرکز می کنند و اغلب از ارزش بالقوه داده ها از طریق بررسی تامین کنندگان و سیستم های سازمانی آگاه می شوند

3- آگاهی از داده ها:
در مرحله آگاهی استخراج هر نوع ارز شی از داده ها رخ می دهد. شرکتهای آگاه در زمینه داده ها روی تجزیه و تحلیل تمرکز می کنند.

4- درک داده ها
در این مرحله سازمان متوجه می شود که داده ها صرفا دارای ارزش تاکتیکی نیستند؛ داده ها می توانند یک دارایی استراتژیک باشند. برای توسعه این ارزش استراتژیک ، سازمان بجای چیستی توجه خود را به چرایی معطوف می کند و به سمت توسعه بینش و بصیرت سوق می دهد.

5- داده محوری
سازمان های داده محور، تجزیه و تحلیل داده ها و بینش ها را برای پاسخ به سؤال "Waht Next" بکار می گیرند. سازمان هایی در این مرحله، در هر سطح و در هر قسمت از سازمان، داده ها را به عنوان یک منبع استراتژیک می شناسند.

#data #datadriven #data_driven #data_aware #data_resistant #data_guided
#devops #linux #culture #organization
https://t.iss.one/unixmens
unixmens

وقتی qemu/kvm پادشاه است 😍🫵😊☁️


Red Hat Virtualization (RHV)

Stack:

RHV-M Console/CLI

vdsm

libvirt

QEMU/KVM

VM


Host type: RHV Host

Notes: Uses vdsm (Virtual Desktop and Server Manager) to manage libvirt and VMs.


2. OpenShift Virtualization

Stack:

OpenShift Console/CLI

kubelet

libvirt

QEMU/KVM

KubeVirt Container


Host type: RHEL CoreOS Host

Notes: Virtualization runs inside containers with KubeVirt, allowing VMs to run alongside containers in OpenShift.

3. Red Hat OpenStack Platform (OSP)

Stack:

OpenStack Horizon/CLI

nova-compute

libvirt

QEMU/KVM

VM


Host type: OSP Compute

Notes: Uses nova-compute to manage VM lifecycle under OpenStack.

Key Takeaways

All three rely on QEMU/KVM + libvirt as the virtualization foundation.

RHV and OSP focus on VM-centric infrastructure.

OpenShift Virtualization integrates VMs into a container-native platform (via KubeVirt).


#qemu #kvm #redhat #linux #virtualization
#sddc #cloud #kubernetes
@unixmens

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

راه‌اندازی و استقرار Active Directory و Domain Controller در گنو/لینوکس

اتصال یک Active Directory Slave مایکروسافت به Master لینوکسی

استفاده از قدرت SQL Server (MSSQL) و قابلیت Always On در محیط گنو/لینوکس

مدیریت و افزودن Object Groupها در ساختار دامین

و نکات کاربردی دیگر در زمینه یکپارچه‌سازی سرویس‌های ویندوزی و لینوکسی


#microsoft #linux

unixmens
https://t.iss.one/unixmens

آیا elk یک log management هست یا ابزار مانیتورینگ ؟

پاسخ هردو


در دنیای امروز که سیستم‌ها پیچیده، توزیع‌شده و اغلب مبتنی بر ابر و راهکارهای cloud-native و Microservices هستند، سازمان‌ها بیش از هر زمان دیگری به ابزارهایی برای جمع‌آوری، تحلیل و نظارت بر داده‌ها نیاز دارند. یعنی ورود به مفاهیم و ساختار های data driven.
در این مسیر، استک ELK به‌عنوان یکی از محبوب‌ترین راهکارها برای Log Management و حتی Monitoring / Observability شناخته می‌شود.

اما اگر عمیق تر نگاه کنیم آیا این ابزار صرفاً مدیریت لاگ انجام می‌دهد یا می‌تواند نقش مانیتورینگ را هم ایفا کند؟


در واقع ELK چیست؟

در حقیقت ELK مخفف سه مؤلفه اصلی است:

Elasticsearch → موتور جستجو و پایگاه داده NoSQL برای ذخیره‌سازی و ایندکس‌گذاری لاگ‌ها.

Logstash → ابزار پردازش داده‌ها (ETL) برای جمع‌آوری، فیلتر و انتقال داده.

Kibana → ابزار تجسم داده‌ها (Visualization) و ساخت داشبورد.


نکته : ما نود های مختلفی داریم برای data برای ذخیره‌سازی داکیومنت هاذو شارد ها .
نود master
نود ingest
نود cordinator
نود data که خود این نود هم شامل ساختار ilm هست که به hot 🔥, warm 🥵 , و cold 🥶 را شامل میشود و در ادامه repository برای ذخیره داده های قدیمی تر .

نکته : میتوان در کلاستر از logslash استفاده نکرد و از نود با وظیفه ingest استفاده کرد . البته این دو نود هر کدام نکته های باریک دارند .
بررسی ELK به‌عنوان Log Management :

در ابتدا ELK به‌عنوان یک Log Management Platform معرفی شد:

جمع‌آوری لاگ‌های سیستمی، اپلیکیشنی و شبکه‌ای

پردازش و نرمال‌سازی داده‌ها

ذخیره‌سازی در Elasticsearch

جستجو، تحلیل و ساخت گزارش در Kibana


به همین دلیل ELK معمولاً در کنار ابزارهایی مثل Splunk یا Graylog دسته‌بندی می‌شود.

بررسی ELK به‌عنوان ابزار Monitoring / Observability :

با گذشت زمان و توسعه‌ی ELK، قابلیت‌های آن گسترش یافت:

امکان تعریف Alerting و هشدار (با X-Pack یا Elastic Alerting)

داشبوردهای Real-Time در Kibana

پشتیبانی از APM (Application Performance Monitoring) و Metrics (از طریق Beats مثل Metricbeat)

استفاده در امنیت (Elastic SIEM)


بنابراین ELK از یک Log Management ساده فراتر رفت و به سمت یک پلتفرم Monitoring و حتی Observability حرکت کرد.


در واقع ELK در اصل یک Log Management Platform است.

اما در عمل، با اضافه شدن قابلیت‌های Dashboard، Alerting و APM، و ... به یک Monitoring و Observability Platform نیز تبدیل می‌شود.


بنابراین ELK را می‌توان هم به‌عنوان مدیریت لاگ و هم به‌عنوان ابزار مانیتورینگ در نظر گرفت؛ بسته به اینکه سازمان از آن در چه سطحی و با چه افزونه‌هایی استفاده کند.


#devops #linux #elk #elasticsearch




https://t.iss.one/unixmens

مفهوم Fleet در ELK چیست؟

در واقع Fleet یک ابزار مدیریتی در Elastic Stack است که برای مدیریت متمرکز Agentها طراحی شده.
در واقع، وقتی شما می‌خواهید روی سرورها، کلاینت‌ها یا کانتینرها داده (لاگ، متریک، امنیت، APM و غیره) جمع‌آوری کنی، باید Elastic Agent نصب بشه.
مدیریت دستی تعداد زیادی Agent (نصب، پیکربندی، به‌روزرسانی) سخت می‌شه.
اینجاست که Fleet وارد عمل میشه.

وظایف Fleet چیست ؟

1. مدیریت متمرکز Agentها

از طریق Kibana می‌تونی Agentها رو نصب، پیکربندی و مدیریت کنی.

نیازی نیست روی هر سرور جداگانه تغییرات اعمال کنی.



2. Policy Management

تعریف Policy (مثلاً جمع‌آوری لاگ‌های سیستم، متریک CPU و لاگ‌های Nginx).

این Policy به صورت خودکار روی Agentها اعمال میشه.



3. Data Ingestion ساده‌تر

در Fleet داده‌ها رو از طریق Elastic Agent به Elasticsearch می‌فرسته.

این داده‌ها می‌تونن شامل:

لاگ‌ها (Log Files)

و Metrics (سیستم و اپلیکیشن‌ها)

داده‌های امنیتی (Endpoint Security)

داده‌های APM

باشه .


4. Integration Hub

در Fleet یک Integration Hub وجود داره که ده‌ها Integration آماده برای سرویس‌ها (مثل MySQL, Nginx, Kubernetes, AWS) رو فراهم می‌کنه.

کافیه انتخابش کنیم تا Agent ها تنظیمات مربوطه رو اعمال کنن.



تفاوت Elastic Agent + Fleet با Beats

قبل از Elastic Agent، باید از Filebeat، Metricbeat، Packetbeat و … جداگانه استفاده می‌کردیم.

هر کدوم نصب و تنظیم خودشون رو داشتن.

الان Elastic Agent اومده و همه رو یکپارچه کرده.

و Fleet هم مدیریت مرکزی همین Agentهاست.


مزایای Fleet

مدیریت ساده در مقیاس بالا (ده‌ها یا صدها سرور)

پشتیبانی از Integrationهای آماده

امکان امنیت مرکزی برای Agentها (از طریق Kibana)

جایگزینی مدرن برای Beats

مناسب برای محیط‌های Cloud و Kubernetes خلاصه:
در واقع Fleet یک کنسول مدیریتی متمرکز در Kibana است که برای مدیریت Elastic Agentها استفاده می‌شود.
این ابزار فرآیند نصب، پیکربندی، به‌روزرسانی و مدیریت Policy را ساده می‌کند و عملاً نسل جدید مدیریت داده در ELK به شمار می‌آید.


#elk #linux #security #elasticsearch #kibana


unixmens

https://t.iss.one/unixmens

ا. GitLab Kubernetes Agent چیست؟

ا. GitLab Kubernetes Agent یک کامپوننت نرم‌افزاری است که داخل کلاستر Kubernetes نصب می‌شود و به صورت دوطرفه (bi-directional) با GitLab ارتباط برقرار می‌کند.
برخلاف روش قدیمی (integration با استفاده از kubeconfig یا API مستقیم)، این Agent یک کانال ارتباطی امن و پایدار بین GitLab و کلاستر ایجاد می‌کند

وظایف و قابلیت‌های اصلی

1. ارتباط امن و پایدار با کلاستر

بجای اینکه GitLab از بیرون به API کلاستر دسترسی داشته باشد (که خطرناک است)، Agent در داخل کلاستر اجرا شده و خودش ارتباط امن (TLS + gRPC) را با GitLab برقرار می‌کند.



2. GitOps (Declarative Deployments)

ا. Agent می‌تواند تغییرات تعریف‌شده در ریپازیتوری GitLab (مثل manifestها و Helm chartها) را به‌طور خودکار با وضعیت کلاستر هماهنگ کند.

یعنی وقتی شما کدی را commit کنید که شامل تغییر در Kubernetes manifests باشد، Agent این تغییرات را به کلاستر اعمال می‌کند.



3. CI/CD Integration

امکان اجرای jobهای CI/CD که نیاز به ارتباط با کلاستر دارند (مثل deploy، تست E2E، security scans).

دسترسی به کلاستر بدون نیاز به اشتراک‌گذاری kubeconfig در pipeline.



4. Cluster Observability

ا. Agent اطلاعات وضعیت کلاستر (nodes, pods, workloads) را به GitLab گزارش می‌دهد.

این کار امکان monitoring و visualization مستقیم از داخل GitLab UI را فراهم می‌کند.



5. Multi-cluster Management

با یک GitLab می‌توان چندین کلاستر را مدیریت کرد (Dev, Staging, Prod).

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



6. Policy Enforcement و Security

می‌توان policyهایی تعریف کرد (مثلاً فقط برخی namespaceها یا resourceها قابل دسترسی باشند).

این باعث می‌شود امنیت نسبت به روش قدیمی kubeconfig خیلی بالاتر باشد.

مشکلات روش kubeconfig قدیمی نسبت به GitLab Kubernetes Agent

امنیت :
نیاز به ذخیره kubeconfig در GitLab (ریسک نشت) ارتباط gRPC امن از داخل کلاستر
ا. GitOps محدود : پشتیبانی کامل (Pull-based deployment)
مقیاس‌پذیری سخت : (برای چندین کلاستر) اما در اجنت ساده تر است . (هر کلاستر Agent خودش را دارد)
ا Observability محدود : اما در اجنت یکپارچه با GitLab UI
مدیریت Policy دستی و پشتیبانی داخلی

#devops #gitlab #kubernetes #k8s #grpc #security #linux #cluster

https://t.iss.one/unixmens

When we say Linux knowledge is very important, the reasons are both technical and strategic. This importance can be explained in a few layers:

The basic infrastructure of the IT and Cloud world :

More than 90% of large Internet services (from Google and Facebook to Amazon and Netflix) run on Linux.

The dominant operating system is in public schools such as AWS, GCP and Azure Linux.

Most important databases (MySQL, postgresql, mongodb, oracle DB works better on Linux)

Security and control :

Linux is the open source (Open Source); That is, it has transparency in the code and the security audit capability.

Low -level security tools and hardness (such as Selinux, Apparmor, iPTables, Nftables ,cgroup , namespace) are more powerful in Linux.

A specialist who knows Linux can take full control of the system, not just superficial use.

Devops and Automation :


Almost all Devops (ANSIBLE, TERRAFORM, KUBERNETES, DOCKER, JENKINS) tools are born on Linux and have the best performance on Linux.

Scripting with Bash and combining it with Linux tools (Sed, AWK, GREP, etc.) is the main part of automation.

Network infrastructure and internet :

Vital Internet services (DNS, Web, Mail, Proxy, VPN) have been developed on the Linux platform.

For a network or security specialist, Linux knowledge means direct management of infrastructure service

Stability and scalability :

Linux is a scalable and stable operating system; From mobile (Android) to supercamapiers.

The world's top 5 superpowers work on Linux.

Engineering :

Linux teaches the user how the system works, not just how to use it.

This makes the person upgraded from the "simple user" to the "engineer and architect"
🔑 :
Linux knowledge is important because the cornerstone of the modern digital world, security, and organizational transformation is based on Linux.


#linux #devops #k8s #clustering #kernel

در دنیای امروزی، حجم ترافیک شبکه به شکل انفجاری در حال رشد است. از دیتاسنترهای ابری گرفته تا شبکه‌های 5G، نیاز به پردازش سریع بسته‌های شبکه، بدون تأخیر (low latency) و با ظرفیت بالا (high throughput)، بیش از هر زمان دیگری احساس می‌شود.

سخت‌افزارهای سنتی مثل ASICها و FPGAها قدرت بالایی در پردازش بسته دارند، اما انعطاف‌پذیری کمی دارند. در مقابل، سرورهای عمومی (COTS Servers) انعطاف‌پذیرند، ولی عملکرد پردازش بسته روی Kernel Networking Stack محدود است.

اینجاست که DPDK (Data Plane Development Kit) وارد می‌شود:
یک کتابخانه متن‌باز برای پردازش کارآمد بسته‌ها روی سرورهای عمومی.
ا DPDK چیست؟

در واقع DPDK مجموعه‌ای از کتابخانه‌ها و درایورهاست که امکان بای‌پس کردن کرنل (Kernel Bypass) و دسترسی مستقیم به سخت‌افزار شبکه را فراهم می‌کند.
(مراجعه شود به monolithic kernel و micro service kernel )
زبان توسعه: C

مجوز: BSD (کاملاً متن‌باز)

پشتیبانی: جامعه متن‌باز + شرکت‌هایی مثل Intel، Red Hat، Mellanox (NVIDIA)، Arm، Huawei، و غیره
معماری DPDK

معماری DPDK را می‌توان به چند لایه تقسیم کرد:

مدیریت سخت‌افزار (HW Management)

مدیریت حافظه، CPU، و دستگاه‌ها

تضمین سازگاری روی CPUها و کرنل‌های مختلف

درایورها (Poll Mode Drivers)

حذف وقفه‌ها (interrupts) و استفاده از polling برای دریافت/ارسال بسته‌ها

کاهش overhead کرنل

ساختار داده‌ها

mempool: مدیریت حافظه بهینه برای bufferها

mbuf: نمایش بسته شبکه به عنوان یک شیء سبک

3.4 کتابخانه‌های پردازش بسته

Ethernet, IP fragmentation, TCP segmentation

QoS, Crypto, Compression

Tunnels, Classification, Flow Offload

لایه کاربردی

اپلیکیشن‌های شبکه‌ای مثل VNFها، روتر مجازی، فایروال، SDN Controller

ویژگی‌های کلیدی

ا High Performance: میلیون‌ها PPS (Packet Per Second) روی سخت‌افزار عمومی

Low Latency: مناسب برای 5G، مالی (HFT)، و Real-time

ا Portability: سازگار با Linux، FreeBSD، و معماری‌های CPU مختلف

ا Extensible: امکان افزودن ماژول‌های پردازش سفارشی

اکوسیستم DPDK

اکوسیستم DPDK بسیار گسترده است و شامل بخش‌های زیر می‌شود:

پروژه‌ها و نرم‌افزارهای وابسته

ا Open vSwitch (OVS-DPDK): نسخه شتاب‌یافته OVS برای دیتاسنترها

ا VPP (Vector Packet Processing): محصول پروژه FD.io، جایگزین kernel stack

ا Snort & Suricata (IDS/IPS): نسخه‌های بهینه‌سازی‌شده با DPDK

ا TRex Traffic Generator: ابزار تولید ترافیک پرقدرت مبتنی بر DPDK

صنعت و کاربردها

ا NFV (Network Function Virtualization): شتاب‌دهی VNFs روی سرورهای COTS

ا Telco/5G: Core Network، Baseband و Packet Core

ا Cloud & Data Center: بهبود عملکرد SDN و NFV

ا Security: شتاب‌دهی فایروال‌ها، VPNها، و ابزارهای رمزنگاری

رقبا و مکمل‌ها

ا eBPF / XDP (Linux Kernel): پردازش بسته درون کرنل

ا SmartNIC / FPGA: سخت‌افزارهای تخصصی با قابلیت offload

ا P4 / programmable switches: برنامه‌نویسی مستقیم روی ASIC

مزایا و چالش‌ها

✅ مزایا

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

متن‌باز بودن و حمایت جامعه بزرگ

کاهش نیاز به سخت‌افزار اختصاصی گران‌قیمت

انعطاف‌پذیری برای توسعه اپلیکیشن‌های سفارشی

❌ چالش‌ها

نیاز به Pinned CPU cores → مصرف منابع زیاد

پیچیدگی برنامه‌نویسی (C سطح پایین)

مناسب‌تر برای محیط‌های user space → ادغام با کرنل سخت‌تر است

بهینه‌سازی دقیق لازم دارد (NUMA, Cache, HugePages)

آینده DPDK

ادغام بیشتر با SmartNICs و programmable hardware

ترکیب با eBPF/XDP برای انعطاف‌پذیری بالاتر

استفاده گسترده‌تر در 5G Core, Edge Computing, و Cloud-native Networking

تمرکز روی energy efficiency برای کاهش مصرف CPU


#linux #kernel #sdn #cloud #devops #ebpf #dpdk

https://t.iss.one/unixmens

رشد سریع دیتاسنترهای ابری، شبکه‌های 5G و سرویس‌های Cloud-native، نیاز به پردازش پرسرعت بسته‌های شبکه بیش از هر زمان دیگری اهمیت پیدا کرده است. روش سنتی مبتنی بر Kernel Networking Stack به دلیل overhead بالا، پاسخگوی نیازهای امروزی نیست.

برای رفع این مشکل دو رویکرد اصلی مطرح شده‌اند:

ا DPDK (Data Plane Development Kit): رویکرد Kernel bypass در User Space

ا eBPF/XDP (extended Berkeley Packet Filter): پردازش انعطاف‌پذیر در Kernel Space
اینجا به بررسی هر یک میپردازیم :

معماری و فلسفه طراحیeBPF

ا eBPF یک مکانیزم درون‌هسته‌ای (in-kernel) است که به برنامه‌ها اجازه می‌دهد کدهای کوچک و امن را در کرنل لینوکس اجرا کنند. فلسفه اصلی آن انعطاف‌پذیری و قابلیت مشاهده (observability) است. eBPF به کاربران اجازه می‌دهد بدون تغییر در کرنل، منطق دلخواه خود را در سطح شبکه، امنیت و مانیتورینگ اضافه کنند. برنامه‌های eBPF در محیطی ایزوله (sandbox) اجرا می‌شوند و توسط verifier کرنل اعتبارسنجی می‌شوند تا مانع ایجاد مشکلات پایداری شوند.



ا DPDK یک مجموعه کتابخانه و درایور است که هدف اصلی آن حداکثرسازی سرعت پردازش بسته‌ها در فضای کاربر (user space) است. فلسفه آن مبتنی بر دور زدن کرنل و حذف لایه‌های سربار مانند socket و interrupt است. DPDK با استفاده از تکنیک‌هایی مانند polling و zero-copy، پردازش بسته‌ها را به شکل مستقیم از NIC (کارت شبکه) به فضای کاربر منتقل می‌کند.

عملکرد و کارایی

ا eBPF بیشتر بر روی انعطاف‌پذیری و قابلیت برنامه‌ریزی تمرکز دارد. این یعنی می‌توان بدون نوشتن ماژول کرنل، سیاست‌های پیچیده فایروال، ردیابی جریان‌ها و ابزارهای observability مانند bcc یا Cilium را ساخت. از نظر کارایی، سرعت آن مناسب است اما به دلیل وجود در کرنل، همچنان محدودیت‌هایی دارد.

ا DPDK برای عملکرد خام (raw performance) طراحی شده است. در سیستم‌هایی که نیاز به میلیون‌ها بسته در ثانیه (Mpps) وجود دارد، DPDK انتخاب بهتری است. اما این سرعت با مصرف بالاتر منابع CPU و پیچیدگی بیشتر توسعه همراه است.

سطح پیاده‌سازی و توسعه

ا eBPF توسعه‌دهندگان را قادر می‌سازد با استفاده از زبان C یا LLVM-based زبان‌ها، کدهای کوچک و قابل بررسی تولید کنند. توسعه آن ساده‌تر است زیرا مستقیماً با کرنل لینوکس ادغام شده و نیاز به مدیریت مستقیم منابع سخت‌افزاری ندارد.

ا DPDK توسعه‌دهنده را ملزم می‌کند که با سطح پایین‌تری از سخت‌افزار و پردازش بسته‌ها کار کند. برنامه‌نویسی با DPDK نیازمند درک عمیق از معماری CPU، حافظه و NIC است.

کاربردها eBPF

ساخت فایروال‌های مدرن مانند Cilium در Kubernetes.

مانیتورینگ شبکه، سیستم و عملکرد برنامه‌ها (مانند bpftrace).

امنیت در سطح هسته با قابلیت مشاهده دقیق رفتار برنامه‌ها.

ابزارهای observability برای Cloud-native environments.

DPDK

ساخت سیستم‌های SDN و NFV با کارایی بالا.

استفاده در فایروال‌ها، load balancerها و IDS/IPS با نیاز به throughput بسیار بالا.

محیط‌هایی که latency و jitter باید حداقل باشد، مانند مخابرات و 5G core.

زیرساخت‌های دیتاسنتر با پردازش میلیون‌ها بسته در ثانیه.

مزایا و محدودیت‌ها

ا eBPF مزایای بزرگی مانند سادگی توسعه، امنیت، قابلیت ترکیب با ابزارهای موجود لینوکس و عدم نیاز به bypass کرنل دارد. محدودیت اصلی آن، کارایی پایین‌تر نسبت به DPDK در بارهای بسیار سنگین است.

ا DPDK در کارایی بی‌نظیر است اما توسعه پیچیده‌تر، نیاز به منابع CPU بالا، و مدیریت دشوارتر دارد. همچنین برخلاف eBPF، tightly coupled با کرنل نیست و قابلیت observability گسترده ارائه نمی‌دهد.


مکمل بودن

ا eBPF و DPDK الزاماً رقیب مستقیم نیستند. در بسیاری از معماری‌های مدرن، این دو مکمل هم هستند:

ا eBPF: برای مشاهده‌پذیری (observability)، مانیتورینگ، امنیت و کنترل.

ا DPDK: برای دیتاپلین پرسرعت و پردازش سنگین بسته‌ها


#linux #kernel #devops #kubernetes #ebpf #dpdk


https://t.iss.one/unixmens

ابزار Kubernetes و چالش‌های آن: چرا ترکیب OpenShift/KubeSphere با KubeVirt بهترین گزینه برای سازمان‌هاست؟

مقدمه

بسیاری تصور می‌کنند گوگل از Kubernetes در زیرساخت داخلی خود استفاده می‌کند. در حالی که واقعیت این است که گوگل همچنان از سیستم‌های پیشرفته‌تر خود یعنی Borg و Omega بهره می‌برد؛ زیرا این سیستم‌ها برای مدیریت دیتاسنترهای عظیم گوگل طراحی شده‌اند و در مقیاس‌های فراتر از Kubernetes کارایی بالاتری دارند. Kubernetes در واقع بر اساس تجربیات همان پروژه‌ها ساخته شد و به صورت متن‌باز ارائه گردید تا جامعه جهانی از آن استفاده کند.

اما نکته مهم اینجاست: Kubernetes در دنیای سازمانی امروز، با وجود قدرت و انعطاف‌پذیری بالا، همچنان چالش‌برانگیز است.

چرا Kubernetes چالش‌برانگیز است؟

پیچیدگی عملیاتی: نصب، مدیریت و نگهداری Kubernetes حتی برای تیم‌های حرفه‌ای آسان نیست.

نیاز به مهارت بالا: تیم‌ها باید دانش عمیق در مفاهیم Networking، Storage، Security و CI/CD داشته باشند.

چالش‌های امنیتی: به‌صورت پیش‌فرض امنیت Kubernetes در سطح Enterprise کافی نیست.

مدیریت چندخوشه‌ای (Multi-Cluster): برای سازمان‌های بزرگ به یک کابوس مدیریتی تبدیل می‌شود.

هزینه آموزش و یادگیری: ورود تیم‌های جدید زمان‌بر و پرهزینه است

چرا گوگل هنوز Borg و Omega را ترجیح می‌دهد؟

مقیاس‌پذیری فراتر از Kubernetes: در دیتاسنترهای گوگل که میلیون‌ها کانتینر اجرا می‌شود، Borg و Omega بهینه‌تر هستند.

ثبات و تجربه عملیاتی: گوگل بیش از یک دهه این سیستم‌ها را بهبود داده و آن‌ها را در بالاترین سطح تولیدی استفاده می‌کند.

کاستومایز اختصاصی: Borg و Omega کاملاً بر اساس نیازهای خاص گوگل طراحی شده‌اند، در حالی که Kubernetes یک پلتفرم عمومی برای جامعه جهانی است.

راه‌حل سازمان‌ها: OpenShift و KubeSphere

برای بیشتر سازمان‌ها، استفاده مستقیم از Kubernetes بدون ابزارهای تکمیلی منجر به مشکلات جدی می‌شود. اینجا است که OpenShift و KubeSphere وارد میدان می‌شوند:

OpenShift (Red Hat):

امنیت سازمانی قوی (SELinux، RBAC پیشرفته).

تجربه توسعه‌دهنده کامل (داشبورد، CI/CD داخلی).

پشتیبانی رسمی و Enterprise از سوی Red Hat/IBM.


KubeSphere:

نصب ساده و رابط کاربری کاربرپسند.

مدیریت چند خوشه‌ای (Multi-Cluster) با قابلیت‌های گسترده.

ماژول‌های آماده برای DevOps، نظارت، و Service Mesh.

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

نقش KubeVirt: اتصال VMها و Containerها

یکی از مشکلات رایج سازمان‌ها این است که هنوز بارهای کاری Legacy (روی VMها) دارند.
با KubeVirt:

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

مهاجرت تدریجی از VM به Container بدون نیاز به دو پلتفرم جداگانه امکان‌پذیر می‌شود.

هزینه زیرساخت کاهش پیدا می‌کند و تیم‌ها فقط یک ابزار مدیریت نیاز دارند.


در حالی که گوگل همچنان برای دیتاسنترهای داخلی خود از Borg و Omega استفاده می‌کند، Kubernetes به عنوان استاندارد جهانی معرفی شده است. با این وجود، Kubernetes به‌تنهایی برای سازمان‌ها بسیار چالش‌برانگیز است.

راه‌حل درست برای ورود به دنیای Cloud-Native در سطح سازمانی، استفاده از پلتفرم‌های تکمیلی مثل OpenShift یا KubeSphere و ترکیب آن‌ها با KubeVirt است. این ترکیب نه‌تنها مشکلات پیچیدگی و امنیت را کاهش می‌دهد، بلکه امکان همگرایی کامل میان بارهای کاری سنتی (VM) و مدرن (Container) را فراهم می‌کند.
#kubernetes #devops #clustering #k8s #linux #security #google #borg #omega
https://t.iss.one/unixmens

At VeeamON 2024, Veeam announced that in the upcoming version (likely v13), the Veeam Backup & Replication (VBR) Server will be available for Linux systems, in addition to Windows.


Historically, VBR has required a Windows installation. This move to support Linux is a long-awaited shift that many in the community have requested.


Deployment and design details mentioned in the post (though subject to change):

Expected delivery as an OVA (virtual appliance).

Likely based on a hardened Rocky Linux 9.2, managed by Veeam.

It will include a web-based console—though it's unclear if the traditional Windows console will also be available.

Initially, the Linux option may not support other distributions, focusing solely on Rocky Linux at launch.

Feature parity with the Windows version is hoped for, but not guaranteed.


Broader Context & Updates Since Then
Veeam Backup & Replication Version Info

The latest official release is v12.3.1.1139, released on March 19, 2025.
Wikipedia

As of that version, the Linux deployment of the VBR server was not yet available. VBR still runs on Windows in v12.

v13 Rolling Out with Linux Support

On September 3, 2025, Veeam officially released Veeam Backup & Replication 13 (v13)—but only as a Linux-based Software Appliance (VSA). The Windows installer is still pending and expected to come out in the coming months.



Available formats:

OVA (pre-built virtual appliance) for VMware vSphere (requires ESXi 7.0 U2 or later).

ISO for physical host or alternate hypervisor installations—with system requirements including:

x86-64 CPU with at least 8 cores.

Minimum 16 GB RAM, plus ~500 MB per concurrent job.

Two 240 GiB disks (for OS and installation).

Network: 1 Gbps+ local or 1 Mbps+ WAN connection.


Some existing Windows component dependencies still remain. For example, a Windows mount server is required for certain restore scenarios.


Due to the architecture changes in v13, Veeam has extended support for v12 (including its agents and plugins) to 4 years instead of the usual 3


#veeam #linux #backup

بررسی نرخ مربوط به داده و فرمول اختصاص محاسبه تقریبی رم

نسبت به نرخ داده در elasticsearch



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


امید هست ، مورد استفاده ، جامعه It , devops , bigdata کشور قرار گیرد .





پذیرای هرگونه از پیشنهادات و نظرات و انتقادات شما عزیزان میباشم .


#data #elk #elasticsearch #linux #bigdata #log #etl

#yashar_esmaildokht

https://t.iss.one/unixmens

خرید Isovalent توسط سیسکو؛ گامی استراتژیک در آینده‌ی شبکه و امنیت چندابری

مقدمه

در دنیای فناوری اطلاعات، خریدها و ادغام‌های استراتژیک اغلب مسیر آینده‌ی صنعت را شکل می‌دهند. یکی از مهم‌ترین خریدهای اخیر در حوزه شبکه و امنیت، خرید شرکت Isovalent توسط سیسکو (Cisco Systems) است؛ حرکتی که نه تنها جایگاه سیسکو در بازار شبکه‌های ابری و چندابری را تقویت می‌کند، بلکه آینده‌ی فناوری‌های مبتنی بر eBPF را نیز رقم خواهد زد.
پیشینه خرید

در ۲۱ دسامبر ۲۰۲۳، سیسکو اعلام کرد که قصد خرید Isovalent را دارد.

این معامله در ۱۲ آوریل ۲۰۲۴ نهایی شد.


با این خرید، سیسکو مالکیت فناوری‌های کلیدی Isovalent مانند Cilium و Tetragon را به دست آورد؛ ابزارهایی که به‌ویژه در دنیای Cloud Native و محیط‌های چندابری به‌سرعت در حال تبدیل شدن به استاندارد صنعتی هستند.
فعالیت Isovalent و نقش آن در صنعت

در واقع Isovalent شرکتی پیشرو در توسعه‌ی راهکارهای شبکه و امنیت مبتنی بر eBPF است. eBPF (Extended Berkeley Packet Filter) یک فناوری قدرتمند در هسته لینوکس است که امکان نظارت، مشاهده‌پذیری (observability)، و اعمال سیاست‌های امنیتی در سطح پایین سیستم‌عامل را بدون نیاز به تغییر کد کرنل فراهم می‌کند.

محصولات کلیدی Isovalent

1. Cilium:

یک پلتفرم متن‌باز برای شبکه‌سازی Cloud Native در Kubernetes.

قابلیت‌هایی مانند شبکه‌سازی امن، load balancing و observability را ارائه می‌دهد.



2. Tetragon:

یک ابزار امنیتی پیشرفته مبتنی بر eBPF.

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

انگیزه‌های سیسکو از این خرید

1. تقویت موقعیت در بازار چندابری (Multicloud):
بسیاری از سازمان‌ها امروزه از چندین ارائه‌دهنده ابر استفاده می‌کنند. سیسکو با Cilium و Tetragon می‌تواند یک لایه مشترک شبکه و امنیت بر فراز تمام ابرها ایجاد کند.


2. افزایش توان امنیتی:
با eBPF، سیسکو می‌تواند قابلیت‌های امنیتی را از سطح سخت‌افزار و شبکه‌های سنتی به سطح نرم‌افزار و workloadها منتقل کند.


3. نوآوری در Observability و Performance:
ترکیب فناوری‌های Isovalent با محصولات سیسکو، امکان پایش لحظه‌ای و بهینه‌سازی عملکرد در مقیاس بالا را فراهم می‌کند.


4. هم‌افزایی با اکوسیستم متن‌باز:
خرید Isovalent به معنای ورود جدی‌تر سیسکو به دنیای پروژه‌های متن‌باز است که برای نوآوری در زیرساخت‌های ابری حیاتی است.
تأثیرات این خرید بر صنعت

تقویت جایگاه eBPF به‌عنوان ستون فقرات شبکه‌سازی و امنیت در محیط‌های ابری.

رقابت شدیدتر با شرکت‌هایی مانند VMware، Google و Red Hat در حوزه Cloud Native Networking.

ایجاد یکپارچگی بیشتر بین زیرساخت‌های سنتی شبکه سیسکو و جهان Cloud Native و Kubernetes

خرید Isovalent توسط سیسکو را می‌توان یک حرکت استراتژیک و آینده‌نگرانه دانست که مسیر تحول در شبکه‌سازی ابری، امنیت workloadها و observability را تغییر خواهد داد. سیسکو با این اقدام، نه‌تنها قدرت خود را در بازار شبکه‌های سازمانی تثبیت می‌کند، بلکه خود را به‌عنوان یکی از بازیگران اصلی در دنیای چندابری و Cloud Native مطرح می‌سازد.


#cisco #isovation #linux #kernel #ebpf #tetragon #cilium

https://t.iss.one/unixmens

دواپس و مسیر های ورود به آن



#devops #linux #infra #infrastructure #system #design #network #programmer #developer




https://t.iss.one/unixmens

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

اما چرا ؟

🔹 دلیلش ساده است:
وقتی سال‌ها با سیستم‌عامل، استوریج، دیتابیس، شبکه لینوکسی، HA، replication و tuning کار کرده‌ای، به‌صورت تجربی یاد می‌گیری که:

چطور منابع محدود (CPU, RAM, Disk I/O, Network) را بین سرویس‌ها طراحی و بهینه کنی.

چطور برای scalability، سیستم را افقی (scale-out) یا عمودی (scale-up) توسعه دهی.

چه الگوهایی برای High Availability و Fault Tolerance وجود دارد.

چطور داده را در مقیاس بالا توزیع و ایمن نگه دارد

تفاوت با بقیه مسیرها

برنامه‌نویس‌ها بیشتر روی design در سطح کد (Design Patterns, Microservices Architecture) تمرکز دارند، اما وقتی صحبت از زیرساخت و ظرفیت سیستم می‌شود، عمق لازم را ندارند.

متخصصان شبکه هم system design را معمولاً فقط در لایه‌ی ارتباطات می‌شناسند (topology، routing، segmentation) نه در کل stack.


اما متخصص زیرساخت، وقتی از system design صحبت می‌کند، یعنی دید End-to-End دارد:
از block storage و replication گرفته تا شبکه، دیتابیس و اپلیکیشن.

چرا این در DevOps مهم است؟

چون DevOps فقط ابزار نیست؛ DevOps یعنی طراحی یک سیستم پایدار، مقیاس‌پذیر و قابل‌اعتماد.

اگر system design بلد نباشی، صرفاً ابزارها را به هم می‌دوزی.

ولی اگر system design را بفهمی، ابزارها را بر اساس نیاز واقعی سیستم انتخاب و ترکیب می‌کنی.


به همین خاطر کسی که از زیرساخت آمده، معمولاً در تیم DevOps نقش معمار (Architect) را هم می‌تواند بر عهده بگیرد، در حالی که بقیه مسیرها بیشتر در نقش مجری یا توسعه‌دهنده باقی می‌مانند.



#devops #linux #infra #infrastructure #system #design #network #programmer #developer




https://t.iss.one/unixmens

دوستان دواپسی نکته ای را از یاد نبریم

دواپس نصب سریع ابزار ها نیست .
دواپس سرعت بخشیدن به کارهای تکراری و toil work هست
دواپس یعنی داشتن درک system design .
از یاد نبریم وقتی شغل هایی که مفهوم engineer را یدک میکشن . به معنای ، implementation ، problem solving, optimisation, upgradation هست .

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

هدف نصب و استقرار به جای ۱ ساعت در ۱۰ دقیقه و ندانستن اجزا و رفع اون نیست .

اون مورد سرعت و اتومیشن هم برای bcp و drp هست ، در واقع شناخت اجزای سیستم و قابلیت حل مسائل در شرایط حساس مانند BCP/DRP.


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

وهمچنین درک ساختار در موضوعات operation , prosessing , tecnical بخش جدانشدنی از این مسیر است.


#devops #linux #culture #team

https://t.iss.one/unixmens