مهاجرت از سیستم های سنتی به شیرپوینت - قبل، حین و پس از مهاجرت

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

 

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

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

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

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

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

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

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

  SQL Servers شیرپوینت (لاگ فایل‌ها)
حین مهاجرت، داده ها با سرعت بسیار زیاد در پایگاه داده‌های محتوا جای خواهند گرفت. بی‌تردید، اثر شمارۀ یک مهاجرت بر فارم شیرپوینت لاگ فایل‌های پایگاه داده های محتواست. اکثر به کاراندازی‌های شیرپوینت برای نرخ بار بالای مهاجرت طراحی نمی‌شوند. بدون برنامه‌ریزی درست، لاگ فایل‌ها طی مهاجرت پر خواهند شد. این می‌تواند موجب عملکرد نامنظم مهاجرت یا بروز خطا گردد و بر کاربران نهایی نیز تأثیرگذار خواهد بود.

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

2- حین مهاجرت
اکنون که فارم (farm)برای پذیرش حجم‌های بالای محتوا آماده است، در نظر گرفتن چند موردی که باید طی مهاجرت مدیریت شوند از اهمیت برخوردار است. به طور کلی، بسیار حیاتی است که مطمئن شویم کاربران نهایی تحت تأثیر قرار نمی‌گیرند. وقتی محتوا به شیرپوینت اضافه می‌شود، در اکثر شرایط، برای خزیدن (crawling) طی خزش (crawl) تدریجی، دائمی یا کامل ایجاد پرچم می‌کند (flagged). این می‌تواند مسئله ساز باشد، به خصوص هنگام انتقال محتوا به برنامۀ وب شیرپوینت که در آن کاربران نهایی نیز همکاری خواهند داشت. مثلاً، اگر کاربری سند جدیدی را در portal.acme.com با صدها یا هزاران سند در دقیقه آپلود کند، خزش تدریجی/ دائمی اضافه بار (overload) زیادی خواهد داشت. این بدان معناست که سند کاربر برای مدتی بسیار طولانی‌تر از معمول قابل دسترس نخواهد بود.

به طور  ایده آل، بهترین روش این است که محتوا به همان «منبع محتوایی» که کاربران نهایی در یک سیستم زنده از آن استفاده می‌کنند منتقل نشود. منبع محتوای جستجو در شیرپوینت تعیین می‌کند کدام آدرس‌های مبدأ از طریق زمان بندی یک خزش فرضی خزیده می‌شوند. نکتۀ آخر این که شما باید مهاجرت را به گونه ای طراحی کنید گویی که محتوا را در برنامۀ وب متفاوتی (یا احتمالاً میزبانی به نام مجموعۀ سایت) که در منبع محتوای کاملاً متفاوتی سرویس دهی می‌شود جای می‌دهید. برای مثال، اگر سایت گروهی (collaboration site) "portal.acme.com" باشد، شاید بتوان محتوای منتقل شده را در "archive.acme.com" جای داد.

از آنجایی که اکنون داریم محتوای مهاجرت را در archive.acme.com جا می‌دهیم، می‌توانیم زمان بندی خزش را فقط برای آن منبع محتوا کنترل کنیم. به طور ایده آل، خزش طی مهاجرت باید کاملاً قطع شود. این بدان دلیل است که زیرسیستم خزش با محتوای «تغییریافته/ جدید» بار اضافی خواهد گرفت. این امر در نهایت به پنهان شدن محتوای کاربر نهایی در محتوای مهاجرت منجر می‌گردد. با قطع همۀ خزش ها برای محتوای منتقل شده، زیرسیستم خزش می‌تواند بر خزیدن محتوای تغییریافته/ جدیدی که کاربران نهایی ارائه می‌دهند، متمرکز شود.

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

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

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

گات چک (Gut check)
حواستان به محل‌های مقصد برای همۀ محتوایتان باشد. آیا تعداد کل اسناد منطقی است؟ کتابخانه‌ها را ناوش کنید. آیا محتوا را می‌بینید؟ گاهی پس از انتقال محتوا به نظر می‌رسد چیزی در کتابخانه‌ها موجود نیست. مثلاً، این امر وقتی اتفاق می‌افتد که یک فیلد ضروری داده‌ها را نمی‌گیرد. شیرپوینت سند را پذیرش خواهد کرد اما سند در حالت "checked out" باقی خواهد ماند. این بدان معناست که دیگر حساب‌های کاربری نمی‌توانند محتوایی که حساب سرویس مهاجرت در حال استفاده هستند را ببینند.

متریک‌های منبع
حواستان به بهره برداری از سی پی یو، استفاده از حافظه (RAM موجود در مقابل Paged RAM)، فضای دیسک موجود و دیسک I/O باشد. دیسک I/O می‌تواند با نظارت بر میانگین طول صف دیسک (ADQL) برای حجمی که پایگاه داده های محتوا در آن، محتوا را روی SQL Server ذخیره می‌کند کنترل گردد. ADQL باید در دامنۀ ده دهی قرار داشته باشد. اگر در ارقام فرد باشد، احتمالاً به درستی کار می‌کند. اگر در ارقام بالای دودویی، ارقام سه تایی یا حتی ارقام
چهارتایی باشد، به شدت لطمه خواهید خورد. چرخاننده های دیسک (disk spindles) شما به قدر کافی سریع نیستند که با نرخ بار شما هماهنگ باشند. علاوه بر با مانع روبرو شدن مهاجرت، I/O دیسک شما بر کاربران نهایی نیز اثر می‌گذارد. اگر هر یک از این متریک‌ها به شدت نامتوازن باشند، مهاجرت نابود خواهد شد.

3- بعد از مهاجرت
بعد از کامل شدن مهاجرت، کارهای متعددی وجود دارد که باید پیش از پرداختن به داده‌های «زنده» (live) اجرا گردند.

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

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

از کاربران کسب‌وکار خود بخواهید محتوای انتقال داده شده را مرور کنند
مهاجرت تنها وقتی «رسماً» موفق می‌شود که کسب‌وکار موفقیت آمیز بودن آن را تایید کند. کاربران کسب‌وکار محتوا را بهتر از هرکس دیگر می‌شناسند. آن‌ها این توانایی را دارند که به محتوای منتقل شده نگاه کنند و بفهمند که موردی اشتباه است یا نه.

خزش ها را روشن کنید
حالا زمان پیکربندی زمان‌بندی خزش کامل است، یک خزش کامل را حرکت دهید و سپس خزشهای تدریجی/ دائمی را (در همان دستور) پیکربندی کنید. شما می‌خواهید که خزش کامل شروع شود. خزش تدریجی روی ده ها هزار، صدها هزار یا میلیون‌ها سند کمتر از حادثه ای دردناک در خزش سرورها نیست اما خزش کامل برای ادارۀ بار منبع محتوای خامی که قبلاً نخزیده بود طراحی می‌شود.

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

ارسال نظر

آخرین نظرات

Comment RSS