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

خودروهای تاکتیکی یکی از ابزارها و ادوات بسیار مهم در عرصه های نبرد و میدان های پیکار با دشمنان هستند. این خودروها به جهت لزوم بهره گیری در زمینه های ذکرشده باید از ویژگی های شاخصی برخوردار باشند. البته متخصصان ایرانی هم با توجه به این شاخص ها ویژگی های ذکرشده را در طراحی و ساخت این خودروها مدنظر قرارداده بودند.

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

در نخستین گزارش از این مجموعه به بررسی خودروی تاکتیکی سفیر پرداختیم که در صنایع خودرویی فتح ساخته شده و  سال ۸۷ از آن رونمایی شد. این خودرو از نظر ویژگی‌های فنی شباهت زیادی به خودرو‌های جیپ داشته و از نظر عملکردی همانند آن‌ها عمل می‌کند. این خودرو به در قالب خودرو‌های ۴x۴ طراحی و ساخته شده است. وزن این خودرو در حدود ۱.۵ تن برآورد شده است.

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

دومین گزارش از این مجموعه خودروی تاکتیکی ارس را بررسی کرد که نوعی خودروی تاکتیکی فرماندهی ساخت وزارت دفاع کشورمان است. این خودرو روز ۳۱ مرداد ۹۱، همزمان با روز ملی صنعت دفاعی کشور با حضور وزیر دفاع و رئیس جمهور وقت، محمود احمدی نژاد، رونمایی شد. 

اما در سومین بخش از این گزارشات نیز به بررسی انواع دیگر همین خودروها پرداخته است.

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

خودروی نینوا

رونمایی از «نینوا»

نینوا در رسانه‌های خارجی

پایگاه های خبری تحلیلی REVOLVY و ARMY GUIDE در گزارشی ضمن معرفی کامیون نینوا به تحلیل و بررسی این خودرو پرداخته و از آن به عنوان یک خودروی تاکتیکی یاد کرده است.

کلام آخر

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

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

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

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

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

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

حسگرهای بوش (Bosch) در سرتاسر پارکینگ همراه‌با گیرنده‌های ساخت دایملر که در درون خودرو قرار دارد، امنیتوسیله‌ی نقلیه در راهروهای پارکینگ را برقرار می‌کنند. اگر مانعی تشخیص داده شود، خودرو به‌صورت خودکار می‌ایستد.

این سیستم از فناوری خودران سطح ۴ استفاده می‌کند که توسط انجمن خودروسازان تحت عنوان «رانندگی بدون راننده در منطقه‌ی جغرافیایی مجزا» تعریف شده است.

گروه خودروسازی دایملر می‌گوید سیستم مذکور یک ایده‌ی امنیتی، مناسب جهت آزمایش و گرفتن تأییدیه است که می‌توان آن را فراتر از پروژه‌ی آزمایشی به کار برد.

دکتر مارکوس هین، عضو هیئت مدیره‌ی بوش عنوان کرد:

رانندگی و پارک خودکار، زیرساخت‌های مهمی برای آینده هستند. سیستم پارک خودکار نشان می‌دهد که ما در امتداد این مسیر توسعه، پیشرفت کرده‌ایم.

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

مأموریت آپولو ۱۱، یک شاهکار فوق‌العاده دقیق تاریخ بشری بود. موشک ساترن ۵ که با حداکثر سرعت حدود ۱۶ کیلومتر در ثانیه پرواز می‌کرد، در صورت وقوع حتی کوچک‌ترین خطای ناوبری ناگهانی، می‌توانست از مسیر خارج شود و فاجعه‌ای ناگوار را رقم بزند. در همین حال، پس از جدا شدن فضاپیما از موشک، اعضای مرکز کنترل مأموریت در هیوستون از فاصله‌ی حدود ۳۸۶ هزار کیلومتری، موقعیت فضاپیما را برای هر ۱۰ متری ردیابی می‌کردند. کامپیوتر گردونه فرماندهی و خدمات آپولو می‌توانست زمان را به‌صورت میلی‌ثانیه محاسبه کند و با همه‌ی این دقت خارق‌العاده، هنوز کسی به درستی نمی‌داند که نیل آرمسترانگ دقیقا در چه لحظه‌ای اولین قدم خود را روی ماه گذاشت.

آرمسترانگ «گام کوچک» خود را روز ۲۰ ژوئیه ۱۹۶۹ (۲۹ تیر ماه سال ۱۳۴۸) یعنی ۵۰ سال قبل روی ماه گذاشت. این مرحله پس از ساعت ۱:۵۶ دقیقه‌ی آن شب به وقت ایالات شرقی آمریکا اتفاق افتاد. آرمسترانگ در آن لحظه اعلام کرد: «بسیار خب، می‌خواهم از گردونه‌ی ماه‌نشین پایین بیایم.» و سپس جمله‌ی مشهور خود را گفت:‌ «این گامی کوچک برای انسان و جهشی بزرگ برای بشریت است.» یا به تعبیر بهتر: «گامی کوچک برای یک انسان و جهشی بزرگ برای بشریت است.»

نیل آرمسترانگ با لباس فضانوردی در حال تمرین برای فرودن آمدن از نردبان گردونه ماه‌نشین و گذاشتن اولین قدم‌ها روی ماه

در لحظه‌ای بین این دو جمله که حدود ۸ ثانیه طول کشید، او به اولین انسانی بدل شد که روی ماه قدم برمی‌دارد. اما قدم گذاشتن روی ماه دقیقا در چه لحظه‌ای انجام شد؟ جالب است که هنوز بعد از گذشت نیم قرن، اختلاف‌نظرهای زیادی در این مورد وجود دارد و شاید لحظه‌ی دقیق فرود انسان روی ماه هیچ‌وقت مشخص نشود!

شب فرود، ناسا به رسانه‌ها اعلام کرد که آرمسترانگ در ساعت ۱۰:۵۶:۲۰ بعد از ظهر روی ماه قدم گذاشته است و نیویورک تایمز نیز صبح روز بعد همین زمان را در صفحه نخست چاپ کرد. گزارش زمان واقعی که از فضا به زمین مخابره شده بود، نشان می‌دهد که آرمسترانگ زمانی بین ۱۰:۵۶:۴۳ تا ۱۰:۵۶:۴۶ گام‌هایش روی ماه را گذاشته است. زمانی‌که متن گزارش مأموریت آپولو ۱۱ ناسا در نوامبر همان سال (آذر ۱۳۴۸) در رسانه‌ها منتشر شد، چنین شرح داده شد که اولین تماس نیل آرمسترانگ با خاک ماه، ۵ ثانیه زودتر یعنی در ساعت ۱۰:۵۶:۱۵ انجام گرفته است.

به این ترتیب، کارشناسان به این نتیجه رسیدند زمانی‌که ناسا در اختیار خبرنگاران گذاشته، از کمترین درجه‌ی اعتبار (به لحاظ دقت) برخوردار بوده است. و در همین حال، ناسا توجه زیادی به گزارش مأموریت نشان نداده که مشخصا از مملو از خطای انسانی بوده است. برخی حتی گزارش مأموریت را زیر سؤال برده‌اند که لازمه‌ی آن ماه‌ها تجزیه و تحلیل اطلاعات، گزارش‌ها و مصاحبه‌های خدمه‌ی مأموریت بوده است. هیکو کافن، مهندس نرم‌افزار آلمانی و از شیفتگان فضا، یکی از این دست افراد است.

از سمت چپ به راست: فرمانده مأموریت آپولو ۱۱، نیل آ. آرمسترانگ، خلبان گردونه فرماندهی مایکل کالینز و خلبان گردونه ماه‌نشین ادوین باز آلدرین

کافن ابتدا در سال ۲۰۰۹ متوجه این اختلاف زمانی شد. او در آن زمان تلاش می‌کرد که یک ردیاب زمان را برای چهلمین سالگرد فرود انسان روی ماه مورد استفاده قرار دهد. هنگامی که کافن تلاش کرد تا متن گزارش مخابره شده به زمین را با یک نسخه‌ی تصویری صوتی این رویداد مطابقت دهد، متوجه شد که گزارش مأموریت اندکی عقب است و همین نشان می‌داد که یکی از مهم‌ترین سوابق ثبت شده‌ از  اولین گام آرمسترانگ روی کره ماه اشتباه بوده است. کافن فرود روی ماه را محتملا «بزرگ‌ترین دستاورد بشریت» می‌دانست و به همین دلیل از اینکه ناسا این نقطه عطف تاریخی را با دقت بیشتری ثبت نکرده، کاملا دلسرد شده بود. او در سال ۲۰۱۱، شروع به تجزیه و تحلیل متن گزارش و ویدئوهای مأموریت کرد تا زمان قطعی قدم گذاشتن اولین انسان روی ماه را محاسبه کند.

اما موانع زیادی سر راه کافن بودند. ماه فاصله زیادی با زمین دارد و حتی نور هم نیاز به ۳۰۰ هزار کیلومتر بر ساعت دارد تا از نقطه‌ای به نقطه‌ی دیگر برود. به همین ترتیب، اطلاعات صوتی و تصویری رسیده به تلویزیون‌های آنالوگی که حدود ۵۰۰ میلیون را پای خود نگه داشته بودند تا فرود آرمسترانگ از نردبان گردونه‌ی ماه‌نشین را تماشا کنند نیز از همین قاعده تبعیت می‌کردند. علاوه بر این، زمان لازم برای پردازش این اطلاعات و تأخیر بین لحظه‌ای که آرمسترانگ روی ماه قدم گذاشت و لحظه‌ای که بینندگان تلویزیونی این صحنه تاریخی را مشاهده کردند را نیز حساب کنید.

حتی اگر تأخیر را به حساب بیاوریم، هماهنگ‌سازی صدا با ویدئو هنوز مشکل دارد، چرا که به سختی هیچ‌کدام از صداهای ضبط شده در ویدئو قابل مشاهده هستند. آیا در این لحظه به‌خصوص قبل از فرود از نردبان، آرمسترانگ کار دیگری (مثلا کوبیدن به یک درام) را انجام داده است! در همین حال، راهی نیست که مانند فیلم‌های سینمایی لب‌های گوینده را با صدا هماهنگ‌ کرد.

کافن می‌گوید:

در نهایت، ما هرگز متوجه نخواهیم شد که ویدئو و صدا واقعا همگام بوده‌اند.

عکسی از یکی از اولین قدم‌های فضانوردان روی ماه که به دلیل نبود باد در ماه برای مدت طولانی دست‌نخورده باقی مانده بود

مورد دیگر که مشخصا جزء جدانشدنی از هر کاری محسوب می‌شود، همان خطای انسانی است.

بیل بَری، مورخ ناسا در مورد این اختلاف زمانی می‌گوید:

باید به یاد داشته باشیم که قضیه مانند مسابقات شنای المپیک نیست که دست زدن به دیوار باعث متوقف شدن زمان‌سنج شود. زمان دقیق اولین تماس نیل (آرمسترانگ) با سطح ماه، الزاما موضوع تفاسیر بسیاری بوده است، چرا که زمان دقیق از راه دور و با ابزارهایی اندازه‌گیری شده که قرار نبوده زمان را به‌صورت دقیق و ثانیه‌ای محاسبه کنند.

کافن برای هماهنگ کردن گزارش‌ها و صداها و تصاویر ضبط‌ شده، از آنچه به‌عنوان «فرض‌های منطقی» نام می‌برد، استفاده کرد. اما، اکنون بعد از ۱۰ سال از شروع بررسی‌هایش، هنوز هم نتوانسته او را به نتیجه‌ی دلخواه برساند. او متوجه شد که آرمسترانگ، اولین‌بار در ساعت ۱۰:۵۶:۲۵ روی ماه قدم گذاشت که کاملا با زمانی‌که ناسا آن شب به خبرنگاران گفته بود، تفاوت دارد.

اریک جونز، یکی از پژوهشگران آزمایشگاه ملی لوس آلاموس پس از تحقیقاتی که براساس تجزیه و تحلیل‌های کافن انجام داد، اولین تماس با سطح ماه را ۱۰:۵۶:۱۷ دانست. ناسا گزارش نوامبر ۱۹۶۹ را مدنظر قرار داده و بری نیز می‌گوید که زمان رسمی ۱۰:۵۶:۱۵ است. نیم قرن بررسی دقیق ممکن است راه‌حل معقولی در بر نداشته باشد. اما بری یکی از کسانی است که در این خصوص نگرانی ندارد. او گفت:

هنگامی که شیفتگان فضا و مهندسان ۵۰ سال اطلاعات را برای بررسی و بررسی مجدد در اختیار دارند، چنین چیزی اتفاق می‌افتد.

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

با وجود این لحظه‌ی سرشار از غرور و تاریخی برای ما انسان‌ها و با وجود اینکه شاید از محدودیت‌های اکتشافات انسانی پیشی گرفته باشیم، بازهم باید متوجه باشیم که ما انسان‌ها هیچ‌وقت نمی‌توانیم مصون از خطا باشیم. وقتی از کافن سؤال می‌شود که چرا این همه ساعت را صرف تجزیه و تحلیل یک ثانیه کرده است، او با یکی از نقل‌قول‌های سری مأموریت‌های آپولو که از مأموریت آپولو ۱۵ است، پاسخ می‌دهد. او می‌گوید: «وقتی که دیوید اسکات، فرمانده مأموریت آپولو ۱۵ به دشت‌های هادلی (محل فرود مأموریت) نگاه می‌کرد، حقیقتی بنیادین در مورد ماهیت بشر را کشف کرد.» پیگیری مصرانه‌ی کافن همان‌قدر که شاید بی‌اهمیت به نظر می‌رسد، تلاشی برای پاسخ به سوالی بدون جواب و بیانگر همان ماهیت بنیادین است و شاید هم جامع‌تر از آن چیزی باشد که فضانورد سابق آپولو ۱۵ گفته بود:

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

برنامه‌ی لزوم استفاده از کارت سوخت شخصی خودرو در تاریخ ۲۰ مرداد ماه فقط در کلانشهرهای تهران، کرج، تبریز و اصفهان اجرا می‌شود؛ در حالی‌ که مصوبه‌ی قبلی شرکت‌ ملی پالایش و پخش فرآورده‌های نفتی از اجرای سراسری این برنامه در تاریخ ۲۰ مرداد ماه حکایت داشت.

پیش از این شرکت ملی پخش فرآورده‌های نفتی ایران در خرداد ماه طی اطلاعیه‌ای اعلام کرده بود:

عرضه‌ی بنزین در جایگاه‌های سوخت سراسر کشور از تاریخ بیستم مرداد ماه سال جاری صرفاً با ارائه‌ی کارت هوشمند سوخت خودرو، امکان‌پذیر خواهد بود.

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

این طرح در مدت زمان کوتاه در دیگر کلانشهرها و کل کشور نیز اجرا خواهد شد.

پیگیری‌ها از سامانه‌ی ۰۹۶۲۷ شرکت ملی پخش فرآورده‌های نفتی ایران نیز این مسئله را تأیید می‌کند که در تاریخ ۲۰ مرداد ماه، اجرای مصوبه‌ای که قرار بود در این تاریخ سراسری باشد، فقط در چهار کلانشهر مذکور انجام می‌شود و در روزها و شاهد هفته‌های بعد از آن، باید منتظر اجرای مصوبه‌ی مورد بحث در سایر نقاط کشور باشیم. همچنین هموطنانی که رمز کارت سوخت خودرو را فعال نکرده‌اند، می‌توانند با مراجعه به جایگاه عرضه‌ی بنزین در سراسر کشور و واردن کردن چهار رقم سمت راست کد ملی، آن را فعال کنند تا در زمان اجرایی شدن طرح با مشکلی مواجه نشوند.

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

Stack Overflow یکی از مشهورترین وب‌سایت‌ها در میان برنامه‌نویس‌ها محسوب می‌شود؛ جامعه‌‌ای که برای مطرح کردن مشکلات و چالش‌های برنامه‌نویسی و حتی یادگیری، مورد استفاده‌ی بسیاری از توسعه‌دهنده‌ها است. استقبال بالای کاربران از این سرویس و حجم زیاد درخواست‌ها و فشار روی سرورها، نگه‌داری آن را به امری حساس و چالش‌برانگیز تبدیل می‌کند.

تیم فنی استک اورفلو سال گذشته تصمیم گرفت تا زیرساخت نرم‌افزاری سمت سرور خود را از ویندوز سرور ۲۰۱۲ به ویندوز سرور ۲۰۱۹ ارتقا دهد؛ فرایندی که دشواری‌های خاص خود را داشت و حتی تلاش شبانه‌روزی اعضای گروه را طلب می‌کرد. با وجود تمام مشکلات، بالاخره فرایند مهاجرت پایان یافت. تارین پرات، مدیر دیتابیس استک اورفلو، در پستی وبلاگی به شرح فرایند مهاجرت به ویندوز سرور ۲۰۱۹ پرداخته است که در ادامه‌ی این مطلب زومیت، چگونگی روند جابه‌جایی را از زبان او می‌خوانیم. شایان ذکر است در مقاله‌ی پیش‌رو شاهد اصطلاحات و تعاریف تخصصی شبکه و سرور خواهیم بود که شاید برای کاربر عادی جذاب نباشد.

ما سال گذشته زیرساخت دیتابیس خود را به SQL Server 2017 تغییر دادیم، اما تغییری در سیستم‌عامل سرور یا سرورهای محصول اصلی اعمال نکردیم. سیستم‌عامل اصلی، ویندوز سرور ۲۰۱۲ بود. البته ما حتی از نسخه‌ی R2 نیز استفاده نمی‌کردیم. ما می‌دانستیم که تغییر سیستم‌عامل فرایندی بسیار دشوار خواهد بود؛ فرایندی که به تغییر ساختاری کلاسترها نیاز داشت و درنتیجه زمان اکار (غیرفعال بودن سرور) را افزایش می‌داد.

من در زمانی‌که پروژه‌‌های سال ۲۰۱۹ شرکت را برنامه‌ریزی می‌کردم، تغییر سیستم‌عامل از نسخه‌ی ۲۰۱۲ به ۲۰۱۹ را در اولویت بالای فهرستم قرار دادم. این کار باید واقعا انجام می‌شد، ما در سال ۲۰۱۹ هستیم و دیگر زمان گذر از سیستم‌عامل هفت ساله فرا رسیده بود. از همان ابتدا می‌دانستیم که فرایند پیچیده‌ای را در پیش خواهیم داشت. به‌ هر حال اجرای پروژه از هر لحاظ منطقی به‌نظر می‌رسید. ما با شروع مهاجرت به ویندوز سرور ۲۰۱۹، پروژه‌ای پیچیده و جذاب را در ابتدای سال شروع می‌کردیم که بعدا امکان استفاده از SQL Server 2019 را نیز فراهم می‌کرد.

فرایند جابه‌جایی از ویندوز سرور ۲۰۱۲ به ۲۰۱۹ برای خود من هم پروژه‌ای کاملا جدید و ناشناخته بود. قبلا چنین کاری انجام نداده بودم و در ماه ژانویه، بالاخره نقشه‌ی راه جابه‌جایی به سیستم‌عامل جدید را طراحی کردم. در این مقاله تمامی مراحل جابه‌جایی اعم از برنامه‌ریزی، آزمایش، مشکلات پیش‌بینی‌نشده و پیاده‌سازی نهایی را شرح می‌دهد.

توجیه‌پذیری

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

یکی از مزیت‌های اصلی به‌روزرسانی در توان عملیاتی ما در لاگ گروهی سرور بود. خوشه‌های (کلاسترها) کنونی سرورهای ما متشکل از سه نود هستند. دو نود اصلی و ثانویه‌ی محلی در نیویورک سیتی و یک نوت ثانویه‌ی دسترسی از راه دور در کلرادو واقع هستند. ما در کلرادو تأخیرهای قابل‌توجهی تجربه می‌کردیم و دیتابیس به‌خوبی و با سرعت مناسب هماهنگ نمی‌شد.

به‌روزرسانی از ویندوز سرور ۲۰۱۲ به نسخه‌های پس از سال ۲۰۱۶ فوایدی در کارایی سرورها ایجاد می‌کرد و همچنین برخی از مشکلات هماهنگی بین آن‌ها را از بین می‌برد. بهبودهای مذکور برای من ارزش بالایی داشتند، چون دیگر شاهد مشکلاتی همچون تصویر زیر نمی‌شدم:

فاز اول: آزمایش

من محیطی آزمایشگاهی برای بررسی ایده‌ها و برنامه‌ها دارم که مزایای بسیار زیادی در پروژه‌ها دارد. در ابتدای این پروژه، دو کلاستر آزمایشی Windows Server Failover Clusters (یا WSFC) داشتم. هریک از آن‌ها دو نود شبکه داشت که مجهز به ویندوز سرور ۲۰۱۶ و SQL Server 2017 بودند. به‌علاوه هر کلاستر مجهز به Availability Group بود و بین دو کلاستر نیز Distributed Availability Group پیاده‌سازی می‌شد. به‌هرحال من نمی‌‌خواستم که برای آزمایش، کلاسترهای موجود را تغییر دهم و درنتیجه سرورهای جدیدی برای آزمایش ایجاد کردم.

هدف اولیه‌ی آزمایش، ایجاد یک نمونه‌ی کوچک‌تر از تنظیمات اصلی سرورها بود. سپس سناریوهای گوناگون را آزمایش می‌کردم تا به نتیجه‌ی دلخواه برسم. خوشه‌های سروری در نسخه‌ی ۲۰۱۲ پروداکشن سرور (سرورهایی که میزبان وب‌سایت‌های فعال یا وب‌اپلیکیشن‌های همیشه در حال اجرا هستند) طراحی شبیه به تصویر زیر دارند.

سرورهای پروداکشن هرکدام دو WSFC داشتند که مجوز به ویندوز سرور ۲۰۱۲ بود و هرکدام سه نود داشت. هر دو کلاستر یک Availability Group و یک Distributed Availability Group داشتند که به کلاستری دیگر متصل بود. پس از اتمام پروژه، کلاسترهای جدید ظاهر شبیه به هم پیدا می‌کردند، اما سیستم‌عامل و نام آن‌ها تغییر می‌کرد. در پایان SQL Server اصلی هر یک در گروه‌های مربوطه هم به دیتابیس NY Secondary تبدیل می‌شود.

من برای آزمایش کامل برنامه به سه سرور مجهز به ویندوز سرور ۲۰۱۲ نیاز داشتم. نکته‌ی جالب این بود که روشی برای نصب ویندوز سرور ۲۰۱۲ نداشتیم و حتی ایمیجی از نرم‌افزار مذکور در دسترس نبود. به‌هرحال در نهایت نسخه‌ای از نرم‌افزار با پیدا کردم و فرایند آزمایش با سه سرور نهایی شروع شد.

در مرحله‌‌ی نهایی سه کلاستر جدید ۲۰۱۲ داشتم که هرکدام سه نود داشتند (دو نود در نیویورک و یکی در کلرادو). همه‌ی کلاسترها از SQL Server 2017 استفاده می‌کردند و دو گروه AG در آن‌ها طراحی شد. یکی از گروه‌های AG محدود به کلاستر بود و دومی به DAG کلاستر دیگر متصل می‌شد.

آزمایش کاربردپذیری

پیش از آن که کلاستر آزمایشی را بررسی کنیم، ایده‌ی ساخت سروری دیگر با ویندوز سرور ۲۰۱۹ مطرح شد تا امکان کار کردن آن با کلاستر آزمایشگاهی بررسی شود. درواقع ما می‌خواستیم هماهنگی داده میان سرورها را بررسی کنیم. من یک سرور دیگر راه‌اندازی کردم و این بار سیستم‌عاملی کاملا جدید یعنی ویندوز سرور ۲۰۱۹ اجرا می‌شد که در SQL Server 2017 روی آن نصب بود. هدف نهایی، اضافه کردن نسخه‌ی ۲۰۱۹ در کنار ویندوز سرور ۲۰۱۲ بود تا دریافت داده از نسخه‌ی قدیمی بررسی شود. پیکربندی مورد نظر، شبیه به دیاگرام زیر می‌شد:

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

• اضافه کردن سرور ۲۰۱۹ به کلاستر ۲۰۱۲ موجود که طبق پیش‌بینی‌ها موفق نشد. دلیل شکست نیز تفاوت سیستم‌های عامل بود.
• تلاش برای اضافه کردن سرور به AG موجود که باز هم به‌خاطر عدم عضویت در کلاستر موفق نشد.
• ایجاد یک کلاستر نود مجزا برای سرور ۲۰۱۹ و تلاش برای اضافه کردن آن به‌عنوان عضوی دوم در AG که باز هم موفق نبود.

وقتی آزمایش‌های بالا و بسیاری بررسی‌های دیگر ناموفق شدند، درباره‌ی چگونگی انجام نهایی پروژه نگران شدم. آزمایش بعدی ایجاد DAG برای همه‌ی AG‌های موجود بود تا شاید بتوان سرور ۲۰۱۹ را به ترکیب جدید اضافه کرد. درنهایت به نتیجه‌ای رسیدم که برای یک سرور تکی جوابگو بود. پس از آن که یک DAG بین کلاستر ۲۰۱۹ و ۲۰۱۲ ایجاد کردم، داده‌ها بین دو کلاستر با سیستم‌های عامل متفاوت جابه‌جا و هماهنگ شدند.

نتیجه‌ی بالا برای یک سرور به‌خوبی به دست آمد. در مرحله‌ی بعدی باید پیاده‌سازی با سه سرور در یک کلاستر را بررسی می‌کردم که همه‌ی AGها و DAGها در آن فعال باشند.

سرور آزمایشی پروداکشن

وقتی به این نتیجه رسیدیم که می‌توان کلاسترهایی با سیستم‌عامل گوناگون داشت و داده را با استفاده از AG توزیع‌شده هماهنگ کرد، زمان آزمایش کلاستر آزمایشگاهی ۲۰۱۲ فرا رسید. از آنجایی که کلاستر مذکور به‌صورت یک کلاستر مستقل با SQL Server در حال کار بود، باید آزمایشی کاملا نزدیک به شرایط واقعی و مورد نظر سرور پروداکشن نهایی طراحی می‌کردیم. ابتدا باید یک کپی از کلاستر گزارش‌دهی ایجاد می‌کردم. در این مرحله از یک کلاستر ۲۰۱۶ استفاده کردم که در محیط آزمایشگاهی در دسترس بود.

برنامه‌ی آزمایش مرحله‌ی جدید، شامل ایجاد DAG بین کلاستر ۲۰۱۲ موجود و کلاستر آزمایشگاهی ۲۰۱۶ بود. چنین تنظیماتی شبیه به طراحی موجود در سرور پروداکشن می‌شد که دیاگرام زیر نشان‌دهنده‌ی طراحی آن است:

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

۱- جدا کردن سرور از کلاستر موجود ۲۰۱۲

۲- بازسازی با ویندوز سرور ۲۰۱۹

۳- ساخت WSFC جدید با یک نود

۴- نصب SQL Server 2017

۵- پیاده‌سازی AG توزیع‌شده‌ی جدید از کلاستر قدیمی به کلاستر جدید برای همگام‌سازی دیتابیس

پس از پیاده‌سازی مراحل بالا، قصد داشتم تا همین فرایند را برای سرور ثانویه‌ی کلرادو با کلاستر ۲۰۱۲ هم انجام دهم. تفاوت فرایند برای کلاستر CO این بود که آن را به‌صورت یک نود جدید به WSFC اضافه می‌کردم تا به‌صورت یک کپی از AG به کلاستر جدید افزوده شود. در این مرحله از فرایند یک کلاستر قدیمی ۲۰۱۲ داشتیم و یک سرور تکی نیز داده را به دو کلاستر ارسال می‌کرد. به‌ بیان‌ دیگر یک کلاستر گزارش‌دهی ۲۰۱۶ و یک کلاستر ۲۰۱۹ جدید ایجاد شد که طرحی شبیه به دیاگرام زیر داشت:

پیش‌ از به‌روزرسانی سرور ۲۰۱۲ نهایی، باید فرایند Failover (به زبان ساده جابه‌جایی یک سرور به سروری دیگر) را برای AG توزیع‌شده از کلاستر ۲۰۱۲ به کلاستر ۲۰۱۹ جدید انجام می‌دادم. برای پیاده‌سازی فرایند مذکور یک مشکل اساسی داشتم که در کلاستر گزارش‌دهی دیده می‌شد. اگر failover را از AG توزیع‌شده به کلاستر ۲۰۱۹ جدید انجام می‌دادم، فرایند دریافت داده متوقف می‌شد. درنتیجه دو گزینه پیش رو داشتیم:

۱- پیاده‌سازی failover و خارج کردن کلاستر گزارش و سپس انتظار برای بازگشت شرایط همگام‌سازی داده

۲- جابه‌جایی کلاستر گزارشی و AGهای توزیع‌شده‌ی آن پیش از فرایند failover به کلاستر ۲۰۱۹ و امیدواری به همگام‌سازی مجدد داده‌ها

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

پس از انتخاب گزینه‌ی اجرایی، پیاده‌سازی فرایند در محیط آزمایشگاهی دشواری زیادی نداشت. تنها یک سرور در کلاستر قدیمی باقی ماند و باید AGهای توزیع‌شده را به کلاستر ۲۰۱۹ جدید منتقل می‌کردیم (فرایند failover). در مراحل بعدی باید کلاستر ۲۰۱۲ از بین می‌رفت و سرور جدید با ویندوز ۲۰۱۹ ساخته می‌شد. مراحل نهایی شامل اضافه کردن سرور جدید به WSFC 2019، نصب SQL Server و اضافه کردن مجموعه به‌عنوان یک کپی به همه‌ی AGها بود.

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

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

• ۲ سیستم WSFC
• ۶ سرور با سیستم‌عامل جدید و نسخه‌های تازه‌ی SQL Server
• ۵ گروه AG با ۳۸۵ دیتابیس
• ۵ گروه AG توزیع‌شده‌ی موقت که در کنار AGهای بالا قرار می‌گرفتند

با توجه به مراحل بالا به این نتیجه می‌رسیم که به آدرس‌های IP جدید برای کلاسترها هم نیاز داشتیم. به‌علاوه AG Listener و نام‌ جدید باید برای کلاسترها، AGها و DAGها انتخاب می‌شد. در فرایند آزمایش متوجه شدیم که نمی‌توان نام‌های مشابهی برای موارد مذکور انتخاب کرد. حتی با وجود متفاوت بودن سرورها، نام‌های مشابه انتخاب مناسبی نبود؛ چرا که فرایند جابه‌جایی به سرور پروداکشن را بسیار دشوار و زمان‌بر می‌کرد. به‌ هر حال همه‌ی شرایط برای فرایند نهایی آماده به نظر می‌رسید.

فاز دوم: پیاده‌سازی اولیه

تقریبا تمامی ماه ژوئیه به بررسی و آزمایش فرایند برای اجرا در سرور پروداکشن اختصاص یافت. ابتدا ماه فوریه را برای اجرای نهایی انتخاب کردم که گزینه‌ی اشتباهی بود. درواقع در مراحل پایانی آزمایش پیشنهاد به‌روزرسانی به سرور ۲۰۱۹ در چند سرور توسعه‌ای مطرح شد تا هرگونه اشکال احتمالی در جابه‌جایی سرور پروداکشن بررسی شود. سرورهای توسعه‌ای اصلی ما که برای بخش پرسش و پاسخ اصلی استفاده می‌شوند، سخت‌افزار و تنظیمات مشابه دارند، اما هیچ‌گونه AG با آن‌ها در ارتباط نیست. درواقع سرورهای مذکور تنها کپی‌هایی از دیتابیس دارند که برای فرایند توسعه استفاده می‌شود.

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

برای اجرای فرایند آزمایشی روی سرورهای توسعه‌ای، به سرور نیاز داشتم. دو ماشین مجازی و یک سرور فیزیکی انتخاب شدند. ما از سرویس Foreman برای بازسازی خودکار سرورها استفاده می‌کنیم که فرایند پیاده‌سازی و بازسازی سرورها را بسیار دشوار می‌کرد. از آنجایی که ویندوز سرور ۲۰۱۹ هیچ‌گاه پیاده‌سازی نشده بود، در فورمن به آن دسترسی نداشتیم. درنتیجه باید سرورها را به‌صورت دستی به‌روزرسانی می‌کردم. به‌روزرسانی ابتدا روی دو ماشین مجازی انجام شد. به‌جز چند مشکل جزئی، سایر فرایند به‌خوبی انجام شد. سیستم‌عامل به‌خوبی پیاده‌سازی و نصب SQL Server هم در ادامه‌ی آن انجام شد. درنهایت سرورها در عرض چند ساعت به چرخه‌ی عملیات بازگشتند.

مرحله‌ی بعدی پیاده‌سازی ویندوز سرور ۲۰۱۹ در سرور فیزیکی بود که چالش‌های اصلی را به‌همراه داشت. همان‌طور که قبلا گفتم، سرورهای توسعه‌ای ما سخت‌افزار و پیکربندی کاملا مشابهی با سرورهای پروداکشن دارند. درواقع با یک درایو برای سیستم‌عامل، درایوی برای SQL مجهز به NVMe/PCIe و عموما درایو سومی مجهز به دیسک‌های چرخنده داریم. سرور فیزیکی که برای آزمایش سیستم‌عامل جدید انتخاب شد، هر سه درایو مذکور را داشت. من فرایند بازسازی را شروع کردم و دو ساعت پس از آن، با صفحه‌ی آبی مرگ روبه‌رو شدم:

مشکل عملیاتی بسیار سریع کشف شد. درایوهای NVMe با ویندوز سرور ۲۰۱۹ هماهنگ نبودند. به کمک اعضای عالی تیمم فرایند دیباگ را شروع کردیم. پس از بحث‌های متعدد به این نتیجه رسیدیم که درایو را به‌روزرسانی کنیم. یکی از درایوهای NVMe ابتدا در ظاهر از کار افتاد و سپس مجددا آنلاین شد. ما توانستیم سرور را مجددا به حالت پیش از به‌روزرسانی ۲۰۱۶ بازگردانیم.

فرایند بالا اصلا در مسیر اصلی پیاده‌سازی نبود. ما می‌خواستیم به نسخه‌ی ۲۰۱۹ به‌روزرسانی کنیم، اما درایور جدید با NVMe RAID هماهنگ نبود. درنتیجه باید با شرکت‌های سازنده یعنی اینتل و دل تماس می‌گرفتیم. شاید به کمک آن‌ها می‌توانستیم درایور و نرم‌افزار مورد نیاز را برای درایوهای NVMe RAID خود پیدا کنیم. درنهایت توانستیم تجهیزات را آماده کرده و درایورهای مورد نیاز را با نرم‌افزاری نصب کنیم که توانایی شناسایی RAID ما را داشت. در مرحله‌ی بعد باید یک پیاده‌سازی دیگر را برای نسخه‌ی ۲۰۱۹ آزمایش می‌کردیم. پس از گذشت دو ساعت از فرایند بازسازی، به وضعیت ۴۵ درصد پیشروی در به‌روزرسانی رسیدم:

ابتدا تصور کردیم که مراحل به‌خوبی پیش می‌روند و به‌همین دلیل به وظایف دیگرم پرداختم. پس از گذشت ۶ ساعت متوجه شدم که فرایند به‌روزرسانی در ۴۵ درصد متوقف شده است. کاملا مشخص بود که فرایند به‌روزرسانی مشکل دارد و درنتیجه برای سومین مرتبه آماده شدیم.

وقتی فرایند سوم بازسازی شروع شد، همه‌چیز عادی به‌نظر می‌رسید. پس از اتمام فرایند و بارگذاری سیستم، ویندوز سرور ۲۰۱۶ بارگذاری شد! در این مرحله ما یک پارتیشن دو ترابایتی NVMe داشتیم که هیچ اطلاعاتی در آن نبود. به‌ بیان‌ دیگر تمامی داده‌های SQL ما در درایوهای NVMe پاک شده بودند. به‌هرحال زمان برای آزمایش چهارم فرا رسیده بود. در این مرحله همه‌ی درگاه‌های PCIe را در بایوس غیرفعال کردیم.

پس از رخ دادن مشکلات متعدد بالا، ما اعتماد به نفس خود را برای به‌روزرسانی به ویندوز سرور ۲۰۱۹ از دست داده بودیم. به‌ هر حال و صرف‌نظر از همه‌ی چالش‌ها، باید اجرایی بودن پروژه را بررسی می‌‌کردیم. تلاش چهارم بالاخره به نصب ویندوز سرور ۲۰۱۹ انجامید، اما باز هم مشکلی دیگر داشتیم. وقتی درگاه‌های PCIe مجددا فعال شدند، تنها دو دیسک در بخش مدیریت RSTe بخش مدیریت دیسک سرور نمایان بود. البته در بخش دیوایس منیجر همه‌ی دستگاه‌ها قابل مشاهده بودند. چرا گزارش‌ها با هم هماهنگ نبود؟ واقعا با مشکلاتی عجیب در سرور روبه‌رو بودیم.

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

در مرحله‌ی بعدی تلاش کردیم تا سرور را به حالت ۲۰۱۶ بازگردانیم و از درایورهای قدیمی برای SSDها استفاده کنیم تا شاید سرور به مرحله‌ی پیش از به‌روزرسانی به ۲۰۱۹ برگردد. ما امیدوار بودیم که در صورت بازگرداندن درایورها به وضعیت قبلی، درگاه‌های PCIe مجددا شناخته شوند و درایوها به چرخه بازگردند. آزمایش جدید هم با شکست روبه‌رو شد چون پیاده‌سازی سیستم‌عامل توانایی پیوند دادن سرور به دامین‌ها را نداشت و درنهایت ورود به سرور ممکن نبود.

تلاش‌های ما برای بازسازی سرور به مرحله‌ی ششم رسید. مرحله‌ای که بتوانیم با استفاده از ویندوز سرور ۲۰۱۶ و درایورهای قدیمی، سرور را به دامین متصل کنیم و SSD هم به‌خوبی کار کند. باز هم موفق نبودیم و فرایند اتصال به دامین مشکل داشت. مجددا هم‌تیمی‌های من تلاش کردند تا سرور را به شبکه بازگردانند. پس از اتصال به دامین، با مشکل عجیب دیگری مواجه شدیم:

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

مارک هندرسن، همکار من در زمان انتظار برای ارسال درایوهای جدید از سوی اینتل، بهینه‌سازی فرایند فورمن را انجام داد تا با نسخه‌ی ۲۰۱۹ هماهنگ شود. به‌‌علاوه او درایوهای NVMe را هم از فرایند خارج کرد تا در زمان نصب سیستم‌عامل، مزاحمتی ایجاد نکنند. همه‌ی مراحل مذکور، یعنی باید باز هم بازسازی انجام می‌دادیم. درواقع سه فرایند بازسازی در پیش داشتیم. یکی بازسازی به ۲۰۱۶، دیگری به ۲۰۱۹ و سپس مجددا بازگشت به ۲۰۱۶ که مجموعا به ۹ بازسازی روی یک سرور می‌انجامید. شاید این سؤال ایجاد شود که چرا پس از بازسازی به نسخه‌ی ۲۰۱۹، مجددا به نسخه‌ی ۲۰۱۶ بازگشتیم؟

فرایند بالا به این دلیل انجام شد که ما دیگر به‌نوعی اعتماد به‌نفسی برای استفاده از نسخه‌ی ۲۰۱۹ با SSDهای موجود نداشتیم. اینتل هم دیگر درایورهای عمومی نداشت و ما را به دل ارجاع داد. به‌هرحال ما در فرایندی رفت‌وبرگشتی گرفتار شدیم که در وضعیت مذکور، اصلا جالب نبود.

تلاش‌های متعدد و شکست‌ها و از دست دادن سخت‌افزار، ما را به‌نوعی از به‌روزرسانی سرورهای پروداکشن به ویندوز ۲۰۱۹ ناامید کرده بود. درواقع نمی‌توانستیم ریسک از بین رفتن درایوهای SSD به‌خاطر نصب ویندوز را بپذیریم. مطمئن بودیم که نسخه‌ی ۲۰۱۶ مشکلی برای آن‌ها ایجاد نمی‌کند چون سرور توسعه‌ای سال‌ها از آن استفاده می‌کرد. درنهایت تصمیم گرفتیم تا ویندوز سرور ۲۰۱۹ را تاحدودی از برنامه‌ها خارج کنیم.

پس از دو هفته بالاخره درایوهای ذخیره‌ساز جدید رسیدند و زمان نصب و آزمایش مجدد فرا رسید. در آن زمان ما بازسازی را برای دهمین مرتبه انجام می‌دادیم. برای نصب نسخه‌ی جدیدی از ویندوز ۲۰۱۶ آماده بودیم که باز هم فرایند بازسازی شکست خورد!

ابزار Puppet، رویکرد دیگری است که ما در کنار فورمن برای رساندن سرورها به حالت پایدار استفاده می‌کنیم. شکست در بازسازی آخر به‌خاطر اشکالی در پاپت بود و البته گزارشی هم در لاگ خطاها دیده نمی‌شد. به‌ هر حال فرایندها باز هم شکست خوردند و رسیدن به نسخه‌ای پایدار بدون هیچ‌گونه خطا، تا مرحله‌ی ۱۴ بازسازی طول کشید. پس از رد شدن از همه‌ی چالش‌ها، بالاخره نسخه‌ای پایدار و تمیز از سرور توسعه‌ای داشتیم. ویندوز سرور ۲۰۱۶ به‌خوبی نصب شده بود و نوبت به نصب SQL Server رسید که در ظاهر دشواری چندانی نداشت.

سرور تحت آزمایش، مشکلات بسیار متعددی داشت. SQL Server 2017 برای نصب انتخاب شده بود که همیشه با چند دستور PowerShell به‌راحتی پیاده می‌شد، اما در سرور مذکور باز هم به چالش برخوردیم. در نصب ماژول SqlServer و سپس SPNها، مشکلات زیادی داشتیم و روند به‌خوبی پیش نمی‌رفت. به‌هرحال همه‌ی چالش‌ها به ترتیب حل شدند و درنهایت یک سرور توسعه‌ای با تمامی دیتابیس‌ها راه‌اندازی شد.

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

فرایند آزمایش و پیاده‌سازی در سرورهای توسعه‌ای تا میانه‌های آوریل طول کشید و به‌نوعی ما دو ماه درگیر آن‌ها بودیم. به‌هرحال همه چیز برای پیاده‌سازی‌های نهایی و تغییر سیستم‌عامل سرور پروداکشن آماده بود.

فاز سوم: سرور پروداکشن

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

برنامه‌ی پیاده‌سازی برای سرور پروداکشن، دقیق‌ترین طرحی بود که تا آن زمان تدوین کرده بودم. به‌هرحال تلاش کردیم تا همه‌ی جزئیات پوشش داده شود و نیک کراور هم در مسیر تدوین به من کمک کرد. همه‌چیز برای اجرا آماده بود و سندی ۳۵ صفحه‌ای به‌عنوان راهنمای اجرا پیش روی ما قرار داشت. فرایندها برای هر سرور به‌صورت مجزا نوشته شد و هر فعالیتی از ساده تا پیچیده، برنامه‌ریزی شده بود. برای هر سرور در سند راهنما، دستوراتی شبیه به موارد زیر داشتیم:

• پشتیبان‌گیری لاگ تراکنش‌ها را در سرور اصلی متوقف کنید
• روتینگ فقط-خواندن را از AG بردارید
• اتصالات را در اپلیکیشن فلاش کنید
• پشتیبان‌گیری کامل را در سرور اصلی قطع کنید
• سرور را از AGهای موجود در سرور اصلی حذف کنید
• سرور را از کلاستر کنونی حذف کنید
• سرور را برای پیاده‌سازی نسخه‌ی ۲۰۱۶ به فورمن وارد کرده و فرایند بازسازی را شروع کنید
• مطمئن شوید که پس از بازسازی، پاپت اجرا شده و مشغول به کار باشد
• پس از بازسازی، نقش Failover Cluster را به سرور اضافه کنید (سرور ریبوت می‌شود)
• یک WSFC جدید بسازید
• وقتی Cluster Object در AD ایجاد شد، اگر نیاز بود آن را به OU منتقل کنید
• وقتی کلاستر آبجکت ایجاد شد، آرس‌های IP را بررسی کرده و آن‌ها را ویرایش کنید
• مطمئن شوید که کلاستر آبجکت در WSFC مجوز ساختن و پاک کردن آبجکت‌های کامپیوتری را در AD دارد
• ابزارهای Dell NVMe را نصب کنید
• SQL Server را نصب کنید (اگر tempdb هنوز در پوشه‌ی D:\Data بود، ابتدا همه‌ی فایل‌ها را پاک کنید)
• حالت Trace Flags را فعال و سرویس SQL را مجددا بارگذاری کنید
• اسکریپت‌های مربوطه برای اضافه کردن اطلاعات ورود، کاربران و موارد دیگر را اجرا کنید
• AG جدید بسازید
• برای هر AG یک AG توزیع‌شده‌ی موقت (TAG) ایجاد کنید که ابتدا در سرور اولیه و سپس ثانویه پیاده شوند
• در این مرحله همه‌ی داده‌ها باید به‌خوبی با سرور جدید همگام‌سازی شوند که سروری مجزا در کلاستر اختصاصی خود خواهد بود
• جاب‌های sql را بازسازی کنید
• جاب پشتیبان‌گیری را برای دیتابیس کاربران غیرفعال کنید
• جاب پشتیبان‌گیری را در سرور اولیه‌ی کلاستر قدیمی مجددا راه‌اندازی کنید

اگرچه مراحل پیاده‌سازی برای هر سرور منحصربه‌فرد است، اما فرایندهای بالا به‌نوعی پایه‌های اجرایی همه‌ی آن‌ها محسوب می‌شوند. اگر همه‌ی برنامه‌ها به‌خوبی پیش می‌رفت، تا پایان چهارشنبه ۱۷ آوریل ۲۰۱۹ سه سرور را به کلاسترهای جدید جابه‌جا کرده بودیم و SQL Server روی همه‌ی آن‌ها نصب شده بود. درنتیجه فرایند همگام‌سازی هم به‌درستی انجام می‌شد و به دیاگرامی شبیه به تصویر زیر می‌رسیدیم:

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

روز اول

روز اول، برنامه‌ی مخصوص سرور اول یعنی NY-SQL-03 را اجرا کردیم که سرور ثانویه‌ی کلاستر NY بود. همه‌ی موارد طبق برنامه پیش رفتند. ویندوز و SQL Server نصب شدند، کلاستر آماده شد و همه‌ی چهار TAG مورد نظر پیکربندی شدند. همه‌ی دیتابیس‌ها فرایند همگام‌سازی را انجام می‌دادند و در Opserver وضعیت سبز داشتند. به‌هرحال روز اول با موفقیت پیش رفت و پنج سرور دیگر در صف تغییرات بودند.

روز دوم

فعالیت روز دوم زودتر و جدی‌تر پیگیری شد، چون تصمیم داشتیم تا دو سرور را تغییر دهیم. NY-SQL-01 و CO-SQL-03 در برنامه‌ی روز دوم بودند. فرایند بازسازی را به‌صورت هم‌زمان روی دو سرور انجام دادیم. NY-SQL-01 پس از چند ساعت به فرایند کاری بازگشت، اما سرور دیگر دشواری‌هایی را به‌همراه داشت.

سرور دوم یا CO در فرایند بازسازی مشکلات عجیبی را نشان می‌داد. این سرور تنها نود کلاستر ۲۰۱۶ جدید بود. سیستم دارای ۳۷۵ دیتابیس بود که در چهار AG قرار داشتند و همچنین چهار DAG هم برای همگام‌سازی داده‌ها بین سرورهای ۲۰۱۲ و ۲۰۱۶ استفاده می‌شدند. به‌هرحال پس از چند ساعت فرایند همگام‌سازی، مشکلاتی را در Opserver مشاهده کردم که به‌معنای توقف‌های متعدد در جابه‌جایی داده‌ها بود.

فرایند ارسال و دریافت دیتابیس سرور CO به‌راحتی صورت نمی‌گرفت. وضعیت AG نیز مدام تغییر می‌کرد و قابل اعتماد نبود. به‌هرحال پس از چند ساعت تلاش برای دیباگ کردن تصمیم گرفتم که TAG‌ها را غیرفعال کرده و آن‌ها را بازسازی کنم. هر TAG بازسازی‌شده فرایند همگام‌سازی را به‌خوبی انجام می‌داد، اما به‌هرحال هنوز مشکل اجرایی داشتیم.

برای رفع مشکلات ابتدا تصمیم گرفتیم که سرویس SQL Server را مجددا راه‌اندازی کنیم. سپس متوقف کردن AG در WSFC را انجام دادیم و لاگ خطاها، باز هم مشکل را در AG نشان می‌داد. با بررسی فرایندهای متعدد تصمیم گرفتیم که بکاپ جدیدی از دیتابیس در AG داشته باشیم و آن را به NY-SQL-03 بازگردانیم و سپس با اتصال آن به AG فرایند همگام‌سازی را مجددا شروع کنیم.

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

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

روزهای سوم تا هفتم

فرایندهای انتقال دیتابیس به‌خوبی ادامه پیدا کردند، اما باز هم تأخیرهایی در آن‌ها وجود داشت. ما حتی در انجمن‌های استک‌اکسچنج خود با کاربران برای رفع مشکل مشورت کردیم و یک نفر غیرفعال کردن Parallel Redoرا در SQL Server پیشنهاد داد. به‌هرحال همه‌ی راهکارهای ممکن را امتحان کردیم، اما چالش‌هایی که در DMV و همچنین تأخیرهای مکرر داشتیم، نتیجه‌گیری را دشوار می‌کرد. درنهایت مجبور شدیم تا در یک تیکت پشتیبانی ازمایکروسافت درخواست کمک کنیم.

در زمان انتظار برای پاسخ مایکروسافت، به بهینه‌سازی سرور CO-SQL03 مشغول شدیم تا آن را در وضعیتی پایدار نگه داریم. بکاپ‌هایی به‌صورت Copy Only در کلرادو گرفتیم تا در زمان نیاز احتمالی، مجبور به جابه‌جایی چند ترابایت دیتا از نیویورک به کلرادو نباشیم. به‌هرحال مشکلات باز هم ادامه داشتند و قطع سرورها طولانی‌تر شد. به‌هرحال برنامه‌ی ایجاد بکاپ‌ها هم به‌خوبی پیش نرفت و مجبور شدیم همه‌ی فایل‌های پشتیبان را از نیویورک به کلرادو منتقل کنیم. درنهایت همه‌ی فایل‌ها در یک روز کپی شدند و تنها چالش، برگشتن کلیت سرور به وضعیت پایدار بود.

پس از دریافت پاسخ تیکت از سوی مایکروسافت، با یکی از کاربران متخصص دیتابیس به‌نام شان گالاردی مشاوره کردم که کارمند مایکروسافت هم بود. در این مرحله باید به فرایند دشوار به‌روزرسانی برمی‌گشتیم و شان پیشنهاد داد که فرایند auto-seeding (فرایندی برای راه‌اندازی AG) را SENetwork_TAG غیرفعال کنیم. درنتیجه کد زیر را اجرا کردیم:

کد بالا فرایند سید خودکار دیتابیس را متوقف کرد، اما مشکل به قوت خود باقی بود. ما هنوز نمی‌توانستیم دیتابیس را در کلاستر جدید همگام‌سازی کنیم و هنوز مشکلات متعدد کوچکی در NY-SQL-03 وجود داشت. درنهایت مشورت من و نیک و شان به راهکار زیر ختم شد:

۱- TAG مرتبط با SENetwork را حذف کنیم چون به‌خاطر مشکل اصلی ایجاد شده بود.

۲- AG موجود در کلاستر جدید را حذف کنیم.

۳- دیتابیس‌ها را به‌صورت دستی در وضعیت بازیابی NY-SQL03 و CO-SQL03 بازیابی کنیم.

۴- TAG مورد نظر برای SENetwork را بازسازی کنیم.

۵- به‌آرامی هر دیتابیس را به AG در هر دو سرور NY-SQL03 و CO-SQL03 اضافه کنیم تا فرایند همگام‌سازی انجام شود.

درنتیجه مجددا فرایند آهسته‌ای شروع شد که در هر مرتبه دو تا چهار دیتابیس را وارد روند بالا می‌کردیم. برای آهسته بودن فرایند همین بس که باید ۳۵۴ دیتابیس را جابه‌جا می‌کردیم. مشکل اصلی ما، باگی در SQL Server بود که در زمان افزایش دیتابیس‌های یک AG از ۱۵ عدد رخ می‌دهد. DAG ما شامل ۳۵۴ دیتابیس بود و به‌همین دلیل نمی‌توانست این تعداد را مدیریت کند.

با ادامه دادن روند بالا تا آخر هفته ما دو کلاستر جدید داشتیم که داده را از کلاسترهای قدیمی ۲۰۱۲ دریافت می‌کردند. درنهایت زمان آن رسیده بود که فرایند انتقال (failover) را از TAGها انجام دهیم. با وجود همه‌‌ی زمان‌هایی که در دیباگ کردن از دست دادیم، درنهایت به وضعیتی پایدار رسیده بودیم و برنامه‌ریزی زمان انتقال ممکن بود. تا پایان هفته سرورها به وضعیت زیر رسیده بودند:

در پایان هفته و پس از چند مشکل جزئی دیگر، برای اجرای نهایی فرایند آماده بودیم.

روز هشتم

هفته‌ی جدید شروع شده بود و ما به‌جز سه سرور باقی‌مانده، یک فرایند انتقال بزرگ در پیش داشتیم. البته همه‌ی باگ‌‌ها از بین رفته بودند و مسیری مستقیم تا پایان خط داشتیم. روز هشتم را با جدا کردن CO-SQL01 از کلاستر قدیمی و فرایند بازسازی شروع کردم. باز هم مشکلاتی پیش آمد. فرایند خودکار فورمن به‌خوبی کار نمی‌کرد و مدام باید بهینه‌سازی‌هایی در آن انجام می‌دادیم. به‌علاوه فرایند به‌روزرسانی ویندوز هم دچار مشکل شد. بالاخره توانستم SQL Server را نصب کنم و بکاپ‌ها را در وضعیت NORECOVERY بازیابی کنم. سپس پیاده‌سازی لاگ‌ها انجام شد تا دیتابیس به وضعیت کنونی برسد و درنهایت، همگام‌سازی داده شروع شد. درنهایت چهار سرور در کلاسترهای جدید داشتیم که همه در وضعیت سبز کار می‌کردند.

روز نهم: اجرای فرایند failover

روز مهم فرا رسید و ما باید پنج TAG را با زمان تأخیر هرچه پایین‌تر جابه‌جا می‌کردیم. من قبلا فرایند را در محیط آزمایشگاهی بررسی کرده بودم، اما هیچ‌گاه تجربه‌ی اجرای آن را در سرور پروداکشن نداشتم. به‌علاوه با نگاهی به گذشته و همه‌ی مشکلاتی که تجربه کردیم، تاحدودی استرس داشتم. به‌هرحال در ابتدای روز همه‌ی روندهای آتی در شب را بررسی کردیم. پیچیدگی فرایند تنها به جابه‌جایی SQL Server محدود نبود. ما باید نسخه‌ی جدیدی از همه‌ی اپلیکیشن‌ها و سرویس‌های خود را نیز بازسازی و ارائه می‌کردیم، چون تغییراتی در کانکشن استرینگ ایجاد شده بود.

تغییر در اپلیکیشن‌ها به‌‌خاطر ایجاد کلاسترهای جدید با AG و DAG جدید بود که همه باید به آدرس‌های IP جدید متصل می‌شدند. به‌علاوه در کنار حساسیتی که در اجرای فرایندها در روز failover داشتیم، اولویت اجرای آن‌ها نیز بسیار مهم بود. اولین دیتابیس در دسته‌ی Exceptions قرار می‌گرفت که به‌نام NY.Exceptions می‌شناسیم. این دیتابیس برای ذخیره‌ی خطاهایی استفاده می‌شود که در شبکه ظاهر می‌شوند. ابتدا دیتابیس مذکور را از AG در کلاسترهای قدیمی و جدید حذف کرده و قابلیت نوشتن روی آن را نیز بررسی کردیم. به‌علاوه هر دو دیتابیس را به فرایند نظارتی Opserver اضافه کردیم تا اپلیکیشن‌های با مقاصد اتصالی غلط، حین فرایند شناسایی شوند. چنین رویکردی امکان ردگیری خطاها را فراهم می‌‌کرد.

مرحله‌ی بعدی، اعمال تغییرات اپلیکیشن‌ها به پروداکشن بود. ما از Team City برای پیاده‌سازی اپلیکیشن‌ها استفاده می‌کنیم که یک دیتابیس روی SQL Server دارد. باید پیش از ادامه‌ی فرایند از آماده بودن تیم سیتی مطمئن می‌شدیم. درنتیجه برای اولین اقدام جابه‌جایی، NYOnly_AG را انتخاب کردیم و کانکشن استرینگ را از SQL-NYOnly_AG به SQLAG-NYOnly تغییر دادیم. سپس اپلیکیشن ساخته شد و مرحله‌ی بعدی، جابه‌جایی DAG بود.

طبق اسناد مایکروسافت برای failover یک DAG باید از فرایندی دستی استفاده کرد. کد مورد نظر ابتدا باید در سرور کنونی اولیه اجرا شود و پس از تأیید شدن، کدهای بیشتر اجرا شوند و این فرایند چندین بار ادامه پیدا می‌کند. در سند راهنمای انتقال، همه‌ی کدهای لازم نوشته شد و اکنون زمان اجرا بود. درنهایت با اجرای کدهای مرحله‌ی اول، اولین DAG جابه‌جا شده بود و همه‌ی موارد نیز قابل نوشتن بودند. تنها چهار دسته‌ی دیگر باقی ماند.

برای جابه‌جایی بعدی Chat_TAG را انتخاب کردیم و مراحل قبلی تکرار شدند. به‌هرحال این بخش هم انجام شد و سه مورد دیگر برای جابه‌جایی باقی ماند. برای کاهش تأثیر failover روی کاربران، فرایند را در ساعات پایانی روز انجام دادیم. درنتیجه همگام‌سازی با کلاستر گزارش‌دهی نیز به‌مرور پایان می‌یافت. به‌هرحال چنین اتفاقی بالاخره رخ می‌داد و ما تنها زمان آن را کمی عقب انداختیم. کاربران از فرایند failover آگاه بودند و ما هم تلاش کردیم تا هرچه سریع‌تر مجددا آنلاین شویم.

پیش از اجرای فرایند جابه‌جایی نهایی، DAG قدیمی بین کلاستر ۲۰۱۲ و کلاستر گزارش‌دهی حذف شد. درواقع ما می‌دانستیم که همگام‌سازی داده‌ها در زمان جابه‌جایی نهایی متوقف می‌شود و از بین برد DAG فرایندی اجتناب‌ناپذیر بود. پس از اینکه HighAvailability_DAG پاک شد، بخش جابز در سایت را به فقط-خواندن تغییر دادیم. سپس کانکشن استرینگ در همه‌ی اپلیکیشن‌ها جایگزین شد و مجددا آن‌ها را ساختیم. سپس نوبت به فرایند انتقال نهایی DAG جدید رسید که به‌نام Misc_TAG شناخته می‌شد. این بخش هم بدون مشکل پیش رفت و دیتابیس Careers مجددا قابل نوشتن شد. درنهایت جابز را از حالت فقط-خواندن خارج کردیم و همه‌چیز برای ادامه‌ی راه فراهم شد.

انتقال‌ها یا failoverهای نهایی مربوط به StackOverflow_TAG بو SENetwork_TAG بودند. با توجه به نام گرو‌های می‌دانیم که جابه‌جایی آن‌ها منجر به قطعی موقت می‌شد. به‌هرحال باید فرایند را با سرعت هرچه بیشتر انجام می‌دادیم. DAGهای مذکور تمامی دیتابیس‌های شبکه‌ی سایت‌ها را مدیریت می‌کنند و جابه‌جایی سریع آن‌ها منجر به کاهش زمان قطعی می‌شد.

اولین فرایند failover مربوط به StackOverflow_TAG بود که تنها پنج دیتابیس داشت و به تصور ما، جابه‌جایی آن سریع‌تر انجام می‌شد (دیگری قطعا با ۳۵۴ دیتابیس، مشکلات بیشتری ایجاد می‌کرد). ابتدا DAG قدیمی که به کلاستر گزارش‌دهی می‌رفت را حذف کردم و سپس فرایند failover برای گروه مذکور شروع شد و بدون هیچ مشکلی پایان یافت. گروه دوم نیز با وجود تمام استرس گروه به‌خوبی جابه‌جایی شد و سپس فرایند تأیید LSNها صورت گرفت.

تأیید LSNها با اجرای چند خط دستور و بررسی ۳۵۴ دیتابیس با هم انجام می‌شد که قطعا فرایندی پیچیده و دشوار بود. فرایند تأیید و بررسی چندین بار انجام می‌شد تا از هماهنگ بودن همه چیز مطمئن شویم. مدتی طول کشید تا از عالی بودن همه چیز مطمئن شویم. هدف ما از دست دادن حداقل داده بود و در این‌ مسیر به‌نوعی با همه‌ی‌ دیتابیس‌ها درگیر می‌شدیم.

پس از بررسی همه‌ی دیتابیس‌ها به مرحله‌ی پایانی failover برای SENetwork_TAG رسیدیم. کدهای مربوطه اجرا شدند و درنهایت سرور اصلی NY-SQL03 جدید شروع به کار کرد. بالاخره انتقال همه‌ی TAGها انجام شد و همه‌ی سایت‌ها در حالت آنلاین بودند. همه به این تصور رسیدیم که فرایند failover تمام شده است.

پس از پایان فرایند انتقال دیتابیس‌ها، سرور اصلی NY-SQL04 دچار مشکل شد و به نوعی پاسخگویی مناسبی در برابر دستورها نداشت. همه‌ی دیتابیس‌های آن قفل شده بودند و پردازنده با شدت بالایی کار می‌کرد. تا ۲۵ دقیقه هیچ پاسخی از سرور نداشتیم. به‌هرحال یک سرور جدید داشتیم و می‌توانستیم آن را کاملا به ویندوز سرور ۲۰۱۶ بازسازی کنیم. درنهایت تصمیم گرفتیم تا زمان بازسازی، SQL Server را متوقف کنیم.

پس از رفع چالش‌ها فوق، کل فرایند انتقال پایان یافت و همه‌ی سیستم‌ها در کلاستر ویندوز سرور ۲۰۱۶ طبق دیاگرام زیر مشغول به فعالیت بودند:

هنوز دو سرور در کلاستر ۲۰۱۲ فعال بودند. NY-SQL04 به‌‌صورت SQL Server فعالیت نمی‌کرد چون سرویس اس‌کیو‌ال را پس از فرایند انتقال قطع کرده بودیم. به‌علاوه NY-SQL02 عضو گروه TAG بود که به‌تازگی منتقل کرده بودیم. به‌هرحال سرورهای مذکور را در روز بعد بازسازی می‌کردیم و در روز دهن تنها روی کلاستر گزارش‌دهی متمرکز بودیم. این کلاستر برای کاربردهای داخلی اپلیکیشن‌ها استفاده می‌شود و باید هرچه سریع‌تر آن را آنلاین می‌کردیم.

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

پس از اجرای کدهای مربوطه مجددا به مشکل خوردیم و کلاستر گزارش‌دهی فرایند همگام‌سازی را انجام نمی‌داد. کدهای دستوری متعددی را در دیتابیس‌ها اجرا کردیم و حتی کلاستر گزارش‌دهی را برای انتقال به سرور ثانویه‌ی کلرادو و سپس بازگرداندن آماده کردیم. در ادامه باز هم در اجرای فرایندها موفق نبودیم و در لاگ خطاها، موارد متعددی مشاهده شدند. برای رفع چالش‌ها فرایند بازیابی (Restore) را در دیتابیس‌ها انجام دادیم و با اجرای کد زیر، فرایند همگام‌سازی شروع شد:

Alter Database [database_name] Set HADR Availability Group = [distributed_AG_Name];

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

روز دهم: اصلاحات نهایی

پس از استراحت از روز دشوار نهم و فرایند حساس failover، نوبت به پایان فهرست انتقال رسیده بود که با وجود کم بودن وظایف در آن، موارد حساسی را شامل می‌شد. فهرست وظایف روز دهم شامل موارد زیر می‌شد:

• بازیابی دیتابیس‌ها به CO-RPTSQL01 و اجرای فرایند همگام‌سازی در AG‌ و AGهای توزیع‌شده در کلاستر گزارش‌دهی
• حذف AGهای توزیع‌شده‌ی موقتی در کلاسترهای جدید ۲۰۱۶
• بازسازی NY-SQL04 و NY-SQL02 که آخرین سرورهای موجود در کلاستر ۲۰۱۲ بودند
• وارد کردن سرورهای جدید به کلاسترهای جدید ویندوز ۲۰۱۶، نصب SQL Server و اضافه کردن آن‌ها به AG
• روشن کردن همه‌ی فرایندهای بکاپ گیری t-log و بکاپ‌های کامل روزانه
• اضافه کردن مسیردهی فقط خواندن در همه‌ی AGها

همه‌ی وظایف بالا باید در طول یک روز انجام می‌شدند، اما از همان ابتدا به چالش برخورد کردیم. یکی از سرورهای گزارش‌دهی که در روز نهم اعلام وضعیت همگام‌سازی داده بود، در چنین وضعیتی قرار نداشت. درواقع گزارش‌های نظارت عملکرد آن صحیح نبودند. ابتدا SQL Service را مجددا راه‌اندازی کردیم، اما موفقیتی حاصل نشد. تنها راه برای اجرای بهینه‌ی همگام‌سازی، مراحل زیر بود:

• جداسازی و وصل کردن دیتابیس‌ها
• اجرای t-logs برای همگام‌سازی به وضعیت کنونی
• در مرحله‌ی نهایی احتمالا با اجرای چند فرمان SQL در AGها، فرایند همگام‌سازی شروع می‌شد

همه‌ی فرایندهای بالا برای کلاستر گزارش‌دهی اولیه‌ی NY-RPTSQL01 انجام شد و سپس باید برای CO-RPTSQL01 نیز آن‌ها را اجرا می‌کردیم. نیک روی سرورهای گزارش‌دهی نیویورک و کلرادو متمرکز شد و من هم بازسازی دو سرور نهایی یعنی NY-SQL04 و NY-SQL02 را بر عهده گرفتم. بازسازی سرورها به‌خوبی انجام شد و در مرحله‌ی اضافه کردن به AG، بکاپ‌های جدید از سرورهای اولیه گرفته و به سرورهای جدید منتقل شد. انجام فرایند مذکور به این خاطر بود که یک AG با ۳۵۴ دیتابیس (با حجم ۳/۵ ترابایت) را به‌صورت خودکار جابه‌جا نکنیم. درواقع قصد داشتیم تا حداقل T-log برای راه‌اندازی و تنظیم دیتابیس‌ها به وضعیت آنلاین اجرا شوند. درنهایت Opserver در همه‌ی بخش‌ها گزارش عملکرد موفق می‌داد:

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

صحبت نهایی

فرایند به‌روزرسانی سرورها یکی از پیچیده‌ترین پروژه‌های من بود که از لحاظ پیچیدگی با به‌روزرسانی SQL Server 2017 در سال گذشته برابری می‌کرد. پروژه‌ای که شامل کلنجار رفتن‌های متعدد با سرورها، دیتابیس‌ها و AGهای متعدد می‌شد و باید در حداقل زمان در دسترس نبودن سایت انجام می‌گرفت. کل فرایند تنها منجر به ۱۰ الی ۱۵ دقیقه در دسترس نبودن عمومی سایت شد که از نظر من رکورد قابل‌‌توجهی بود.

در پایان نتایج و نکاتی که از این پروژه آموختم را به‌صورت خلاصه ارائه می‌کنم:

• آزمایش کنید، آزمایش کنید و این روند را چند بار اجرا کنید. برنامه‌ی اولیه شامل اجرای نهایی پس از آزمایش‌های اولیه بود و تغییر در سرورهای توسعه‌ای ناگهان به پروژه اضافه شد. تصور نمی‌کردیم که فرایند منجر به ایجاد خلل در محیط توسعه شود، اما به‌هرحال چالش‌های مذکور باگ‌های متعددی را به ما نشان دادند. اگر آزمایش انجام نمی‌شد، احتمال بروز باگ‌ها در پیاده‌سازی سرور پروداکشن وجود داشت.
• در صورت امکان همیشه یک محیط آزمایشی داشته باشید. من با استفاده از محیط‌های آزمایشگاهی تقریبا همه‌ی چالش‌های احتمالی در روند پروژه را پیش‌بینی و تجربه کردم. البته قابلیت آزمایش کردن در مقیاس واقعی را نداشتم، اما به‌هرحال از کارساز بودن مراحل برنامه‌ریزی تاحدودی مطمئن شدم.
• به تیم خود اعتماد کنید. اگرچه من مدیر و مسئول اصلی دیتابیس در استک‌ اورفلو هستم، برخی اوقات در اجرای روندها در فورمن یا پاپت به مشکل بر می‌خوردم. واقعا باید از کمک‌های اعضای تیم در حل چالش‌ها قدردانی کنم.
• فراموش نکنید که با وجود همه‌ی برنامه‌ریزی‌ها، باز هم رخدادهای غیرقابل پیش‌بینی اتفاق می‌افتد. من دستورالعملی ۳۵ صفحه‌ای داشتم، اما در زمان وقوع باگ هیچ‌یک از بخش‌های آن کارآمد نبود.
• در زمان خارج شدن اوضاع از کنترل، تحت استرس قرار نگیرید. چالش‌های متعددی در پروژه‌ی ما رخ داد و من از خستگی تیمم ناراحت می‌شدم. به‌هرحال فرایند به‌جای یک ماه، چهار ماه طول کشید و تأثیر منفی زیادی روی اعتماد به نفس ما داشت. با وجود همه‌ی مشکلات، ما به جلو پیش رفتیم و روند خود را بهبود دادیم. درنهایت حفظ چشم‌انداز از دستاورد نهایی، در عبور از چالش‌های فنی بسیار کارساز خواهد بود.
• در زمان انجام فرایندهای پیاده‌سازی شبیه به پروژ‌ه‌ی ما، همیشه یادداشت‌برداری کنید. هر روز یادداشتی از رخدادها داشته باشید و همه‌ی اتفاق‌های مثبت و منفی رخ داده را بررسی کنید. در نوشتن این مقاله هم از همان یادداشت‌ها استفاده شد.

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

ماسایوشی سان، بنیان‌گذار سافت بانک از برنامه‌ی جدید شرکتش برای سرمایه‌گذاری عظیم در حوزه‌ی فناوری رونمایی کرد. درواقع او و شرکت تحت مدیریتش در تلاش هستند تا جایگاه خود را به‌عنوان تأثیرگذارترین سرمایه‌گذار صنعت ثبت کنند. غول ژاپنی قصد دارد تا با جذب سرمایه‌‌ای ۱۰۸ میلیارد دلاری، دومین صندوق سرمایه‌گذاری ویژن فاند را تأسیس کند؛ سرمایه‌ای که رکورد ویژن فاند اول را به مبلغ ۱۰۰ میلیارد دلار پشت سر خواهد گذاشت.

خود سافت بانک در روند جدید جذب سرمایه، ۳۸ میلیارد دلار سرمایه تزریق خواهد کرد که نشان از ریسک‌پذیری بالای این شرکت و بنیان‌گذارش دارد. چنین رویکردی آن‌ها را به‌عنوان بزرگ‌ترین سرمایه‌گذار صندوق معرفی می‌کند؛ رتبه‌ای که در صندوق اول به عربستان سعودی تعلق داشت. سعودی‌ها در سرمایه‌گذاری صندوق اول سهم ۴۵ میلیارد دلاری داشتند و با شرکتی به‌نام Public Investment Fund وارد همکاری شدند. البته سافت بانک در رونمایی از صندوق جدید هیچ اشاره‌ای به عربستان نداشت.

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

ماسایوشی سان تصمیم دارد تا هر دو یا سه سال، برنامه‌ی جذب سرمایه‌ای اجرا کرده تا از فرصت‌های جدید موجود در فناوری‌های فوق پیشرفته همچون هوش مصنوعی و خودروهای خودران بهره‌برداری کند. شرکت او در ماه ژوئن اعلام کرد که ویژن فاند اولیه تاکنون ۶۲ درصد بازگشت سرمایه داشته است. آن‌ها تاکنون ۶۴/۲ میلیارد دلار را طی ۷۱ قرارداد سرمایه‌گذاری کرده‌اند.

کریس لین، یکی از تحلیل‌گران استنفورد سی برنشتین درباره‌ی سرمایه‌گذاری‌های سافت بانک می‌گوید:

من تصور نمی‌کردم که بدون کمک سعودی‌ها بتوان ۱۰۰ میلیارد دلار سرمایه جذب کرد. از نظر من کاهش تأثیر دولت سعودی در سرمایه‌گذاری‌ها، تصمیمی عاقلانه از سوی سافت بانک بود. 

دیسوکه سواتاکه، یکی از سخنگوهای سافت بانک از تلاش شرکت‌های عربستانی برای سرمایه‌گذاری در ویژن فاند ۲ می‌گوید. او نام شرکت‌هایی همچون PIF و Mubadala Investment را به‌عنوان متقاضیان ورود به دور جدید جذب سرمایه نام برده است. به‌هرحال هنوز مشخصی نیست که آیا کاهش فعالیت عربستان به‌خاطر فشارهای سافت‌بانک یا خود کشور سعودی بوده است یا خیر.

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

امیر انورزاده، استراتژیست Asymmetric Advisors ایده‌ی تصمیم‌های اخلاقی سافت‌بانک در قبول سرمایه از عربستانی‌ها را دور از ذهن می‌داند. او در یادداشتی تحقیقاتی نوشت که شرکت‌های عربستانی و دولت این کشور، احتمالا تنها به‌خاطر بالا بودن ریسک سرمایه‌گذاری جدید به آن وارد نشده‌اند. به‌عنوان نمونه‌ای از ریسک‌های جدید، سان از سرمایه‌گذاری ۱۶ میلیارد دلاری روی وی‌ورک صحبت کرد؛ یک سرمایه‌گذاری که به هشت میلیارد دلار قبلی در شرکت مذکور اضافه خواهد شد.

برنامه‌های سافت بانک برای افزایش سرمایه‌گذاری در دور دوم، نشان‌دهنده‌ی ریسک‌هایی هم برای این شرکت خواهد بود. S&P Global Ratings به‌نوعی برنامه‌های ویژن فاند ۲ را خطرناک می‌داند. این مؤسسه‌ در مطلبی پیرامون سافت بانک نوشت:

برنامه‌ی آن‌ها برای دومین جذب سرمایه‌ی بزرگ با چنین سرعتی، نشان‌دهنده‌ی یک استراتژی رشد تهاجمی است. به‌علاوه سیاست‌های مالی در پشت آن دیده می‌شود که در ادامه منجر به کاهش اعتبار آن‌ها خواهد شد.

از شرکت‌های مالی ژاپنی که آمادگی خود را برای همکاری اعلام کرده و اسناد MOU را امضا کرده‌اند، می‌توان به Mizuho، Sumitomo، Mitsubishi UFJ، Dai-ichi Life Holdings، Sumitomo Mitsui Trust Holdings و Daiwa Securities اشاره کرد. به‌علاوه شرکت تایوانی Standard Chertered هم در فرایندهای جذب سرمایه همکاری می‌کند.

ساتورو کیکوچی، تحلیل‌گر SMBC Nikko در توکیو در یادداشتی تحقیقاتی نوشت که افزایش تنوع در گروه سرمایه‌گذارها و حضور جدی سافت‌بانک در فرایند جذب سرمایه، افزایش تأثیرگذاری شرکت ژاپنی را تضمین می‌کند. کیکوچی همچنین ادعا کرد که شاید سافت بانک بخشی از سهام خود را در گروه علی‌بابا بفروشد تا سرمایه‌ی لازم برای مشارکت در فرایند جذب سرمایه را به دست بیاورد.

ویژن فاند اول در اکتبر ۲۰۱۶ رونمایی شد، اما هفت ماه طول کشید تا فرایند جذب سرمایه به مرحله‌ی نهایی رسید. عربستان سعودی با سرمایه‌گذاری ۴۵ میلیارد دلاری به‌عنوان بزرگ‌ترین بازیگر آن برنامه شناخته شد. پس از آن، سافت بانک با سرمایه‌گذاری ۲۸ میلیارد دلاری قرار داشت و در رتبه‌ی بعدی، شرکت Mubadala از ابوظبی با ۱۵ میلیارد دلار سرمایه مشارکت می‌کرد. از سرمایه‌گذارهای دیگر می‌توان به کوالکام و شارپ اشاره کرد. به‌ هر حال سرمایه‌گذاری‌های عظیم سعودی‌ها در جذب سرمایه‌ی اولیه، به‌نوعی قدرت سان و سافت بانک را در سرمایه‌گذاری‌ها محدود می‌کرد.

ماسایوشی سان ۶۱ ساله برای سال‌ها مشغول ساخت امپراطوری مخابراتی خود بود و اکنون زمان بیشتری را به سرمایه‌‌گذاری اختصاص می‌دهد. او مدیریت برنامه‌های مخابراتی داخلی سافت بانک را به کن میائوچی، همکار قدیمی‌اش واگذار کرد. بخش مخابراتی سافت بانک برای سال‌ها منبع درآمد مهم و بزرگ شرکت محسوب می‌شد و سهام آن در دسامبر گذشته به‌صورت عمومی عرضه شد. سان همچنین برنامه‌ی فروش دارایی دیگرش یعنی Sprint را نیز به T-Mobile مدیریت و تأیید کرد که البته هنوز در مراحل تأیید قانونی قرار دارد.

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

فعالیت‌های بزرگ و تهاجمی سافت بانک در سرمایه‌گذاری حوزه‌ی فناوری این سؤال را ایجاد می‌کند که آیا آن‌ها می‌توانند سرعت و مقیاس سرمایه‌گذاری‌های خود را حفظ کنند؟ سهام مشارکت‌کننده‌ها در اولین سرمایه‌گذاری، ۱۰۰ میلیون دلار بود و در عرض دو سال پورتفولیویی شامل ۸۲ شرکت پیش‌گام در دنیای فناوری را شکل داد. از میان آن‌ها شرکت‌هایی همچون اوبر و وی‌ورک شهرتی بیش از سایر داشتند. بخش تاکسی‌های اینترنتی، سهم عمده‌ای از سرمایه‌گذاری‌های سافت بانک و شرکا را به خود اختصاص می‌دهد. در این بخش می‌توان به شرکت‌هایی همچون Didi Chuxing در چین، Ola در هند و Grab در سنگاپور را نام برد.

با توجه به داده‌های شرکت تحقیقات بازار CB Insights نام سافت بانک در فهرست ۲۴ مورد از مجموع ۳۷۷ سرمایه‌گذاری‌های یونیکورن دنیای فناوری دیده می‌شود. یونیکورن به استارتاپ‌هایی گفته می‌شود که به ارزش بیش از یک میلیارد دلار رسیده باشند. اگرچه بسیاری از استارتاپ‌های پورتفولیوی این شرکت مانند اسلک و اوبر، سهام خود را به‌صورت عمومی عرضه کرده‌اند، خروج و سوددهی سرمایه‌گذاری در بسیاری از آن‌ها هنوز در هاله‌ای از ابهام است.

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

سافت بانک استراتژی مبنی بر افزایش ابعاد و استفاده از قدرت خود برای خرید سهام استارتاپ‌هایی در مراحل پایانی (نزدیک به عرضه‌ی عمومی سهام) یا یونیکورن‌ها دارد. این استراتژی وابسته به افزایش شدید ارزش شرکت‌ها در جریان IPO است. درواقع آن‌ها تلاش می‌کنند تا ارزش شرکت‌های خصوصی موجود در پورتفولیوی خود را با افزایش شدید سرمایه‌گذاری در دوره‌های ثانویه، بیشتر کنند.

لین اعتقاد دارد سرمایه‌گذارها بازگشت احتمالی سرمایه از سرمایه‌گذاری‌های سان را دست‌کم می‌گیرند. او در گزارشی در ابتدای سال جاری پیش‌بینی کرد که سوددهی خالص سرمایه‌گذاری اولیه‌ی ویژن فاند بین ۱۴ تا ۲۴ میلیارد دلار خواهد بود. درواقع بازگشت سرمایه‌ی ۱۵ تا ۲۰ درصدی پیش‌بینی شد. او همچنین بازگشت سرمایه برای دوره‌های کنونی و بعدی را بین ۵۰ تا ۸۵ میلیارد دلار پیش‌بینی کرد.

لین در مصاحبه‌ای پیرامون برنامه‌های جذب سرمایه‌ی سافت بانک گفت:

اولین گروه از سرمایه‌گذارها روی یک فرد و بینش او سرمایه‌گذاری کردند؛ اما ایده‌ی او هیچ‌گاه بررسی نشد. برای دومین دور جذب سرمایه می‌توانیم حقایق سرمایه‌گذاری و بازگشت سرمایه را ببینیم.

اپل کدهای مربوط به دو آیپد جدید با شماره مدل‌های A2200 و A2232 را در پایگاه کمیسیون اقتصادی اوراسیا (EEC) ثبت کرده است. در نتیجه انتظار می‌رود پاییز امسال شاهد معرفی دستگاه‌های جدیدی از سوی کوپرتینونشین‌ها باشیم.

باتوجه به اینکه هر دو دستگاه در یک فهرست مشترک قرار داده شده‌اند، احتمالا دستگا‌ه‌هایی با مشخصات مشابه یکدیگر خواهند بود. براساس شایعات منتشرشده پیرامون این دو دستگاه جدید، به‌نظر می‌رسد آیپد جدید ۱۰.۲ اینچی باشد که نسخه‌ی ارتقاءیافته‌ی آیپد ۹.۷ اینچی اپل خواهد بود.

ابتدای سال ۲۰۱۹، کوپرتیونشین‌ها، پنج مدل جدید آیپد با شما‌ره مدل‌های  A2197، A2228، A2068، A2198 و A2230 را نیز در پایگاه کمیسیون اقتصادی اوراسیا ثبت کردند. کمیسیون اقتصادی اوراسیا ادعا می‌‌کند که هر هفت مدل آیپد جدید اپل، پاییز امسال با نسخه‌ی سیستم‌عاملiPadOS 13 به بازار عرضه خواهند شد. 

براساس گزارش‌ منتشرشده از سوی رسانه‌های چینی،‌ تولید انبوه آیپدهای جدید اپل از ماه ژوئیه (‌اواخر مردادماه)‌ آغاز می‌شود.

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

هم‌زمان با ثبت پرونده‌ی مربوط به دو آیپد جدید در وب‌سایت EEC، پرونده‌ی دیگری نیز مربوط به شماره‌ی مدل مک‌بوک به ثبت رسیده است.

تا چند سال پیش، پورشه کیمن، پرچم‌دار خودروهای کوپه‌ی اسپرت با قیمت کمتر ۷۰هزار دلار بود ولی امروز اوضاع فرق کرده و بی‌ام‌و با مدل M2 Competition از راه رسیده است.

بی ام‌و M2 کامپتیشن در مقایسه با M2 معمولی دارای سیستم تعلیق مسابقه‌ای در عقب و جلو بوده و پیشرانه‌ی آن نیز متعلق به مدل M3 است که قدرت بالاتری دارد. کمک فنرهای M2 کامپتیشن هم پایداری بهتری را فراهم می‌کنند و سرعت پاسخگویی خودرو در پیچ‌ها بهتر از قبل شده است. 

بی‌ام‌و M2 کامپتیشن رقبای زیادی در بازار دارد اما الپین A110 یکی از جدیدترین رقبای پرسروصدای آن محسوب می‌شود. الپین A110 خودرویی است که مدت‌ها منتظر ورود آن به بازار بودیم. از نظر قیمتی، بی‌ام‌و M2 کامپتیشن و الپین A110 با هم رقیب هستند ولی مشخصات آن‌ها بسیار متفاوت است. شاید در نگاه اول این سؤال برایتان ایجاد شود که این دو خودرو چطور می‌توانند با هم مقایسه شوند. ابتدا بگذارید به مشخصات فنی دو خودرو بپردازیم. بی‌ام‌و از یک پیشرانه‌ی ۶ سیلندر خطی با حجم ۳ لیتر استفاده می‌کند که توانایی تولید ۴۰۴ اسب‌بخار قدرت و ۵۵۰ نیوتون‌متر گشتاور را دارد. جعبه‌دنده‌ی بی‌ام‌و از نوع ۷ سرعته‌ی دوکلاچ است. این کوپه‌ی ۱۶۲۵ کیلوگرمی آلمانی می‌تواند در ۴.۲ ثانیه به سرعت ۱۰۰ کیلومتربرساعت برسد و حداکثر سرعت آن ۲۵۰ کیلومتربرساعت است. 

رقیب فرانسوی از پیشرانه‌ی ۴ سیلندر ۱.۸ لیتری توربو به قدرت ۲۴۸ اسب‌بخار و گشتاور ۳۲۴ نیوتون‌متر استفاده می‌کند. جعبه‌دنده‌ی الپین A110 نیز از نوع ۷ دنده‌ی دوکلاچ است. قدرت و گشتاور الپین در مقایسه با بی‌ام‌و کم‌تر است ولی در نظر داشته باشید که این مدعی تازه‌وارد فرانسوی با وزن ۱۱۰۳ کیلوگرم، تقریبا نیم تن از بی‌ام‌و سبک‌تر است. سرعت‌گیری صفر تا صد کیلومتربرساعت الپین ۴.۵ ثانیه و حداکثر سرعت آن ۲۵۰ کیلومتر بر ساعت است. کمبود قدرت الپین را وزن کم آن جبران می‌کند؛ به همین دلیل در توانایی‌های حرکتی، دو خودرو بسیار نزدیک به هم هستند. 

پورشه در مدل ۷۱۸ کیمن به سراغ موتورهای ۴ سیلندر رفته ولی بی‌ام‌و همچنان به ۶ سیلندرها وفادار مانده است. فرمان بی‌ام‌و M2 کامپتیشن هم در مقایسه با پورشه ۷۱۸ و هم در مقایسه با آلپینا A110 سنگین‌تر است، ولی دقت فوق‌العاده‌ای دارد و بسیار راحت و خوب می‌توان با بی‌ام‌و تغییر مسیر داد. کنترل بی‌ام‌و فوق‌العاده است و تنها ایرادی که می‌توان به آن گرفت، مقداری خشک بودن سواری در جاده‌های پر دست‌انداز است. 

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

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

 امروز خودروهای بسیار کمی وجود دارند که در زمینه‌ی کنترل شاسی و دینامیک رانندگی با الپین A110 رقابت کنند. حس این خودرو هنگام عبور از پیچ‌ها واقعا رضایت‌بخش است. بی‌ام‌و هم به‌خوبی مزایای خودروهای دیفرانسیل عقب را از خود بروز می‌دهد. تمام چسبندگی چرخ‌های جلو در بی‌ام‌و در خدمت فرمان و تمام چسبندگی چرخ‌های عقب هم در خدمت نیروی پیشرانه است. قسیم وزن M2 کامپتیشن بسیار خوب است و در تمام سرعت‌ها می‌توان از رانندگی با آن لذت برد. 

موقعیت قرارگیری راننده در M2 کامپتیشن خیلی خوب نیست ولی در عوض صندلی‌های بسیار راحتی دارد. الپین هنگام رانندگی حس خودروهای کوچک را دارد و صندلی‌های اسپرت آن نیز حمایت بسیار خوبی از بدن سرنشینان به عمل می‌آورند.

پیش از نتیجه‌گیری در مورد برنده‌ی این رقابت باید اشاره کنیم که تویوتا سوپرا نیز مدعی جدید این کلاس است و جای خالی آن در این مقایسه کاملا حس می‌شد. هر دوی این خودروها می‌توانند شرایط بسیار سختی را برای پورشه ۷۱۸ کیمن ایجاد کنند. بی‌ام‌و M2 کامپتیشن خودرویی بسیار عالی و کم ایراد است ولی حسی مانند خودروهای عضلانی دارد؛ الپین خودرویی مناسب برای پیچ‌های تند است که به لطف تعادل بسیار خوب شاسی، در این رقابت برنده می‌شود.