هرم وارونه سقوط

مدل ۳-۲-۱ معماری سیستم امروزه بسیار رایج است و تقریباً همیشه دقیقاً عکس آن چیزی است که یک کسب‌وکار نیاز دارد یا حتی می‌خواهد اگر وقت می‌گذاشت تا اهداف کسب‌وکار خود را بنویسد به جای اینکه از منظر فناوری اول به یک معماری نزدیک شود. طراحی یک راه‌حل نیازمند شروع با الزامات کسب‌وکار است، در غیر این صورت نه تنها ریسک طراحی نامناسب معماری برای کسب‌وکار را داریم بلکه آن را انتظار داریم.

این نام به سه (این یک نقطه انعطاف‌پذیر است، اغلب دو یا بیشتر) سرور میزبان مجازی‌سازی افزونه‌دار متصل به دو (یا احتمالاً بیشتر) سوئیچ افزونه‌دار متصل به یک دستگاه ذخیره‌سازی واحد، معمولاً یک SAN (اما DAS یا NAS هم اینجا معتبرند) اشاره دارد. این یک هرم وارونه است چون بخشی که اهمیت دارد، میزبان‌های مجازی‌سازی، کاملاً به شبکه وابسته است که به‌نوبه خود کاملاً به دستگاه SAN یا ذخیره‌سازی جایگزین واحد وابسته است. پس همه چیز بر یک دستگاه نقطه واحد خرابی متکی است و همه حفاظت‌ها و افزونگی‌ها بیشتر و بیشتر روی آن پایه شکننده ساخته می‌شوند. برخلاف یک هرم مناسب با پایه‌ای پهن و پایدار و یک نقطه در بالا، این با تمام ضعف در پایین ساخته شده است. (اغلب مدل بازاریابی «ادرار تک‌شاخ» که «SANها جادو هستند و نمی‌توانند به خاطر کنترلرهای دوگانه شکست بخورند» اینجا بیرون می‌آید چون مردم سعی می‌کنند توضیح دهند که چرا این یک نقطه واحد خرابی نیست، اما در هر معنایی یک نقطه واحد خرابی است.)

پس راه‌حل که اغلب طراحی ۳-۲-۱ نامیده می‌شود، می‌تواند «هرم وارونه سقوط» هم نامیده شود چون یک هرم واژگون است که اجرای آن بسیار شکننده و برای آنچه ارائه می‌دهد بسیار گران است. پس برخلاف بسیاری از مدل‌های شکننده دیگر، بسیار پرهزینه است، انعطاف‌پذیری زیادی ندارد و قابل‌اطمینان‌تر از فقط داشتن یک سرور باکیفیت واحد نیست.

زمان‌هایی هست که ۳-۲-۱ منطقی است، اما اغلب اینها موارد استثنایی شدید هستند که یک محیط شکننده مطلوب است و سطوح بالای ذخیره‌سازی مشترک با قابلیت‌های پردازشی عظیم لازم است – چیزهایی که در دنیای SMB نمی‌بینید و در جاهای دیگر هم بسیار نادر است.

هرم وارونه برای افرادی که از کل معماری آگاه نیستند، مانند مدیران و کارآفرینان، بسیار خوب به نظر می‌رسد. جعبه‌های زیادی هست، سیم‌های زیادی هست، اجزای نرم‌افزاری معمولاً با برچسب «HA» وجود دارند که برای ناظر خارجی، این کار می‌کند که به نظر برسد کل راه‌حل باید بسیار قابل‌اطمینان باشد. هرم‌های وارونه محبوب هستند چون «HA» را از منظر بازاریابی ارائه می‌دهند که همه چیز را فوق‌العاده به نظر می‌رساند و هزینه کلی را در محدوده معقول نگه می‌دارند که تقریباً مثل یک معجزه به نظر می‌رسد – وعده‌های دسترس‌پذیری بالا بدون هزینه‌های سنتی. «افزونگی» اضافی برخی اجزا برای بازاریابی عالی است. از آنجا که قابلیت اطمینان سخت‌سنجش است، هم کارآفرینان و هم متخصصان فنی اغلب به جای قابلیت اطمینان از افزونگی صحبت می‌کنند چون افزونگی را می‌توان دید. هرم وارونه با این افراد خوب صحبت می‌کند چون افزونگی بدون قابلیت اطمینان ارائه می‌دهد. افزونگی در جایی نیست که بیشتر اهمیت دارد. کاملاً حیاتی است که به خاطر بسپاریم افزونگی نه یک چک‌باکس است و نه یک هدف، بلکه ابزاری است برای بهبود قابلیت اطمینان. افزونگی نامناسب ارزشی ندارد. فرمان افزونه در صندوق عقب چه فایده‌ای دارد؟ هواپیمای افزونه چه فایده‌ای دارد وقتی با اولی سقوط می‌کنید؟ سرور افزونه چه فایده‌ای دارد وقتی کسب‌وکار شما از کار افتاده و داده‌ها از دست رفته‌اند چون SAN واحد دود کرد؟

هرم وارونه یکی از واضح‌ترین و فراگیرترین نمونه‌های «لباس جدید امپراتور» در فروش فناوری است. چون نیازهای فروشندگان و تولیدکنندگان را با ترویج فروش‌های با حاشیه سود بالا و به حداقل رساندن فروش‌های با حاشیه سود پایین برآورده می‌کند و چون تقریباً هر فروشنده‌ای آن را به خاطر مزایای مالی‌اش برای فروشنده ترویج می‌کند، به‌طور گسترده به‌عنوان یک راه‌حل عالی پذیرفته شده چون به اندازه کافی پیچیده و فنی است که رد گسترده رخ نمی‌دهد و فشار بازار باورنکردنی از آرایه گسترده فروشندگانی که از این معماری سود می‌برند آن را به وضع موجود تبدیل کرده و افراد کمی می‌ایستند و می‌پرسند آیا کل معماری هیچ شایستگی‌ای دارد. این، ترکیب با این واقعیت که همه سیستم‌های امروزی در مقایسه با سیستم‌های فقط یک دهه پیش بسیار قابل‌اطمینان هستند که باعث می‌شود خرابی‌ها به‌اندازه کافی نادر باشند که این واقعیت که آنها بیشتر از آنچه باید باشند اتفاق می‌افتند و نرخ‌های آماری خرابی بین SMBها به اشتراک گذاشته نمی‌شوند، به این معنی است که معماری رشد می‌کند و به راه‌حل پیش‌فرض برای اکثر SMBها تبدیل شده است.

نتیجه این است که رویکرد هرم وارونه هیچ منطقی ندارد – بسیار غیرقابل‌اطمینان‌تر از راه‌حل‌های ساده‌تر است، حتی فقط یک سرور واحد مستقل، در حالی که چندین برابر بیشتر هزینه می‌کند. اگر هزینه یک عامل کلیدی است، باید کاملاً رد شود. اگر قابلیت اطمینان یک عامل کلیدی است، باید کاملاً رد شود. تنها اگر هزینه و قابلیت اطمینان جای بسیار دور از ذهنی دارند و انعطاف‌پذیری باید در نظر گرفته شود و حتی در آن صورت هم نادر است که یک راه‌حل کم‌هزینه‌تر و قابل‌اطمینان‌تر از نظر انعطاف‌پذیری کلی در محدوده پیش‌بینی‌شده انعطاف‌پذیری با آن برابری نکند. بهتر است کاملاً از آن اجتناب شود.

در اصل در Spiceworks به‌صورت خلاصه منتشر شد: http://community.spiceworks.com/topic/312493-the-inverted-pyramid-of-doom