پاسخ کوتاه: Hetzner Cloud چیست؟

Hetzner Cloud پلتفرم Cloud Server شرکت Hetzner است که امکان ساخت VM در چند Location، انتخاب Resource Model و استفاده از Resourceهای مکمل مانند Network، Firewall، Volume، Backup، Snapshot و IP را فراهم می‌کند.

Cloud بودن یعنی Provision و Lifecycle انعطاف‌پذیرتر؛ اما Availability، Backup و امنیت Application همچنان باید توسط معماری شما طراحی شوند.

Cloud Server با VPS سنتی چه تفاوتی دارد؟

مرز این دو اصطلاح همیشه ثابت نیست. در عمل، Hetzner Cloud نیز ماشین مجازی ارائه می‌دهد، اما API، Resourceهای قابل اتصال و Lifecycle سریع باعث می‌شود برای Automation و Infrastructure-as-Code مناسب باشد. VPS سنتی ممکن است همان Virtual Machine باشد اما با Control Plane و مدل محصول متفاوت.

Hetzner چه لوکیشن‌هایی دارد؟

طبق مستندات رسمی، Cloud Locationهای فعلی شامل Falkenstein و Nuremberg در آلمان، Helsinki در فنلاند، Ashburn و Hillsboro در آمریکا و Singapore هستند. این فهرست دقیقاً با نقشه لوکیشن‌های صفحه VPS خارجی FluxCDN هم‌راستاست.

برای Germany-specific workload، VPS آلمان FluxCDN روی نورنبرگ و فالکن‌اشتاین تمرکز دارد.

Shared و Dedicated Resources یعنی چه؟

Hetzner در مستندات Cloud Server میان Shared Resources و Dedicated Resources تفکیک می‌کند. Shared برای Workloadهای عمومی و توسعه می‌تواند اقتصادی باشد؛ Dedicated CPU برای بار CPU-intensive یا نیاز به Performance ثابت‌تر مطرح می‌شود.

اسم Plan به‌تنهایی کافی نیست؛ Profile CPU، RAM و Disk باید با Workload اندازه‌گیری‌شده تطبیق داده شود.

Primary IP و Floating IP

در مدل شبکه، Primary IP برای Public Connectivity Server استفاده می‌شود و می‌تواند IPv4 یا IPv6 باشد. Floating IP برای جابه‌جایی endpoint میان Serverهای سازگار استفاده می‌شود. جزئیات این دو در مقاله IPv4، IPv6 و Floating IP توضیح داده شده است.

Private Network چه کاربردی دارد؟

با Private Network می‌توانید Database، Cache یا Backend را بدون Exposure مستقیم عمومی به هم متصل کنید. این قابلیت جای Firewall را نمی‌گیرد، ولی معماری را تمیزتر می‌کند: فقط Edge عمومی باشد و سرویس داخلی روی شبکه خصوصی بماند.

Volume، Snapshot و Backup را قاطی نکنید

Volume برای Storage متصل‌شونده است. Snapshot تصویر لحظه‌ای برای Clone یا Rollback است. Backup مکانیزم دوره‌ای Provider است. برای Data حیاتی، هیچ‌کدام به‌تنهایی جای Backup Offsite و Restore Test Application-level را نمی‌گیرند.

Firewall و Automation

Cloud Firewall به شما اجازه می‌دهد Rule شبکه را خارج از Guest OS تعریف کنید. در معماری حرفه‌ای، Cloud Firewall و Firewall داخل OS لایه‌های مکمل‌اند. API نیز امکان Provision و تغییر Resourceها را برای CI/CD یا Terraform-like workflow فراهم می‌کند.

چه محدودیت‌هایی باید قبل از طراحی بدانیم؟

هر Cloud Platform Limit دارد: تعداد Server، IP، Volume، Firewall و Resource Assignment. برخی Limitها قابل افزایش‌اند، اما نباید معماری Production را بر فرض Limit نامحدود بسازید. همچنین Capacity یک Plan در یک Location می‌تواند موقتاً در دسترس نباشد.

لوکیشن و Resource Availability

همه Server Typeها الزاماً در همه Locationها یکسان نیستند. مستندات Hetzner Availability نوع Instance را به تفکیک Location نشان می‌دهد. اگر Architecture خاص AMD، Intel یا Arm نیاز دارید، قبل از استانداردکردن Image، محل‌های قابل سفارش را بررسی کنید.

Hetzner برای چه Workloadهایی مناسب است؟

  • Web/API و Backend عمومی
  • Environment توسعه و Staging
  • Build Runner و CI/CD
  • Reverse Proxy و Edge Service
  • Database با طراحی Backup مناسب
  • Automationهایی که Provision سریع نیاز دارند

برای Workload بسیار خاص، نیاز GPU یا Compliance ویژه باید محصول جداگانه بررسی شود.

چرا ارزان‌بودن به‌تنهایی معیار نیست؟

Total Cost شامل CPU/RAM، Traffic، IP، Backup، Storage، عملیات، مانیتورینگ و زمان تیم است. Server ارزان با منابع ناکافی یا Migration پرهزینه می‌تواند در عمل گران‌تر شود. مقاله انتخاب منابع VPS از سمت Capacity به این تصمیم نگاه می‌کند.

ارتباط با VPS آلمان FluxCDN

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

نورنبرگ یا فالکن‌اشتاین

برای دو Location آلمان، تفاوت را با Route و Inventory بسنجید. راهنمای نورنبرگ یا فالکن‌اشتاین روش Pilot و مقایسه P95 Latency را توضیح می‌دهد.

چک‌لیست قبل از انتخاب Hetzner

  • Location با کاربران و Dependencyها هم‌راستاست؟
  • Server Type موردنیاز در آن Location موجود است؟
  • IPv4/IPv6/Floating IP Requirement مشخص است؟
  • Traffic و Egress الگوی پروژه محاسبه شده؟
  • Backup، Snapshot و Offsite Policy جدا تعریف شده‌اند؟
  • Limitهای Account و Resource بررسی شده‌اند؟
  • Failover و Recovery فقط به یک Zone وابسته نیست؟

API و Infrastructure as Code

یکی از تفاوت‌های مهم Cloud Platform، امکان مدیریت Resourceها از طریق API است. به‌جای ساخت دستی Server، می‌توانید Provision، Firewall، Network و Tagging را در Pipeline قرار دهید. این رویکرد برای Environmentهای تکرارشونده و Recovery بسیار ارزشمند است.

بااین‌حال Automation بد فقط خطا را سریع‌تر تکرار می‌کند. Template، Secret و State را Version-control و Review کنید و قبل از Production روی Environment آزمایشی اجرا کنید.

Server Replacement را بخشی از معماری بدانید

در Cloud بهتر است Server را تا حد ممکن Disposable ببینید: Configuration در Code، Data در Storage و Backup مناسب، و Deploy قابل تکرار باشد. اگر تنها نسخه تنظیمات داخل خود VM است، مزیت Cloud Control Plane را از دست داده‌اید.

هدف این نیست که هر روز Server حذف شود؛ هدف این است که در صورت نیاز، بازسازی آن یک عملیات شناخته‌شده باشد.

Capacity و Quota دو محدودیت متفاوت‌اند

Quota مشخص می‌کند Account چه تعداد Resource می‌تواند بسازد؛ Capacity مشخص می‌کند در آن لحظه چه نوع Instance در Location موجود است. افزایش Limit Account تضمین نمی‌کند هر Plan همیشه قابل سفارش باشد.

برای سیستم حیاتی، Alternative Server Type یا Location داشته باشید و Provision Plan را فقط به یک SKU خاص وابسته نکنید.

Monitoring را خارج از خود VM هم داشته باشید

اگر تنها Monitoring داخل Server اجرا شود، با Down شدن Server همان ابزار مشاهده نیز از دست می‌رود. یک Health Check خارجی برای Endpoint حیاتی داشته باشید و Metric داخلی را به مقصد جدا ارسال کنید.

این الگو کمک می‌کند تفاوت میان «VM خاموش»، «Network مشکل‌دار» و «Application ناسالم» سریع‌تر مشخص شود.

برای Production چه چیزهایی را قبل از Launch بررسی کنیم؟

  • Server Type و Location جایگزین مشخص است؟
  • Backup و Restore واقعاً تست شده‌اند؟
  • Firewall حداقلی است؟
  • Primary/Floating IP Lifecycle مستند شده؟
  • Monitoring خارجی وجود دارد؟
  • Data از VM disposable جدا شده یا Recovery آن روشن است؟
  • Quota و Capacity Risk برای Scale در نظر گرفته شده؟

Image، Snapshot و Template در Automation

برای Deploy سریع می‌توانید از Image پایه و Bootstrap استفاده کنید، اما Image قدیمی ممکن است Packageهای آسیب‌پذیر داشته باشد. بعد از Provision همیشه Update و Configuration Management اجرا کنید. Snapshot نیز اگر ماه‌ها نگه داشته شود، هنگام Restore نیاز به Patch فوری دارد.

بهترین الگو این است که Image فقط نقطه شروع باشد و State نهایی از Code قابل بازسازی بماند.

شبکه خصوصی چه زمانی ارزش دارد؟

اگر چند Server دارید، Private Network برای Traffic داخلی میان App، Database و Worker مفید است. این کار Exposure عمومی را کم و تفکیک معماری را واضح می‌کند. بااین‌حال Encryption، Authentication و Firewall داخلی همچنان لازم‌اند؛ «Private» به‌معنای «Trusted بدون محدودیت» نیست.

Hetzner Cloud برای چه کسی انتخاب مناسبی نیست؟

اگر پروژه به سرویس Managed بسیار تخصصی، GPU خاص، Region قانونی مشخص یا Enterprise Feature ویژه نیاز دارد، باید Product Fit را جدا بررسی کنید. Cloud Server عمومی قرار نیست تمام نیازها را پوشش دهد.

همچنین تیمی که هیچ Process برای Patch، Backup و Monitoring ندارد، با Provision سریع مشکل عملیات را حل نمی‌کند؛ فقط Server را سریع‌تر تحویل می‌گیرد.

جمع‌بندی

Hetzner Cloud یک Control Plane برای ساخت و مدیریت Cloud Server و Resourceهای پیرامونی است. ارزش آن برای پروژه زمانی مشخص می‌شود که Location، Server Type، Network و Recovery Design را آگاهانه انتخاب کنید.

اگر هدف شما آلمان است، پلن‌های VPS آلمان FluxCDN را بررسی کنید؛ برای مقایسه گسترده‌تر نیز لوکیشن‌های VPS خارج در دسترس‌اند.

منابع تکمیلی