انجمن‌های فارسی اوبونتو
جامعه کاربران => کافه اوبونتو => نویسنده: shena در 25 اسفند 1400، 06:17 ب‌ظ
-
احتمالا می دونید که CentOS ورژن 7 آخرین نسخه ای هست که با پشتیبانی از جنس LTS ارائه شده و از نسخه ۸ به نوعی میشه گفت که CentOS به صورت Rolling Release در اومده و جای فدورا رو در Upstream بودن برای ردهت احتمالا می گیره.
بعد از این تصمیم ردهت، پارسال یه جمعی از سنت او اس جدا شدن و Rocky رو زدن. الآن هم AlmaLinux رو داریم.
اگر تجربه ای در سازمان تون برای تصمیم گیری در جایگزینی CentOS دارین، ممنون میشم اشتراک بذارید. و معیارهاتون چیه؟
https://almalinux.org
https://rockylinux.org
-
فکر نکنم فرق خاصی داشته باشند. از اونجایی که میشه اونها رو بدون مشکل زیادی به هم تبدیل کرد، بعید می‌دونم فرق خاصی با هم داشته باشند.
-
فکر نکنم فرق خاصی داشته باشند. از اونجایی که میشه اونها رو بدون مشکل زیادی به هم تبدیل کرد، بعید می‌دونم فرق خاصی با هم داشته باشند.
نه، نمی شه بعدا دوباره کوچ کرد. همین الآن هم که باید سرویسها رو از سنت اوس کوچ بدیم خودش غصه شده، چه برسه دوباره قرار باشه چند ماه بعد همین کار رو بخوایم بکنیم اگر مثلا انتخابمون خوب نباشه ](*,)
-
من با هیچ کدوم کار نکردم ولی تا اون‌جا که شنیدم، نظر روی AlmaLinux بوده. دلیلش هم رو نمی‌دونم.
من خودم از دبیان برای تمام سرورها استفاده میکنم. شما هم میتونی یه تجدیدنظر توی استفاده از سیستم‌عامل مورد استفاده کنی.
-
یک سوال دارم، اینا چه امکانات بیشتری داره که دبیان نداره؟
دبیان که به پایدار بودن معروفه، چرا از دبیان استفاده نمیشه؟
-
پشتیبانی طولانی دارند. تا ۱۰ سال بروزرسانی امنیتی دریافت می‌کنند. برای سازمان‌ها که تعداد زیادی سرور دارند، مناسبه چون می‌تونند تا مدتی زیادی، خیالشون از ارتقا سیستم‌عامل راحت باشه.
ولی بهتره هر ۵ سال یه بار که نسخه جدید میاد،اون رو نصب کرد. همینجوری وقتی که نسخه جدید این توزیع‌ها منتشر میشه، برنامه‌های قدیمی دارند (rocky linux وقتی منتشر شد، نسخه bash اون مربوط به دو سال قبل تاریخ انتشار بود)
-
پشتیبانی طولانی دارند. تا ۱۰ سال بروزرسانی امنیتی دریافت می‌کنند. برای سازمان‌ها که تعداد زیادی سرور دارند، مناسبه چون می‌تونند تا مدتی زیادی، خیالشون از ارتقا سیستم‌عامل راحت باشه.
ولی بهتره هر ۵ سال یه بار که نسخه جدید میاد،اون رو نصب کرد. همینجوری وقتی که نسخه جدید این توزیع‌ها منتشر میشه، برنامه‌های قدیمی دارند (rocky linux وقتی منتشر شد، نسخه bash اون مربوط به دو سال قبل تاریخ انتشار بود)
یک بروزرسانی مگه چیز خاصی داره؟ نمیشه مثلا ۲۰ تا سرور به نوبت آپدیت بشه مشکل پیش نیاد؟ (البته خودم هیچ اطلاعاتی در این مورد ندارم نمی دونم میشه اصلأ چند تا سرور می تونن یک سایتی رو میزبانی کنن یا نه)
-
بهتون توصیه میکنم که یه نگاهی به proxmox داشته باشید. یه سیستم virtualization بر اساس KVM و یا LXC هست و همچنین سیستم Backup خیلی خوش دستی داره.
https://proxmox.com/en/proxmox-ve
یه سناریو میتونه این باشه که روی clusterی که دارید، این رو نصب کنید و سپس برای ویندوزهای guest از KVM استفاده کنید (با قابلیت live migration) و برای سیستم‌های بر پایه هسته لینوکس، از LXC (سرعت بالاتر ولی بدون قابلیت live migration). در LXC تنها بین ۱ تا ۳ درصد از توانایی سیستم بدلیل مجازی سازی از دسترس شما خارج میشه.
این proxmox تنها بر پایه دبیان کار میکنه.
اگه سوالی در مورد proxmox داشتی میتونی یه تاپیک جدا بزنی و بپرسی.
-
نه، نمی شه بعدا دوباره کوچ کرد. همین الآن هم که باید سرویسها رو از سنت اوس کوچ بدیم خودش غصه شده، چه برسه دوباره قرار باشه چند ماه بعد همین کار رو بخوایم بکنیم اگر مثلا انتخابمون خوب نباشه ](*,)
منظورم این بوده که، از اونجایی که میشه اینها رو بدون مشکلات زیاد، به هم تبدیل کرد، نباید فرق خاصی داشته باشند.
یک بروزرسانی مگه چیز خاصی داره؟
فقط یه بروزرسانی خالی نیست. پیکربندی برنامه‌ها باید بررسی بشه، معمولا با ارتقا برنامه‌ها، پیکربندی اونها هم عوض میشه و ممکنه پیکربندی قبلی یا کار نکنه یا عملکرد متفاوتی داشته باشه.
ممکنه توی روند بروزرسانی، مشکل پیش بیاد که الزام میکنه مشکل رو حل کرد.
معمولا لازمه سرورها همیشه روشن و در حال کار باشند. این بروزرسانی‌ها نیاز دارند تا سرور راه‌اندازی مجدد بشه، تا زمانی هم که بررسی‌ها انجام نشده یا مشکلی توی بروزرسانی پیش اومده، نمیشه به طور مطمئن از سرور استفاده کرد.
قرار گرفتن این دلایل کنار هم باعث میشه توی سرورها، از rhel و توزیع‌های مبتنی بر اون، بیشتر از دبیان توی سرور استفاده بشن. هرچند ترجیح من اینه که ا دبیان استفاده بشه.
نمیشه مثلا ۲۰ تا سرور به نوبت آپدیت بشه مشکل پیش نیاد؟
چرا میشه. ولی ممکنه برای بعضی از اونها مشکلی پیش بیاد که در این صورت، لازمه توسط مدیرسیستم بررسی بشه.
(البته خودم هیچ اطلاعاتی در این مورد ندارم نمی دونم میشه اصلأ چند تا سرور می تونن یک سایتی رو میزبانی کنن یا نه)
ممکن هست. در مورد load balancer جست‌و‌جو کنید. اینجا هم چیز‌های خوبی در مورد تقسیم بار بین سرورها داره.
https://linuxlearn.org/blog
-
چرا میشه. ولی ممکنه برای بعضی از اونها مشکلی پیش بیاد که در این صورت، لازمه توسط مدیرسیستم بررسی بشه.
مدیر سیستم چیه؟ منظورتون مدیر بستست؟ یا صاحب سرور؟
-
چرا میشه. ولی ممکنه برای بعضی از اونها مشکلی پیش بیاد که در این صورت، لازمه توسط مدیرسیستم بررسی بشه.
مدیر سیستم چیه؟ منظورتون مدیر بستست؟ یا صاحب سرور؟
در واقع "کیه".
مدیر سرور، سیس‌ادمین..
-
قرار گرفتن این دلایل کنار هم باعث میشه توی سرورها، از rhel و توزیع‌های مبتنی بر اون، بیشتر از دبیان توی سرور استفاده بشن. هرچند ترجیح من اینه که ا دبیان استفاده بشه.
تا اونجایی که من دیدم، تقریبا همه از اوبونتو و دبیان برای سرور استفاده می‌کردن. به جز شرکت‌های خیلی بزرگ که اونها پول میدن و لایسنس SUSE یا RHEL رو میخرن.
سرور CentOS توی ایران خیلی رایج هستن.
-
اگر تجربه ای در سازمان تون برای تصمیم گیری در جایگزینی CentOS دارین، ممنون میشم اشتراک بذارید. و معیارهاتون چیه؟[/b]
من این تجربه رو در چندین سازمان مختلف داشتم. همه رو به دبیان مهاجرت دادم و الآن همه خیلی خیلی راضی‌تر از قبلن.
-
یک بروزرسانی مگه چیز خاصی داره؟
برای کدهای لگسی خیلی باید دست به عصا بود، چون با یه آپدیت سرور ممکنه سرویس دهی بخوابه. برنامه ها اینجوری نیستن که همگام با آخرین libهای مخزن های توزیع ها جلو بیان. تازه بخش هایی از کد به دلایل بیزنسی یا منابع انسانی (جداشدن برنامه نویسهای قبلی از شرکت) ممکنه دیگه توسعه پیدا نکرده باشه. حتی ممکنه چرخ یه بیزنس با کدی برای ۱۰ سال پیش در حال چرخش باشه، مثلا برنامه صنعتی خاصی که سال ها پیش از مثلا زیمنس خریداری شده و بخاطر تحریمها سالهاست که همون ورژن قدیمی داره کار می کنه. تازه قبل از محیط پروداکشن مجبوری در محیط تست هم کارایی برنامه روی آپدیت جدید رو مانیتور کنی. اگرم ادبیات دوواپس باشه که محیط stage رو هم داری؛ یعنی قبل از یک بروزرسانی باید مطمئن باشی که همه چی قراره درست کار کنه.
من این تجربه رو در چندین سازمان مختلف داشتم. همه رو به دبیان مهاجرت دادم و الآن همه خیلی خیلی راضی‌تر از قبلن.
ارتباط ما با تیم توسعه یه مخزن RPM هست! نمی دونم چرا قبلا تصمیم به rpm گرفتن، ولی این روالیه که سمت توسعه بهش عادت کرده. تغییرات نیروها از گذشته هم سمت ما در عملیات و هم در توسعه این سالها زیاد بوده و برای همین CTO برای عوض کردن نوع بسته بندی و بعدش ماهیت توزیع موافقت نکرد. البته ما هم نتونستیم از پیشنهادمون دفاع قانع کننده ای بکنیم (کوچ به اوبونتو رو پیشنهاد داده بودیم)