تبلیغات
computerkomak

computerkomak

سه شنبه 10 مرداد 1396


۴ راه برای غیر فعال کردن آپدیت ویندوز

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

Notify for download and notify for install: اطلاع‌رسانی پیش از دانلود و نصب آپدیت‌ها.

Auto download and notify for install: دانلود خودکار دانلودها و اطلاع‌رسانی پیش از نصب آن‌ها.

Auto download and schedule the install: دانلود خودکار دانلودها و برنامه‌ریزی جهت نصب آن‌ها.

سپس بر روی دکمه‌ی OK کلیک نمایید.

 

۴ راه برای غیر فعال کردن آپدیت ویندوز

اکنون در صورتی که به Windows Update ویندوز مراجعه کنید و روی Check for updates و سپس Advanced options کلیک کنید با پیامی قرمزرنگ مبنی بر تغییر یافتن تنظیمات آپدیت ویندوز روبه‌رو خواهید شد.

 


۴ راه برای غیر فعال کردن آپدیت ویندوز در حال کار

غیرفعال کردن آپدیت خودکار ویندوز ۱۰ از طریق رجیستری
این روش از طریق ویرایش‌گر رجیستری ویندوز صورت می‌پذیرد و در کلیه‌ی نسخه‌های ویندوز ۱۰ به جز نسخه‌‌‌ی Home امکان‌پذیر است. ابتدا کلیدهای ترکیبی Win+R را فشار دهید.در پنجره‌ی Run عبارت regedit را وارد نموده و Enter بزنید.

در پنجره‌‌‌ی Registry Editor به مسیر زیر بروید:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
اکنون در محدوده‌ی فضای خالی سمت‌ راست پنجره، راست‌کلیک کرده و از منوی New گزینه‌ی DWORD (32-bit) Value را انتخاب نمایید. نام این مقدار جدید را AUOptions را قرار دهید.اکنون بر روی AUOptions دوبارکلیک کنید و در پنجره‌ی باز شده، در قسمت Value بر اساس یکی از موارد زیر مقدار دلخواه خود را وارد نمایید:۱: اطلاع‌رسانی پیش از دانلود و نصب آپدیت‌ها.۲: دانلود خودکار دانلودها و اطلاع‌رسانی پیش از نصب آن‌ها.۳: دانلود خودکار دانلودها و برنامه‌ریزی جهت نصب آن‌ها. سپس بر روی دکمه‌ی OK کلیک نمایید. شما می‌توانید به جای تغییر دستی در رجیستری، فایل‌های رجیستری ازپیش‌ساخته‌شده‌ جهت تغییر تنظیمات آپدیت ویندوز را از اینجا دانلود نمایید و هر کدام را به دلخواه خود اجرا نمایید.

غیرفعال کردن آپدیت خودکار ویندوز ۱۰ از طریق سرویس Windows Update
این کار از طریق غیرفعال کردن سرویس Windows Update در ویندوز ۱۰ صورت می‌گیرد. این روش منجر به غیرفعال شدن کامل دریافت خودکار آپدیت‌ها در ویندوز ۱۰ می‌گردد. بدین منظور ابتدا کلیدهای ترکیبی Win+R را فشار دهید.در پنجره‌ی Run دستور services.msc را وارد نموده و Enter بزنید.

اکنون در پنجره‌ی Services، سرویس Windows Update را یافته و بر روی آن دوبارکلیک کنید.سپس بر روی دکمه‌ی Stop کلیک کرده و Startup type را نیز بر روی Disabled تنظیم نمایید.در نهایت بر روی OK کلیک کنید.با توجه به این که روش منجر به غیرفعال شدن کامل آپدیت‌های خودکار (حتی آپدیت‌‌های ضروری و امنیتی) می‌شود پیشنهاد می‌کنیم از انجام آن اطمینان حاصل کنید.

  • نظرات() 
  • سه شنبه 10 مرداد 1396

    اسکن پورت های باز یک آیپی در شبکه

    ۳٫ Free IP Scanner
    این برنامه برخلاف مورد بالا، آیپی های مختلف را بدون چک کردن پورت انجام میدهد. یعنی شما رنج آیپی هایی که میخواید فعال بودنشان چک شود را وارد میکنید و این برنامه خاصیت های IP Address و Workgroup Name و Host Name و User و Mac Address را کاوش میکند.
    خب از ویژگی های این برنامه میتوان به سبک بودن و راحت بودن کار با آن را ذکر کرد.





    یافتن آیپی های موجود در شبکه محلی با سرعت بالا

    ۴٫ Advanced IP Scanner
    نرم افزاری سریع و آسان برای اسکن و یافتن آی پی آدرس های کامپیوتر ها و دیگر دستگاه های شبکه است.
    این نرم افزار قادر به اسکن سریع تمام کامپیوتر ها/پورت های شبکه های لوکال معمولی (باسیم) و یا وایرلس (بدون سیم) می باشد. Advanced IP Scanner دسترسی سریع و آسان به منابع شبکه های مختلف، از جمله HTTP، HTTPS، FTP و پوشه های به اشتراک گذاری شده(Shared) را فراهم می کند و همچنین امکانی برای تشخیص تمام دستگاه های شبکه، از جمله دستگاه های بی سیم و روتر های Wi-Fi را به کاربرانش ارائه می دهد.

    از قابلیت های کلیدی نرم افزار Advanced IP Scanner میتوان به موارد زیر اشاره کرد:
    – اسکن سریع شبکه کامپیئتری
    – سازگاری با نرم افزار Radmin remote control
    – امکان دسترسی آسان به منابع شبکه (مانند HTTP، HTTPS، FTP و پوشه های به اشتراک گذاری شده)
    – تشخیص تمام دستگاه های شبکه
    – امکان خاموش کردن Remote PC
    – اجرای دستورات بر روی یک ریموت کامپیوتر

    برنامه حرفه ای یافتن آیپی ها و فولدرهای شیر باز

     

     

    • نتیجه گیری:

      به نظر من بهترین و سبک ترین و کارآمد ترین برنامه برای استفاده متخصصین و کاربران جهت آنالیز شبکه محلی، برنامه اول یعنی Angry Ip Scanner میباشد که هم سرعتش بالاست و هم کیفیت و کارش درسته.
      البته اگر بررسی فولدرهای Shared مدنظر شماست و به آنالیز با دقت بیشتر نیاز دارید برنامه آخر یعنی Advanced IP Scanner کار شما را بهتر راه میندازد.

  • نظرات() 
  • یکشنبه 3 اردیبهشت 1396

    زمانیکه شما یک Server Farm دارید و در آن از Load Balancer استفاده می کنید و یکی از سرورها از مدار خارج شده و دیگر سرویس نمی دهد ، Load Balancer بصورت خودکار سرور مورد نظر را از مدار خارج نگه داشته و تمامی درخواست های جدیدی که به Load Balancer وارد می شوند به سایر سرورها هدایت می شوند و دیگر مستقیما به سمت سرور از مدار خارج شده هدایت نمی شوند. برای اینکه حالت های پیشرفته تری از Load Balancing را داشته باشیم و مطمئن شویم که درخواست های کاربران به درستی به Application هایی که در سرورها نصب شده اند می رسد Load Balancer ها از مکانیزمی به نام ADC که مخفف Application Delivery Controller به معنی کنترل کننده رسید درخواست های نرم افزارهای کاربردی ( ترجمش واسه خودش سوژه ای هست ) استفاده می کند که باعث بالا رفتن کارایی ، امنیت ، انعطاف پذیری در سرویس دهی application های تحت وب درون سرورها می شود. در واقع ADC فقط یک Load Balancer نیست ، این مکانیزم می تواند پلتفرمی برای اطمینان از دریافت شدن و رسیدن بسته های اطلاعاتی در شبکه ها ، بالا بردن سرویس های تحت وب در application های تحت وب و موبایل و همچنین امن ترین و مطمئن ترین روش برای دسترسی پذیری سرویس ها در نقاط جغرافیایی مختلف را فراهم می کند ، در ADC محل قرار گیری سرور و زمان و نحوه دسترسی تفاوت زیادی در نحوه سرویس دهی نخواهند داشت.

    روش کاری Load Balancer ها


    الگوریتم ها و روش های انجام Load Balancing در Load Balancer
    تجهیزات و نرم افزارهای Load Balancer از الگوریتم های مختلفی برای اینکار استفاده می کنند که به آنها Method ها یا روشهای Load Balancing گفته می شود ، این الگوریتم ها برای استفاده در ADC کاربرد دارند و وظیفه آنها این است که بهترین سرور و مناسب ترین سرور را برای ارسال درخواست کاربر و هدایت درخواست به سمت سرور انتخاب کنند ، در این خصوص الگوریتم ها یا Method هایی به شکل زیر در حال حاضر وجود دارند که این وظیفه را بر عهده دارند :

        روش کمترین تعداد Connection : در این روش که روش پیشفرض در بسیاری از Load Balancer ها است سروری که کمترین تعداد Connection فعال بر روی آن وجود دارد درخواست های جدید کاربران را دریافت خواهد کرد.
        روش Round Robin : در این روش سرورها به ترتیب در Load Balancer مثل یک دایره لیست می شوند ، هر بار که درخواستی به سمت Load Balancer می آید به ترتیب لیست و ترتیب بین سرورها درخواست ها را تقسیم می کند ، به محض اینکه درخواستی به Load Balancer برسد به اولین سرور موجود در لیست ارجاع داده می شود و سرور بعد از دریافت کردن درخواست به آخر صف می رود و منتظر می ماند که همه سرورها درخواست بگیرند تا نوبت به سرور مورد نظر برسد.
        روش کمترین زمان پاسخ یا Least Response Time : در این نوع روش سروری که کمترین تعداد connection فعال را به همراه کمترین زمان پاسخگویی به درخواست دارند شناسایی و درخواست از طریق Load Balancer به سمت آن هدایت می شود.
        روش کمترین پهنای باند یا Least Bandwidth : در این روش سروری که کمترین استفاده از پهنای باند موجود در لینک ها را دارند بر اساس معیار مگابیت بر ثانیه شناسایی شده و درخواست به سمت آن هدایت می شود.
        روش کمترین تعداد Packet یا Least Packets : در این روش سروری که کمترین تعداد Packet در طی وهله های زمانی معین را دارد شناسایی و درخواست ها به سمت آن هدایت می شود.
        روش Load دلخواه یا Custom Load : در این روش Load Balancer سرورهایی که کمترین تعداد یا اینکه هیچ تعداد connection و درخواست فعال ندارند را شناسایی کرده ، اگر همه سرورها درگیر سرویس دهی به connection های کاربران باشند سروری که کمترین تعداد connection فعال بر روی آن وجود دارد را وارد مدار و درخواست ها را به سمت آن هدایت می کند.


    روشهای مختلف Load Balancing


    از Load Balancer در چه زمانی استفاده می شود ؟
    همه روزه ترافیک شبکه های عمومی بسیار زیاد و زیادتر می شود تعداد درخواست ها نیز به همین ترتیب همه روزه در حال رشد هستند ، شبکه ها هر روز پیچیده تر و پر ترافیک تر می شوند. Load Balancer ها به شما این امکان را می دهند که کارایی و امنیت مرتبط با سرویس دهی در حوزه ترافیکی شبکه خودتان را در حوزه application ها تضمین کنید ، یکی از مواردی که خیلی از Load Balancer ها می توانیم استفاده کنیم در سرویس های بانکی است که امروزه در اکثر بانک های ایران از تجهیزات Load Balancer از نوع F5 استفاده می شود. امیدوارم مورد توجه شما قرار گرفته باشد. ITPRO باشید

  • نظرات() 
  • یکشنبه 3 اردیبهشت 1396


        Replication بین چندین سایت برای انتقال Domain directory partition, زمانیکه DC های یک دومین در چندین سایت قرار دارند. همچنین اگر بیش از یک سایت داشته باشیم Replicate کردن Schema and configuration directory partition برای همه سایتها لازم و ضروری می باشد. Replication بین چند سایت از طریق Bridgehead server ها انجام می شود. هر سروری که یک Connection objet از DC های دیگر سایتها داشته باشید بعنوان Bridgehead server مشخص می شود. همچنین با دستور زیر می توانید Bridgehead server های هر سایت را مشخص کنید:

        repadmin /bridgeheads

        KCC دومین کنترولری را به عنوان Bridgehead انتخاب می کند که بتواند تمام Directory partition ها بعلاوه partial global catalog partitions را از دیگر سایتها Replicate کند. بصورت پیش فرض KCC بر روی DC ی که ISTG روی آن فعال باشد شروع به انتخاب Bridgehead server ها می کند. سرور های که نقش GC بر روی آنها فعال می باشد اولویت آنها برای BH زیادتر از بقیه DC ها می باشد.
        ترافیک Replicate شده بین سایتها فشرده سازی می شود.ولی این مسئله دورن یک سایت صدق نمی کند.
        بصورت پیش فرض همه سایت لینکها قابلیت تعدی یا Transitive هستند که این قابلیت را بصورت مفصل اینجا توضیح دادم.
        وقتی قابلیت Transitive بر روی همه site linkها فعال باشد KCC میتواند مسیر replicate را تعقیر دهد و connectionهای لازم را ایجاد کند. تصویر زیر را ببینید:

        در صورت Down شدن BH سرورهای سایت Seattle پروسه KCC مسیر Replicate را تعقیر و کانکشنهای لازم با دو سایت Portland and Boston را ایجاد می کند.توجه کنید این پروسه در صورتی موثر می باشد که همه سایتها full route باشند و Transitive. پروسه KCC بوسیله مقدار Cost مسیر replication را تعیین می کند. برای درک این موضوع تصویر زیر را ببینید:

    Image

    دو عدد سایت لینک که سه سایت را به همدیگر وصل کرده اند و قابلیت Transitive بر روی سایت لینکها فعال می باشد. برای اینکه سایت Portland and Boston بتوانند بصورت مستقیم با همدیگر Replicate کنند ISTG مقدار Cost دو سایت لینک را جمع می کند و حاصل آن می شود مقدار Cost لینک (مجازی یا منطقی) بین دو سایت Portland and Boston . در نتیجه DC3 یک Connection object با DC2 و بلعکس ایجاد می کند.
    (اینجا را با دقت بخوانید و درک کنید)
    ولی صبر کنید سه سایت بالا Directory Partition یکسانی دارند (همه DC ها در یک دومین فعالیت می کنند) پس در نتیجه ISTG بجای ایجاد یک Site link مجازی از سایت لینک PS که دارای Cost کمتری می باشد استفاده می کند و بوسیله متد Store-and-Forward بهره می برد و Replication را بوسیله DC های سایت Seattle ارسال و دریافت می کند. ولی اگر سایت Seattle دومین جداگانه ای باشد یا BH سرورهای سایت Seattle در دسترس نباشند یک Site link مجازی بین Portland and Boston ایجاد می شود.
    نکته: تمام پروسه (ساختار را بصورت Full Route در نظر بگیرید) بالا در صورتی امکان پذیر می باشد که سایت لینکها Bridge or Transitive باشند.
    نکته: برای اینکه پروسه بالا با موفقیت اجرا شود باید زمان بندی و دفعات Replication در دو سایت لینک PS and SB یکسان باشند.
    نکته: اگر قابلیت Bridge بر روی این دو سایت لینک غیرفعال باشد هرگز سایت لینک مجازی بین سایتهای Portland and Boston ایجاد نمی شود. و شما باید یک Site link bridge بصورت دستی ایجاد کنید.
    یک سوال خیلی مهم و کاربردی: چه زمانی ما باید یک Site link bridge بصورت دستی ایجاد کنیم؟؟؟
    زمانی که ساختار ما non-full route باشند و Domain directory partition مربوط به یک دومین در چند سایت مختلف نگهداری می شود. به عبارت دیگر DC های یک دومین در چند سایت مختلف می باشند. تصویر زیر را ببینید:
    Image

    بریم سراغ نحوه عملکرد پروسه KCC:

        پروسه KCC هر 15 دقیقه کل توپولوژی را چک می کند و توپولوژی مورد نظر را ایجاد یا تعقیر می دهد.
        بصورت پیش فرض اولین فعالیت KCC 5 دقیقه بعد از استارت شدن DC می باشد. اگر DC دارای سرویس های DHCP-WINS و غیره باشد این مدت زمان افزایش می یابد. این مدت زمان از طریق Registry قابل تعقیر می باشد.

    KCC در دو مرحله توپولوژی را ایجاد می کند:
    Evaluation:در این فاز KCC با استفاده از اطلاعات موجود در DC ساختار را ارزشیابی می کند و طبق این اطلاعات Connection object ها را ایجاد یا حذف می کند.
    Translation: در این فاز طبق ارزشیابی وتصمیماتی که KCC در مرحله قبلی انجام داده توپولوژی را ایجاد می کند. در این مرحله KCC یک صفت RepsFrom برای هر DC ایجاد می کند که برای Intra-site topology لازم می باشد یا بر روی Bridgehead server ها این صفت را ایجاد می کند. (برای Inter-site topology)
    محدوده و مدهای فعالیت KCC:
    Image

    وقتی KCC توپولوژی را محاسبه میکند دو نوع replication را لحاظ می کند یکی Writable or read-only Replication که برای هر کدام از آنها قوانینی وجود دارد:

        writable replica بروزرسانی ها را فقط از writable replica دریافت می کند.
        Read-only replica می تواند بروز رسانیها را از writable replica دریافت کند.
        Read-only replica همچنین می تواند ابدیتها را از Read-only replica دریافت کند.
        writable replica هرگز بروزرسانیها را از یک Read-only replica دریافت نمی کند.

    KCC برای هر یک از Directory partition ها دو نوع توپولوژی محاسبه می کند. یکی برای Writable replica و یکی برای read-only replica. که این محاسبات تحت شرایطی منجر به ایجاد یک Connection object اضافی برای read-only replica می شود.
    شاید بعضیا تفاوت این دو مد را با هم ندانند که توضیح میدم. بعضی از Directory partition ها بصورت کامل بین DC های یک فارست Replicate می شود مانند Schema, configuration و هر یک از DC ها سه نوع پارتیشن را بصورت کامل دریافت می کنندSchema, configuration و Domain partition مربوط به دومین خود (دومین معتبر) به این نوع ریپلیکیشن Writable replica می گویند. در بعضی از DC ها نقش GC فعال می باشد GC علاوه بر پارتیشن های بالا نیاز به Domain directory partition بقیه دومین های فارست دارد. ( GC تمام اطلاعات Domain partition بقیه دومین ها را دریافت نمی کند بلکه Attribute های محدودی از همه ابجکتها را (که در Schema قابل تعیین می باشد که به لیست PAS معروفه) دریافت می کند که به این نوع Replication بین دو GC میگن Read-only Replica. همچنین پارتیشنی که بین GC ها Replicate می شود Read-only می باشد. در تصویر زیر یک سایت با چهار دومین مختلف مشاهده می کنید. بر روی یکی از DC های دومین A نقش GC فعال می باشد. Replicate بین DC ها بدین شکل می باشد:
    Image

    نکته مهم: اگر یک DC بعد از چند با سعی کردن نتوانست جوابی از DC مقابل دریافت کند و این روال تا دو ساعت همچنان باقی بماند KCC فرض را بر غیر قابل دسترس بودن این DC میگذارد. و توپولوژی را دوباره محاسبه می کند و Connection object آن DC را پاک و یک Connection object جدید ایجاد و یک DC جدید انتخاب می کند.

        Replication برای ارتباط در یک یا چندین سایت بصورت پیش فرض از RPC استفاده می کند. RPC برای عملکرد خود از پورتهای تصادفی استفاده می کند. در جدول زیر پورتهای لازم برای Replication را می بینید:

    Image

    در سناریوهای که بین کلاینتها و DC فایروالی وجود دارد شما باید این پورتها را در مد Fixed تنظیم کنید. برای اینکار از گوگل استفاده کنید.
    در این مقاله روش ایجاد توپولوژی در Intra-site and Inter-site را بصورت مفصل توضیح ندادم (گرچه در مقاله های آتی به آن اشاره خواهم کرد) ولی شما می توانید این قسمتها را در لینک زیر مطالعه کنید.

    منبع مقاله قبلی واین مقاله لینک زیر می باشد:
    How Active Directory Replication Topology Works

    https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx#w2k3tr_repto_how_ludi

  • نظرات() 
  • یکشنبه 3 اردیبهشت 1396

    اینبار بصورت کاملا متفاوت می خواهیم این پروسه جذاب وپیچیده را با هم یاد بگیریم.

        برای انتقال داده ها درون یک دومین یا یک فارست و همچنین Sync کردن پارتیشن های Forest-wide در یک فارست اکتیو دایرکتوری از Replication استفاده می کند.
        برای اینکه پروسه Replication بتواند این اطلاعات را بصورت بهینه دورن یک سایت یا بین سایتها منتقل کند یک توپولوژی ایجاد می کند.
        Replication topology توسط KCC یا Knowledge Consistency Checker بر روی یک Domain Controller ایجاد می شود.
        KCC برنامه ای می باشد که شامل اجزای مختلفی هستش و بر روی هر یک از DC ها عمل می کند. کانفیگ و مدیریت Replication توسط KCC انجام می شود.
        KCC بصورت جداگانه بر روی DC ها فعالیت می کنند و هیچ ارتباطی با دیگر DC ها ندارند. در نتیجه آنها باید از یک الگوریتم ثابت و به همراه داده های که در Schema and * Configuration Partition ذخیره شده است استفاده کنند و توپولوژِی خود را ایجاد کنند.
        برای اینکه KCC بتواند Replication topology را ایجاد کند از اطلاعات ساختار اکتیودایرکتوری استفاده میکند. این اطلاعات را از پارامترهای زیر بدست می آورد:
            سایت
            سرورها
            سایتهای وابسته به هر یک از سرورها
            گلوبال کاتالوگ
            Directory partition های ذخیره شده بر روی سرور
            سایت لینک ها
            Site link Bridge
        برای اینکه KCC بتواند از اطلاعات ذخیره شده بر روی هارد دیسک DC و پارتیشنهای دایرکتوری سرویس استفاده کند از Directory System Agent استفاده می کند. DSA دسترسی KCC به اطلاعات مهم برای ساختن Replication topology را مسیر می کند.
        KCC می تواند برای ایجاد Replication topology داده های (مربوط به Replication) را ایجاد، تعقیر یا حذف کند.
        KCC در صورتی با دیگر DC ها ارتباط برقرار می کند که به دنبال Replication error باشند. KCC از این پروسه برای عیب یابی Replication استفاده می کند. یادتون باشه Replication error فقط درون یک سایت اتفاق می افتد.
        KCC برای ارتباطات خود از پروتکل RPC استفاده می کند نه پروتکل LDAP
        برای اینکه ترافیک Replication بین DCهای یک سایت یا چندین سایت جریان داشته باشد KCC و ISTG کانکشن ایجاد می کنند. این کانکشنها را Connection object می نامند.
        قبل از اینکه Connection object ها ایجاد شوند باید DC مبدا و DC مقصد مشخص شود. بعد از مشخص شدن این دو پارامتر Connection objectها ایجاد خواهند شد.
        یکی از اجزای KCC که خیلی هم مهم می باشد ISTG یا Intersite Topology Generator نام دارد که وظیفه آن ایجاد connection object های مناسب بین Bridgehead server ها برای ایجاد Replication بین سایتها می باشد. ISTG علاوه بر وظیفه فوق وظیفه انتخاب Bridgehead server و مدیریت Replication بین سایتها را بر عهده دارد.
        Bridgehead server ها نمایندگان هر سایت می باشند که وظیفه Replication کردن تعقیرات سایت با سایتهای دیگر می باشد و همچنین تعقیرات ایجاد شده توسط سایتهای دیگر را دریافت می کنند و به DC های سایت خود منتقل می کنند.
        ISTG فقط بر روی یکی از DC ها در کل سایت اجرا خواهد شد و یک دید کلی از کل DC های درون یک Forest را ایجاد می کند.
        محدوده فعالیت KCC فقط بر روی یک DC می باشد ولی محدوده عملکرد ISTG کل یک سایت.

    Image

        بصورت خیلی ساده و خلاصه شده ESE جدولی می باشد که روند عملکرد یک سرویس را ردیابی می کند و بصورت Log file این رویدادها را در دیتابیس خود ذخیره می کند.
        در تصویر بالا چهار DC مشاهده می کنید که چون همه از یک الگوریتم و یک پارتیشن سراسری (Configuration Directory Partition) استفاده می کنند یک Topology کلی برای خود ایجاد کرده اند.
        DC های که Intrasite Replication Topology را ایجاد می کنند همیشه خود را به عنوان DC های مبدا ست می کنند. و DC های دیگر DC های مقصد ترافیک Replicate را از DC های مبدا درخواست می کنند.

    دو نوع Topology داریم:

        Intra-site topology
        Inter-site topology

        به Replication ی که درون یک سایت انجام می شود Intra-site replication می گویند. و Replicationی که بین سایتها اتفاق می افتد را Inter-site replication می نامند. replication topology درون یک سایت توسط KCC ایجاد می شود. و Inter-site topology توسط ISTG ایجاد می شود.
        KCC توپولوژی درون یک سایت را همیشه بصورت Ring ایجاد می کند. و ISTG یک دید کلی از کل Bridgehead Server های سایتهای دیگر ایجاد میکند.

    Image

    بعضی از اجزای KCC برای اجرای Replication موفقیت امیز، ضروری هستن بعضی از انها ضروری نیستند و فقط برای بهینه سازی این ارتباط بکار می روند. ساختار زیر را با دقت نگاه کنید:
    Image

        در تصویر بالا همه ی سرورها Domain controller هستند. همه ی آنها بصورت مستقل از اطلاعات دایرکتوری سرویس استفاده می کنند و Connection object های خود را ایجاد می کنند. KCC توپولوژی Intra-site را بین DC های یک سایت ایجاد می کند. و ISTG توپولوژی بین سایتها را نیز ایجاد می کند. درون یک سایت همه DC ها بصورت Ring تعقیرات خود را Replicate می کنند. و ISTG توپولوژی Inter-site را توسط Bridgehead Server ها ایجاد میکند.
        هر سایت در تصویر بالا نمایانگر محدوده فعالیت فیزیکی یک شبکه یا یک شعبه از یک کمپانی بزرگ می باشد که در آنها ارتباطات سرویس ها با یکدیگر حداقل با سرعت 10 Mbps می باشد. ما این محدوده را توسط شیء به نام Siteدر ساختار دایرکتوری سرویس ایجاد می کنیم. ما این سایتها را توسط یک ارتباط پر سرعت مانند Wireless یا MPLS با هم دیگر وصل می کنیم. در ساختار دایرکتوری ما این لینک ارتباطی را بوسیله شیء به نام Site link مشخص می کنیم. Site link ها به Bridgehead server هر سایت اجازه ارتباط با دیگر Bridgehead server ها را می دهد.
        Replication بین سایتها توسط پروتکل RPC انجام می شود. همچنین این پروتکل داخل یک سایت هم استفاده می شود. در تصویر بالا مشاهده می کنید که لینک ارتباطی بین سایت A and D پروتکل SMTP می باشد این پروتکل مانند پروتکل RPC برای Replicate کردن:
            Configuration Directory Partition
            Schema Directory Partition
            Global Catalog read-only, partial
            read-only directory partitions
        استفاده می شود.این پروتکل برای Replication کردن writable domain directory partitions,ها استفاده نمی شود. این پروتکل برای مواقعی استفاده می شود که ارتباط TCP/IPبا سایت مقصد وجود نداشته باشد یا Site link قابل اعتماد نمی باشد.
        بصورت پیش فرض Site link A-B and A-C بصورت transitive هستند (bridged) بدین معنی که بدون Site link بین سایت B and C ترافیک Replicationبین این دو سایت از طریق سایت A جریان دارد. هر Site link یک پارمتر به نام Cost دارد که ISTG از این پارامتر برای تعین بهترین مسیر برای Replication استفاده می کند. در تصویر بالا مقدار Cost که بر روی Site link A-B and A-C وجود دارد با هم دیگر جمع می شوند و حاصل آن بعنوان یک مسیر ترجیح داده شده برای سایتهای B and C تلقی می شود. در نتیجه Replication بین سایت B and C بصورت اتوماتیک از طریق سایت A به همدیگر Route می شود. در صورتی این دو سایت با هم دیگر بصورت مستقیم Replicate می کنند (با ایجاد Connection object) که Bridgehead server های سایت A در دسترسی نباشند یا متعلق به دومین دیگری باشد.

    KCC به منظور اهداف زیر Replication topology را ایجاد می کند:

        متصل کردن Directory Partition های یکسان و سینک کردن انها.
        کنترول زمان تاخیر Replication بین سایتها
        مسیر Replication بین سایتها.
        بهبود در Log on کردن کلاینتها.

        بصورت پیش فرض Replication Topology بصورت اتوماتیک توسط KCC and ISTG ایجاد می شود. ولی ادمین می تواند آن را بصورت دستی ایجاد کند یا تعقیر دهد که اولویت با تعقیرات ایجاد شده توسط ادمین می باشد.
        یک Replication topology در واقع شامل چندین Replication topology اساسی می باشد. این توپولوژی ها بر اساس Directory partition ها ساخته می شوند. مثلا Schema and Configuration directory partition از یک توپولوژی استفاده می کنند و Application directory partition از یک توپولوژی جداگانه. و همچنین Domain directory partition از یک توپولوژی جداگانه. بعضی از این توپولوژی ها با هم دیگر ادغام می شوند و از کانالهای ارتباطی (connection object) استفاده می کنند و با تمام DC های که داده های یکسانی را نگهداری می کنند Replicate می شوند. به عنوان مثال Configuration and Schema directory partition بر روی همه DC های Forest یکسان می باشد.

    نکته: اگر Domain controller ها Replica ی هم دیگر هستند (DC های یک دومین) برای Replication کردن Directory partitionها از یک Connection object استفاده می شود.
    همانطور که اشاره کردیم برای هر یک (یا هر چند) از Directory partition ها یک توپولوژی متفاوت ایجاد می شود. در بعضی از حالات Schema and Configuration Directory partition و Application Partition از همان توپولوژی استفاده می کنند که Domain directory partition استفاده می کند.
    نکته: در شرایطی که Application and domain directory partition در DC مبدا و DC مقصد یکسان باشند KCC برای Application partition یک Connection object جداگانه ای ایجاد نمی کند.
    حتما به این نتیجه رسیدید که Connection object ها بر اساس Topology ها ایجاد می شوند. افرین به شما که به نتیجه درستی رسیدید.
    نکته: هرگز برای partial replicas که در Global catalog ذخیره می شوند توپولوژی جداگانه ای ایجاد نمی شود. در نتیجه GC از Connection object های توپولوزی های دیگر استفاده می کند.
    برای اینکه KCC یا ISTG بتواند توپولوژی یا توپولوژی های نهائی را ایجاد کند مسیرهای ارتباطی directory partition های زیر را جمع بندی می کند:

        Configuration and schema within a site.
        Each writable domain directory partition within a site.
        Each application directory partition within a site.
        Global catalog read-only, partial domain directory partitions within a site.
        Configuration and schema between sites.
        Each writable domain directory partition between sites.
        Each application directory partition between sites.
        Global catalog read-only, partial domain directory partitions between sites.

    قضیه تاخیر یا Latency بین سایتها را می توانید در این مقاله مطالعه کنید.
    همچنین بهبود در Log on کردن کلاینتها را میتوانید اینجا مطالعه کنید.
    اکتیودایرکتوری اطلاعات مربوط به Replication topology را در Configuration directory partition ذخیره می کند.
    برای اینکه KCC و ISTG بتوانند بهترین ومتناسبترین توپولوژِی ساختار دایرکتوری سرویس را ایجاد کنند نیاز به کمک شما دارند. عاره شما دوست عزیز :) بعضی از پارامترها را باید به این دو پروسه معرفی کنید تا بدونن چطور توپولوژی را ایجاد کنند. مایکروسافت کنسول AD Site and Services را برای این منظور ایجاد کرده است.
    Image

        شیء Site در کنسول بالا نشان دهنده یک یا چند Subnet می باشد که درون یک سایت استفاده می شوند ، زیر مجموعه Site کانتینری به نام Server وجود دارد که DC های آن سایت را مشخص می کند.
        شیء Subnet سگمنتهای TCP/IP می باشند که به کلاینتهای آن سایت تعلق دارد. همچنین از این شیء برای مشخص کردن محدوده فعالیت کلاینتها استفاده میشود. ادرس هر کلاینت نماینگر سایت آن کلاینت می باشد.
        شیء Subnet به شیء Site مپ می شود. در پروسه Domain controller location کلاینتها از شیء Subnet and Site استفاده می کنند و DC های آن سایت یا سایت نزدیک را پیدا می کنند.
        بصورت پیش فرض وقتی Active Directory را نصب می کنید هیچگونه Subnetی ایجاد نمی شود و اگر در یک ساختار چندین سایت داشته باشید و Subnetی تنظیم نکنید پروسه احراز هویت و استفاده از منابع شبکه با مشکل رو به رو می شود.
        زیر مجموعه سایت شیء به نام Server وجود دارد که DC های یک سایت در آن نگهداری می شود. هنگام نصب Domain Controller تنظیمات IP آن با سایتها و سابنتها مقایسه می شود و بصورت اتوماتیک، DC سایت خود را در هنگام نصب انتخاب میکند. ولی اگر تنظیمات IP سرور DC با هیچکدام از سایتها مچ نباشد خود را در سایت DCی عضو می کند که اولین Replication را با آن انجام دهد.
        وقتی شما DC ی از سایتی به سایت دیگری منتقل می کنید باید تنظیمات IP آن را مطابق آن سایت بصورت دستی تعقیر دهید. و دستورات زیر را بر روی آن اجرا کنید:

        Ipconfig /flushdns

        Ipconfig /registerdns

        Net stop netlogon

        Net start netlogon

        و همیشه در قسمت Preferred dns server ادرسها را بصورت ضربدری بر روی DC ها تنظیم کنید. علت اینکار را در اینده اگر عمری باقی ماند توضیح می دهم.
        شیء NTDS که زیر مجموعه Server می باشد نشان دهنده آن است که بر روی این سرور سرویس Active Directory نصب می باشد. و همچنین این شیء نشان دهنده DC های در حال کار و یا از رده خارج شده می باشد.
        وقتی شما DCی را demote می کنید شی NTDS حذف می شود. تا نشان دهد این سرور از رده خارج می باشد.
        Connection object شیء می باشد که برای Replication بین DC ها استفاده می شود. Connection object یک مسیر یک طرفه می باشد که DC های مبدا ترافیک Replication خود را به سمت آنها (DC های مقصد) ارسال می کنند.
        KCC برای هر DC ی که دارای شیء NTDS باشد یک Connection object می سازد. (این پروسه برای DC های درون یک سایت اتفاق می افتد)

    Connection object هم بصورت یک طرفه One-way و هم دو طرفه Two-way در ارتباط می باشد. متد One-way درون یک سایت کاربرد دارد ولی متد Two-way بین سایتها استفاده می شود. مثال می زنم: وقتی چندین سایت داشته باشیم و قابلیت Bridge link را غیرفعال کنیم ISTG یک Connection object می سازد و از طریق این کانکشن ترافیک replication را دریافت و ارسال می کند.

        بحثی داریم به نام مالکیت Connection object یا Ownership of Connection Objects کانکشنهای که توسط KCC ایجاد می شوند در مالکیت KCC قرار دارند و KCC میتواند آنها را حذف، تعقیر یا ایجاد کند. ولی اگر ادمین یک کانکشن ایجاد کند این کانکشن در مالکیت ادمین می باشد و پروسه KCC حق ندارد آن را تعقیر دهد.
        وقتی شما کانکشنی را که در مالکیت KCC or ISTG باشد تنظیمات آن را تعقیر دهید از مالکیت KCC خارج می شود.
        وقتی ادمین کانکشنی را ایجاد می کند، ان کانکشن باقی می ماند تا ادمین ان را پاک کند. همچنین اگر KCC کانکشنهای یکسانی را ایجاد کند انها را بصورت اتوماتیک حذف خواهد کرد و فقط کانکشنهای ضروری را ایجاد می کند.
        DC ها همیشه کانکشنهای DC های مبدا را در خود ایجاد می کنند و replication را از آنها درخواست می دهند.

    Image

        برای اینکه ISTG بتواند Connection object های لازم بین سایت خود با سایتهای دیگر را ایجاد کند نیاز به ایجاد یک Site Link می باشیم. شیء Site Link به پروتکل انتقال ترافیک Replication و زمانبندی کردن Replication بین سایتها و همچنین لینک اتصال دو سایت اشاره دارد. ISTG از اطلاعات ذخیره شده در Site Link ها استفاده و Inter-site topology را ایجاد میکند.
        بصورت پیش فرض همه site linkها که از یک پروتکل انتقال (IP or SMTP) استفاده می کنند، KCC فرض می کند که همه آنها بوسیله یک مسیر یا Route به همدیگر وصل (bridge) می باشند. اگر می خواهید KCC چنین برداشتی نکند و برای دسترسی به سایتی چندین مسیر وجود دارد یا در مواقعی که سایتهای شما Full route نباشند باید این قابلیت را غیرفعال کنید و Route های مختلفی بوسیله Site link bridge بصورت دستی ایجاد و Site link ها را عضو Site link bridge کنید.
        NTDS Site Settings Object شیء می باشد که در زیر مجموعه سایت قرار دارد و تنظیمات و نحوه اعمال این تنظیمات بصورت Site-wide می باشد. هر سایت مجاز به داشتن یک NTDS Site Settings Object می باشد:

    Image

    NTDS Site Settings Object هر سایت وظایف زیر را بر عهده دارد:

        مشخص کردن ISTG هر سایت.در تصویر بالا BF-01-DC مسئنول و مالک این پروسه در این سایت می باشد.
        ایا DC های این سایت مجاز به کش کردن اعضای Universal groups هستند یا نه؟
        ایجاد زمان بندی برای Connection object ها.

        شیء دیگری وجود دارد به نام Cross-Reference Objects که در کنسول AD Site and Services قابل مشاهده نیست و بوسیله کنسول Adsiedit.msc قابل مشاهده می باشد. این شیء محل های Directory Partition را ذخیره می کند. Active directory replication از این شیء استفاده می کند و DC های که Directory Partition بر روی انها ذخیره شده است را نشان می دهد.
        DC برای انتقال Replication از دو پروتکل انتقال استفاده می کند: RPC over IP and STMP over IP. Replication درون یک سایت و بین سایتها همیشه از RPC over IP بصورت همزمان استفاده می کند. برای سایتهای که به ندرت در دسترس هستند و ارتباط درست و درمونی بین آنها نباشه از SMTP over IP استفاده می شود. توجه کنید SMTP برای انتقال Replication بین یک Domain در دو سایت مختلف استفاده نمی شود چون بوسیله این پروتکل فقط پارتیشنهای زیر Replicate می شود:
            Schema
            Configuration
            Global catalog

    در نتیجه Domain partition نمی تواند از SMTP استفاده کند.
    SMTP and IP از دو متد برای انتقال ترافیک Replication استفاده می کنند.

        Synchronous=RPC over IP
        Asynchronous=SMTP over IP

        RPC over IP از Synchronous استفاده و شروع به Inbound Replication می کند. در ارتباطات Synchronous دومین کنترولر مقصد درخواست Replicate با DC مبدا می کند و منتظر جواب می ماند تا DC مبدا درخواست را دریافت کند و Replication را اماده کند و ان را قبل از ارسال notification change به بقیه DC آن را به سمت DC مقصد ارسال کند. به این پروسه inbound replication می گویند در نتیجه DC ها مقصد در ارتباطات Synchronous جواب و داده های Replication را در مدت زمان کوتاهی دریافت می کنند. پروتکل IP از متد Synchronous استفاده می کند. ولی در متد Asynchronous که برای پروتکل SMTP استفاده می شود DC های مقصد منتظر جواب DC های مبدا نمی مانند و در بازه های زمانی خاص درخواست Replication را به چندین DC ارسال می کنند. در نتیجه دریافت Replication در یک زمان کوتاه اتفاق نمی افتد.
        اگر سایت شما در نقطه بدی قرار دارد و همیشه در دسترس نباشد و نتوان بوسیله RPC over IP اطلاعات Replicate را سینک کرد، تنها گذینه ای که برای Replication بین دو سایت باقی می ماند استفاده از E-Mail می باشد. وقتی که ارتباط دو سایت با هم دیگر قطع وصل می شود باید از روش Asynchronous استفاده کرد (SMTP) به علاوه زمانی که محدودیتی از نظر پهنای باند بین دو سایت داشته باشیم نمی توان دو DC را مجبور کرد تمام اطلاعات خود را (All directory partition) ریپلیکت کنند در نتیجه می توان از SMTP استفاده کرد که درخواست خود را در بازه های زمانی مختلفی برای چند DC ارسال کند و در هر بازه از زمان قسمتی از اطلاعات را دریافت کند.
        در Inter-site replication و استفاده از SMTP ما بجای RPC از Mail messaging استفاده می کنیم. در این روش از Change notification استفاده نمی شود بلکه هنگامی که هر دو سایت به همدیگر وصل شدند شروع به تبادل اطلاعات می کنند.
        Intersite messaging قابلیتی می باشد برای Replication بین دو DC که از SMTP استفاده می کنند. این قابلیت هنگام نصب سرویس AD نصب و فعال می شود.
        KCC برای DC های که از SMTP استفاده می کنند Connection object ایجاد نمی کند تا وقتی که شرایط زیر بر روی DC ها اعمال شود:
            باید رول IIS را بر روی هر دو Bridgehead server ها نصب کنیم
            نصب CA در مد Enterprise برای رمزگذاری پیغامهای ردو بدل شده بین دو سایت. وجود Domain Controller Certificate بر روی CA Server ضروری می باشد.
            دوسایت باید بوسیله SMTP site link به همدیگر وصل باشند.
            اگر دو سایت را بوسیله چندین Site link وصل کرده باشید (IP or SMTP) باید site link مربوط به SMTP کمترین مقدار Cost را داشته باشد.

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

        DC را باید تنظیم کنیم که E-Mail ها را دریافت کند، علاوه بر آن باید مطمئن شد که mail ها دست DC مقابل برسد. (اگر دو سایت مستقیما به هم دیگر وصل باشند نیازی به تنظیم خاصی نیست، در غیر اینصورت نیاز به تنظیم یک Mail gateway هستیم.

  • نظرات() 
  • یکشنبه 3 اردیبهشت 1396

    آیا اگر شما ندونید یک نفر چطور یک قفل رو باز میکنه میتونید یک قفل امن درست کنید؟ حتما متوجه منظور بنده شدید، نمیشه بدون فهمیدن مشکلات از مشکلات جلوگیری کرد.یک هکر از مشکلات امنیتی سرور، سایت یا هر قسمت دیگه ای استفاده میکنه تا به هدفش برسه. مقاله ای که باهم میریم جلو یک تیتر هیجان انگیز داره :) چگونه یک هکر شویم.

    این تیتر شاید یک جمله کوتاه باشه ولی یک دنیا حرف و کتاب و آموزش و وقت توش پنهانه. از هیچکس پنهان نیست که هرکسی نمیتونه یک هکر بزرگ بشه حالا هرچقدر هم که میخواد تلاش کنه، همونطور که هرکسی نمیتونه انیشتین بشه چون بعضی چیز ها ذاتی هست. حتما خبری تحت این عنوان که کودکی 13 ساله سایت اینستاگرام را هک کرد و 10 ملیون دلار از اینستاگرام جایزه گرفت رو خوندید، خب مشخصه که این آدم یک نابقه هست. ولی دلسرد نشید، با تلاش شاید نتونیم به این فرد 13 ساله برسیم ولی حتما از کسانی که تلاشی نکردند چندین سر و گردن بالاتر خواهیم رفت و همونطور که شعار خودم هم هست میگم اونقدر تلاش کنید تا اسطوره هایتان تبدیل به رقیبانتان شوند. اگر شما هک رو بلد نباشید شاید بتونید امنیت رو بخونید و حتی خوب هم بشید داخل امنیت ولی هیچوقت به اونجایی نمیرسید که یک امنیت کار بسیار حرفه ای بشید همونطور که میدونید بسیاری از امنیت کار های بزرگ دنیا روزی هکر های بزرگی بودن مثل اسطوره هک تاریخ آقای Kevin Mitnick

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

    قدم اول: یادگیری unix
    unix سیستم عامل اینترنت است. تا زمانی که شما unix رو یاد نگیرید نمیتونید از اینترنت درک درستی داشته باشید (البته نه اینکه فک کنید فقط با یادگیری unix میتونید کاملا اینترنت رو درک کنید). برای یادگیری unix شما میتونید از سیستم عامل های unix like شروع به کار کنید مثل لینوکس و میتونید در مرحله اول اون رو در برنامه های مجازی سازی بریزید تا بعد که حرفه ای تر شدید در کنار ویندوز یا حتی به تنهایی روی لپ تاپ خودتون بریزید. اگر کسی سعی کنه هک رو بدون لینوکس و کلی تر بگم بدون unix یاد بگیره مثل این میمونه که بخواد با لباس قواصی رقص یاد بگیره :) در حالت کلی شما باید سیستم عامل های open source رو بدونید چون mac هم جزوی از unix like هاست ولی کاملا open source نیست و از طرفی هم به سفت و سختی microsoft هم close source نیست. در واقع یادگیری mac لازمه ولی اگر بخواید از اول با اون شروع کنید مثل این میمونه که بخواید مسایقه دو شرکت کنید ولی برای تمرین تو جنگل بدویید که به خاطر وجود درخت ها دائم باید مسیرتون رو عوض کنید و نمیتونید مثل مسابقه مستقیم بدوید.

    قدم دوم: یادگیری زیرساخت ها
    خب حالا شما درباره سیستم ها میدونید ولی همونطور که گفتم فقط با یادگیری unix نمیتونید درک کاملی داشته باشید از اینکه اینترنت یا سرور ها چطور کار میکنن یا چطور بسته ها ارسال و دریافت میشن. شما برای اینکه بتونید روی بسته ها امنیت ایجاد کنید باید بدونید این بسته به چه شکل حرکت میکنه و چه کارهایی میتونیم روی یک بسته انجام بدیم و یه هکر یک بسته رو چطور به دست میاره. برای شروع یادگیری زیرساخت میتونید از سیسکو شروع کنید. یادگیری سیسکو در سطح پایه، به شما دید خوبی از زیرساخت میده. پروتکل های routing و انواع switching ها زو یاد میگیرید و متوجه شکل رفت و آمد بسته ها میشید و روی ip ها و شکل کارکردشون اطلاعات به دست میارید. حالا شما با زیرساخت ها آشنا شدید لایه های مختلف tcp/ip و osi رو میدونید (میدونم همه تو دانشگاه خوندید اینا رو و هیچوقت اساتید محترم ریز نشدن تا جا بیفته که چرا میخونید) و حالا شما دیگه میتونید با خوندن کتاب های زیر ساختی بهتر متوجه این قضایا بشید.باید اطلاعات خودتون رو درباره لایه ها بالا ببرید که وقتی یک بسته ارسال میشه هر لایه چه header ای به بسته اضافه میکنه و تو این header ها چه چیزایی اضافه میشه و اون چیز ها چه کارهایی انجام میدن. برای مثال میتونید تو گوگل سرچ کنید tcp header یا ip header و ببینید که چقدر مسائل ریزی داره داخل هر بسته ارسالی.

    قدم سوم: html بنویسید
    شما باید برنامه نویسی یاد بگیرید. یک هکر خوب باید بتونه با کامپیوتر صحبت کنه و در قسمت وب باید بدونه یک سایت چطور نوشته شده. خب دوستان از ینده بهتر میدونن که html نه به ما یاد میده که با کامپیوتر صحبت کنیم و نه باد میده وب سایت بنویسیم. ولی اینجا یک مسئله ای هست. اولا که html به شما کد زدن رو یاد میده و حوصله شما رو سر نمیبره چون میتونید هرچی رو که یاد میگیرید همون لحظه ببینید و اینکه برای شروع و یادگیری وب سایت نویسی باید از html یاد بگیرید پس شما یک تیر و دو نشون میزنید. برای مشاهده این قضیه میتونید تو همین browser ای که هستید برید داخل قسمت Developer و بعد page source و یه مقدار زمان بذارید و کد های html همین سایت یا هر سایت دیگه ای رو که میخواید رو ببینید.بهتره که کد زدن رو تو برنامه های پایه مثل notepad یاد بگیرید تا دستتون به کد زدن عادت کنه. اینجوری کدزنی براتون سخت میشه و یاد میگیرید تو هر شرایطی کد بزنید چون هرچی بیشتر به مشکل بخورید بیشتر آب دیده میشید. 

  • نظرات() 
  • یکشنبه 3 اردیبهشت 1396

    شما بعنوان یک ادمین شبکه حتما با سرویس DNS بخوبی آشنایی دارید اما ممکن است اطلاعات زیادی درباره یکی از مهم ترین رکورد های DNS یعنی SOA رکورد نداشته باشید.هدف از این مقاله هم دادن اطلاعات خوب و مفید درمورد این Resource record میباشد. برای یک Internet Administrator هیچ چیز مسالمت آمیزتر از پایداری و بهینه سازی DNS سرور نیست.جمله سنگینی بودD: اگر یک پیکربندی اشتباه در DNS سرور وجود داشته باشد DNS سرور قادر به پاسخ گویی صحیح نمیباشد و آنوقت است که وبسایت ها و ایمیل ها down میشوند.بخش مهمی از تنظیمات سرور DNS را رکورد SOA به خود اختصاص داده است.بیایید یکم در مورد Record ها صحبت کنیم ...
    DNS Record ها در یک فایل zone و در DNS سرور،وظیفه تبدیل کردن Url ها را به IP آدرس ها را بر عهده دارند.یعنی در واقع این Record ها هستند که عهده دار اصلی تبدیل نام(FQDN) به آدرس IP هستند که با توجه نوع رکورد ها و مصارفشان میتواند متفاوت باشد.مثلا رکورد های مربوط به Mail Server ها MX هستش و رکورد مربوط به تبدیل نام به آدرس IP در شبکه داخلی A Record هستش و ... . در زیر میتوانید یک نوع فایل zone را مشاهده میکنید:

    ;
    ; Zone file for mydomain.com
    mydomain.com. 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com.(
            2004123001
            86000
            7200
            1209600
            600 )

    mydomain.com. 14400 IN NS ns.mynameserver.com.
    mydomain.com. 14400 IN NS ns2.mynameserver.com.
    mydomain.com. 14400 IN NS ns3.mynameserver.com.

    mydomain.com. 14400 IN A 216.34.94.184

    localhost.mydomain.com. 14400 IN A 127.0.0.1

    mydomain.com. 14400 IN MX 0 mydomain.com.
    mail 14400 IN CNAME mydomain.com.
    www 14400 IN CNAME mydomain.com.
    ftp 14400 IN CNAME mydomain.com.

    در ادامه این مقاله بخش های مختلفی از رکورد های DNS که در بالا مشاهده میکنید را آنالیز و بررسی خواهیم کرد ...

    SOA Record
    SOA یا به اختصار Start Of Authority رکوردی است که ضروری ترین بخش از یک فایل zone را تشکیل میدهد.SOA رکورد رکوردی است که به مدیران Domain اطلاعات پایه ای از دامین را میدهد نظیر : چه زمان هایی Update میشود ، زمان آخرین آپدیت چه وقت بوده ، آدرس ایمیل ادمین و غیره.توجه کنید که هر فایل zone شامل یک رکورد SOA میباشد.آپدیت شدن SOA رکورد بین name server ها بخوبی در افزایش پهنای باند و بهینه سازی آن نقش موثری دارد. و همچنین در افزایش سرعت دسترسی به وبسایت ها هنگامی که حتی DNS سرور اصلی Down شود یا از کار بیفتد را نیز بر عهده دارد.در زیر اطلاعات و پارامتر هایی که یک SOA Record دارد را مشاهده میکنید:

    ; name        TTL     class    rr     Nameserver         email-address
    mydomain.com. 14400     IN     SOA
    ns.mynameserver.com. root.ns.mynameserver.com.
    (
            2004123001 ; Serial number
            86000 ; Refresh rate in seconds
            7200 ; Update Retry in seconds
            1209600 ; Expiry in seconds
            600 ; minimum in seconds )

    حال به توضیح تک تک پارامتر های بالا میپردازیم ...
    -mydomain.com:نام zone ما را مشخص میکند.که همان نام domain ما هست.مثل:itpro.ir
    -TTL – 14400 :این پارامتر معرف مدت زمانی است که کلاینت میتواند این رکورد را cache کند.که اگر مقدارش را صفر انتخاب کنید یعنی کلاینت نمیتواند آنرا در خود کش کند.بازه زمانی این پارامتر بین 0 تا 2147483647 ثانیه هست.(نزدیک 68 سال!!!)
    -IN:این پارامتر یک class است که نوع رکورد را نشان میدهد.IN در اینترنت بیشتر بکار می آید.اگر DNS شما مدت زمان طولانی است که در در اینترنت یا شبکه داخلی(اینترانت) هست شما باید از IN استفاده کنید.
    -Nameserver – ns.nameserver.com:
    nameserver سروری است که فایل های zone را در خود نگهداری میکند.مثلا من یک دامین کنترولر دارم به اسم dc01.itpro.ir که فایل zone ام رو که itpro.ir هستش رو نگهداری میکنه.به همین سادگیD:
    -Email address:این پارامتر نشانگر آدرس ایمیل دامین ما هستش که در اینجا .root.ns.nameserver.com هستش،شاید برای خیلیا مبهم باشه که چرا @ توش وجود نداره؟!!جواب اینه که ایمیل به آدرس روت یعنی root@ns.nameserver.com فرستاده میشه اما بصورت .root.ns.nameserver.com نوشته میشه.دات(.) که بعد از com هستش همون root هست که ما هیچوقت نمینویسمیش ولی به اون صورت نوشته میشه.
    -Serial number – 2004123001:این شماره چیزی نیست جز عددی که آخرین آپدیت zone رو نشون میده که معمولا به همراه تاریخش میاد.و به فرمت date/revision بیشتر رایجه.توجه کنید اگه سریال نامبر مربوط به Primary nameserver کمتر یا مساوی Secondary nameserver باشه هیچ تغییراتی یا بهتر بگیم هیچ انتقالی از Secondary nameserver یه Primary nameserver رخ نداده.
    -Refresh :مقدار این پارامتر که به ثانیه هستش معرف فاصله زمانی refresh شدن slave dns server و primary dns server هست.که در اینجا مقدارش 86000 ثانیه هست.dns سرور دومی به سریال نامبرش نگاه میکنه اگه مقدارش کمتر از سریال نامبر dns سرور پرایمری باشه درخواست رفرش میده و اطلاعات zone اش رو بروز رسانی میکنه.
    -Retry:اینجا فرض کنید که dns سرور دومی یا slave میخواد با dns سرور Primary ارتباط برقرار کنه ولی میبینه سرور down هستش و جواب نمیده.مقدار Retry اینجاس که بکارمون میاد.اگه مثلا روی 10 دقیقه تنظیم شده باشه بعد از هر پاسخ ناموفق ده دیقه صبر میکنه و دوباره درخواست میفرسته.این پارامتر زیاد مهم نیستش جدی نگیریدشD:
    -Expiry:این پارامتر معرف مدت زمانی است که DNS سرور slave فایل zone رو تو خودش نگه میداره یا بهتره بگیم کش میکنه اگه سرور DNS پرایمری نتونه جواب بده.توصیه شده که این مدت زمان بین 2 تا 4 هفته باشه.
    -Minimum – 600:
    این پارامتر معرف مدت زمانی است که DNS سرور slave باید فایل zone رو داخلش کش کنه.این پارامتر یکی از مهم ترین پارامتر ها در رکورد SOA هستش.اگر dns سرور شما اطلاعاتش دائما در حال تغییر و بروزرسانی هست مقدارش رو 1 روز یا کمتر انتخاب کنید.برعکس اگه رکورد های dns سرور شما خیلی کم تغییر میکنه مقدارش رو بین 1 تا 5 روز در نظر بگیرید.مزیت تنظیم کردن بالاترین مقدار این پارامتر اینه که سرعت وبسایت شما بشدت افزایش پیدا میکنه چون که جستجو ها کاهش پیدا میکنه و سرعت میره بالا.امیدوارم از خوندن این مقاله لذت کافی رو برده باشید.ITPRO باشید

  • نظرات() 
  • یکشنبه 3 اردیبهشت 1396

    شاید خیلیاتون ندونید قبل از اینکه توی ادارات کامپیوتر و شبکه بیاد توی اداره های بزرگ برای جابجایی نامه ها یا همون اکسچنج سرور خودمون از سیستم شبکه بادی استفاده میشد
    شبکه بادی نامه رسانی

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

    این کپسول از 4 قسمت 1- درب 2- محفظه3- flag یا تگ 4 - دنباله تشکیل شده
    البته شایان ذکر است که توی این سیستم flag نشان دهنده خالی و پر بودن و همچنین مقصد نامه است .
    روش کار :
    روش کار به این شکل بوده که توی هر اتاق لوله بادی بوده و چند تا کپسول که وقتی میخواستن نامه ای رو ارسال کنن لوله میکردن درب کپسول رو باز میکردند و داخل کپسول میذاشتن و درب اون رو محکم میکردن و مقد که طبق یه کد بوده روی کپسول مشخص میشده و داخل محفظه ارسال قرار میدادن و بعد دکمه ارسال رو فشار میدادن .
    فشار و مسیر باد در لوله ها در اتاق سویچ کنترل میشده و اتاق سویچ رو همان ادمین شبکه های امروزی مدیریتش میکردند و جالب اینجاست اون موقع هم سرعت شبکه مثل سرعت اینترنت بوده و برخی افراد سرعت باد بیشتری توی لوله هاشون بوده به دلیل الویت کاریشون و برخی هم سرعت کمتری اینم بخاطر این بود قدرت باد توی لوله ها خب افت فشار پیدا میکرده و ضمن اینکه سیستم بادی توسط کمپرسورهای قوی همیشه داشته ساپورت میشده ولی شما فرض کنید که نامه های هی پشت هم ارسال بشند و سرعتشون که بالا بره کمپرسور ها سرعتشون نسبت به ارسال نامه ها پایین میاد و کم میارن و کاربران هی باید منتظر میشدن تا کمپرسور بهشون برسه و هوار و کمپرس بکنه برای همین تمهیدات الویت بندی فشار هر لوله انجام شده بوده

    فشار شکن های سویچینگ شبکه های بادی



    این خودش یه صنعت بوده و کلی قوانین داشته مثلا خم لوله ها نباید زیاد باشه و استاندارد داشته و همچنین وسط مسیر برای تقویت باد باید ریپیتر امروزی رو به شکل باد میذاشتن و خیلی از مطالبی که الان داریم راحت باهاش کار میکنیم اون زمان دغدغه ادمین شبکه های بادی بوده.

    Image

    واحد سوئیچینگ برای کنترل ازدهام و کنترل جریان همیشه راهکارهایی رو رعایت میکرده (این همون پروتکلهای flow control خودمونه) مثل راهکارهایی مثل نوبت دهی و...
    سیستم کاری این شبکه کاملا به شکل شبکه های امروزی بوده فقط با فرق این که اگه با نامه یه خوراکی یا یه جسم دیگه میخواستن بفرستن میتونستن بفرستن . فرض کنید توی اداره شما میخواهید برای همکارتون گل بفرستید با این کپسوله ها میتونید به راحتی انجامش بدید .
    واحد سوئیچینگ


    شبکه های بادی

    ضمن این که منبع فارسی برای این موضوع ندیدم توی هیچ سایتی تا بحال این موضوع رو نخوندم ، دلیل توجه من به این نوع شبکه این بود که فقط توی یه فیلم به نام (Dark city 1998) دیدم این نوع شبکه رو و توی اینترنت به انگلیسی سرچ کردم بعد از کلی جستجو فهمیدم به این نام مشهوره (pneumatic tube system)

    خب اینم باید بدونید که ایده اصلی این شبکه از طرح مترو بادی توی سال 1867 از آقای Alfred Ely Beach
    ایده متروی بادی



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

  • نظرات() 
  • یکشنبه 3 اردیبهشت 1396

    Data deduplication اغلب به نام های intelligent compression(فشرده سازی هوشمند) و یا single-instance storage(اینو واقعا نمیتونم معادل فارسیشو پیدا کنم!) نیز مشهور است.
    Data deduplicationفرآیندی است که از افزونگی ناشی از کپی شدن اطلاعات تکراری و در نهایت از overhead شدن دستگاه های ذخیره سازی اطلاعات جلوگیری به عمل می آورد. تکنیک Data deduplication از این اطمینان حاصل میکند که تنها یک نمونه از داده یا همان Data در دستگاه ذخیره سازی اطلاعات یا مدیا(دیسک،فلش مموری،tape و ...) نگهداری شده است.بلوک های اطلاعاتی redundant شده جایگزین یک نمونه اصلی و اولیه ی ساخته شده اطلاعات میشوند.تصویر زیر بخوبی مفهوم آنچه که گفتم را بیان میکند:
    Image

    اگر با روش بکاپ گیری به طریق incremental آشنایی دارید مکانیزم کاری data deduplication به طور تنگاتنگی با incremental backup مطابقت دارد،که تنها داده هایی که تغییر یافته جایگزین backup قبلی میشود و کل اطلاعات بکاپ تحت تاثیر قرار نمیگیرد.
    برای مثال یک سیستم email به طور معمول ممکن است شامل 100 نمونه از فایل هایی باشد که هر کدام مانند هم 1 مگابایت حجم دارند و عینا مانند هم هستند و هیچ تفاوتی در محتوای آنها وجود ندارد،در حین اگر از email هایمان بکاپ یا آرشیو گرفته شود کل 100 نمونه باید ذخیره شود که نیازمند 100 مگابایت فضای ذخیره سازی میباشد.با بکارگیری Data deduplication تنها یک نمونه از آن همه فایل های یکسان ذخیره میشود با یک حساب سرانگشتی ما 99 مگابایت در فضای ذخیره سازی مان صرفه جویی کردیم.حال این تنها یک مثال کوچک بود اما اگر در محیط های enterprise که از فضاهای ذخیره سازی بسیار کلان استفاه میکنند این شرایط پیش بیاید بدون شک هزینه های یک سازمان را برای فراهم سازی فضای ذخیره سازی افزایش میدهد.
    بررسی Target Deduplication و Source Deduplication:
    فرآیند Data Deduplication میتواند در دو سطح Source-based dedupe و target-based dedupe اتفاق بیفتد که به توضیح هر یک میپردازیم ...
    Source-based dedupe بلوک های داده افزونه شده را قبل از اینکه به backup target انتقال داده شود حذف میکند چه کلاینت باشد چه سرور.فرآیند Source-based dedupe به هیچ سخت افزار اضافه ای نیاز ندارد.از ویژگی های فرآیند Deduplicating در سطح source کاهش پهنای باند و storage می باشد.
    در target-based dedupe که نسبت به Source-based dedupe برتری دارد Backup ها در بستر شبکه به disk-based hardware مانند دستگاه های ذخیره سازی SAN انتقال داده میشوند.استفاده از این نوع فرآیند درست است که نیازمند متحمل شدن هزینه های نسبتا زیادی است اما در عوض آن نسبت به Source-based dedupe عملکرد مطلوبی را به همراه دارد.

    تکنیک های deduplicate کردن data:
    دو متد اصلی برای Deduplicate کردن برای داده های redundant شده وجود دارد:
    Inline deduplication و post-processing deduplication
    در محیط های عملیاتی backup گیری از اطلاعات به شما به طور وضوح مشخص میکند که از کدام یک از این دو نوع تکنیک استفاده کنید.
    Inline deduplication داده ها را درون سیستم Backup آنالیز میکند.داده های زائد یا تکراری که در سیستم ذخیره سازی Backup ذخیره شده اند حذف میشوند.تکنیک Inline dedupe کمتر به ذخیره سازی Backup نیاز دارد اما در جای خود میتواند سبب bottleneck شود.کارخانه های سازنده Storage Array مانند شرکت HP توصیه میکنند که ابزار inline data deduplication بهتر است Turn off شوند تا عملکرد primary storage بالا برود.حال به توضیح Post-processing dedupe میپردازیم ...
    Post-processing dedupe فرآیند Backup نامتقارن است که بعد از اینکه داده ها در Storage نوشته شد اقدام به حذف redundant data ها میکند.در این فرآیند داده های Duplicate شده در محل اصلی بلوک داده ها که قرار گرفته اند حذف و جایگزین میشوند.این نوع تکنیک به کاربران یک مزیت بسیار خوب را نوید میدهد که میتوانند به طور انعطاف پذیری workload ها را dedupe کنند و سریعا بکاپ های اخیر را بازیابی کنند بدون اینکه زحمت زیادی را متحمل شوند.
    منظور از File-level data deduplication و block-level data deduplication :
    Data deduplication میتواند در دو سطح Block Level و File Level عمل کند.
    File deduplication همانطور که از نامش مشخص است فایل های duplicate شده را از بین میبرد.اما آن یک کارایی چندان مفیدی برای فرآیند deduplication ندارد.File-level data deduplication فایل مورد نظر را که Backup گرفته شده اند و یا آرشیو شده اند با فایل هایی که کپی آنها ذخیره شده است مقایسه میکند.این کار با چک کردن attribute های آن فایل انجام میدهد بر خلاف چک کردن index شده هایشان،اگر فایل Unique بود ذخیره میشود و index اش برزورسانی میشود، اگر نه ، pointer ای که به فایل موجود ایندکس شده اشاره دارد ذخیره میشود و از ذخیره شدن دوباره آن فایل در کنار فایل مشابهش جلوگیری میکند.نتیجه این میشود که فقط یک نمونه از فایل ذخیره میشود و کپی های مکرر جایگزین فایل اصلی میشود.
    Block-level deduplication درون یک فایل را نگاه کرده و از هر بلوک داده که مقدارش با بلوک داده های دیگر که تنها در قسمتی تغییر در آن وجود دارد و بقیه عین هم هستند را ذخیره میکند.همه Block ها به chunk(تکه یا فرگمنت هایی با طول مساوی) هایی با طول یکسان شکسته میشوند.هر chunk از داده ها از الگوریتم Hash نظیر MD5 و یا SHA1. استفاده میکنند و مورد پردازش قرار میگیرند.این فرآیند یک شماره منحصر بفرد که نتیجه الگوریتم هش است برای هر تکه یا chunk تولید میشود و سپس در index ذخیره میشود.وقتی یک فایلی برزورسانی شد تنها تغییرات داده آن فایل ذخیره میشود حتی اگر اندازه اش یک بایت باشد.این روش block deduplication را کاراتر و موثرتر میکند.اما در هر حال block deduplication کندتر انجام میشود و قدرت پردازش بیشتری را میطلبد و از index های بزرگتری برای مسیریابی هر chunk استفاده میکند.
    Hash collisions یک مشکل اساسی در فرآیند deduplication است.وقتی تکه ای از یک داده یک شماره Hash منحصر بفرد را بخود اختصاص میدهد آن hash با hash ]ای دیگر در داخل index مقایسه میشود،اگر آن شماره hash در index موجود بود آن تکه از داده duplicate در نظر گرفته شده و نیاز به ذخیره سازی مجدد آن نمیباشد.بر خلاف این قضیه،hash نامبر جدید در index اضافه میشود و داده جدید ذخیره میشود.در موارد نادر Hash نامبر تولید شده برای دو chunk از داده یکسان ایجاد میشود در این حین اگر فرآیندHash Collision رخ دهد سیستم داده جدید را ذخیره نمیکند زیرا سیستم اینگونه در نظر میگیرد که دو Hash نامبر هم اکنون در index وجود دارد و نیاز به ذخیره سازی داده جدید نیست.این اتفاق بد data loss را برایمان به وجود می آورد.تعدای از Vendor ها از الگوریتم های Hash ترکیبی استفاده میکنند تا از فرآیند hash collision تا حد مناسبی جلوگیری به عمل آورند.این کار باعث بالارفتن امنیت در ذخیره سازی داده ها هم میشود.همچنین تعدای از Vendor ها metadata ها را بررسی میکنند تا داده ها را تمیز دهند و از وقوع collisions جلوگیری کنند.

  • نظرات() 
  • یکشنبه 3 اردیبهشت 1396

     چرا Replicate میکنیم؟
    سئوالی که ممکن است برایتان پیش بیاید این است که ما چرا از Replication در سرور های DFS استفاده میکنیم و این کار چه مزیت هایی به همراه دارد.به طور فنی شما به DFS سرور های چندگانه نیاز ندارید.اما توجه کنید شما دقیقا به Replica DFS Server نیاز خواهید داشت.برای شروع شما با استفاده از replica server های متعدد به زیرساخت DFS خود را درجه ای از scalability یا مقیاس پذیری خواهید رساند.به جای اینکه هر کاربر به منابع به اشتراک گذاشته شده در یک سرور دسترسی پیدا کنند شما میتوانید درخواست Workload ها یا بارکاری هر کاربر را بین DFS Server های متعدد توزیع کنید تا اینکه فقط یک سرور پاسخگوی درخواست های آنها باشد.
    دلیل دیگر استفاده از DFS replica های چندگانه فراهم آوردن fault tolerance یا تحمل خرابی میباشد.برای مثال فرض کنید میخواهید Service Pack های ویندوز را بر روی ویندوز سرور نصب کنید و به لطف ویندوز جان در هر بار نصب شدن باید یکبار ریستارت شود این ریستارت شدن پی در پی میتواند مانع از دسترسی پیوسته به منابع سرور میشود و ما در اینجا down time خواهیم داشت حال اگر از DFS replica های چندگانه استفاده کنیم این مشکل نیز مرتفع میشود.شما میتوانید با فراهم آوردن fault tolerance در DFS سرور ها در صورت Fail شدن یکی از لینک های شبکه به سرویس دهی به کاربران ادامه دهید.فرض کنید شما یک branch office دارید که با لینک WAN به main office یا اداره مرکزی وصل شده است در این حین اگر لینک WAN از کار بیفتد و خراب شود کاربران حاضر در branch office نمیتوانند به هر سروری که در main office وجود دارد وصل شوند و از منابع آنها استفاده کنند.حال اگر یک سرور DFS replica در branch office داشته باشید آخرین بار قبل از fail شدن لینک WAN اطلاعاتی که از DFS Root حاضر در main office با DFS replica حاضر در branch office ریپلیکیت شده اند دریافت میکند و زمانی که DFS Root به مدار بازگشت DFS replica در branch office اطلاعاتش را با DFS Root حاضر در main office یکسان سازی یا Synchronize میکند.
    Replication Topology(توپولوژی Replication):
    ویندوز سرور 2008 و همچنین 2012 از جفت توپولوژی های Replication پشتیبانی میکند.هر توپولوژی مزایا و معایب خاص خودش را داراست.اگر شما در تصمیم گیری برای استفاده از این توپولوژی ها مشکل دارید شما بایستی با توجه به نیاز سازمان خود از این توپولوژی ها بهره ببرید.در ادامه به معرفی هر یک از این توپولوژی ها میپردازیم...
    The Hub and Spoke Topology
    این توپولوژی یکی از محبوب ترین و پرکاربردترین توپولوژی های DFS replication میباشد.همانطور که در تصویر زیر مشاهده میکنید این توپولوژی شبیه به توپولوژی star در بین توپولوژی های شبکه های کامپیوتری است.در توپولوژی hub and spoke سروری که در مرکز قرار دارد در اصطلاح initial master نامیده میشود.هر replica یک replication دوطرفه را با سرور initial master انجام میدهد.اما با DFS سرور های کناری Replicate انجام نمیدهد.این نوع توپولوژی بسیار کارایی دارد اما نقطه ضعفی که این توپولوژی دارد این است که اگر سرور initial master از کار بیفتد سرور های replica قادر به انجام فرآیند Replicate با آن نخواهند بود.نکته ای که اینجا مطرح است برای استفاده از این توپولوژی باید حداقل 3 عدد DFS Server داشته باشید.
    Image

    The Full Mesh Topology
    این توپولوژی یکی از توپولوژی های رایج دیگر برای DFS replication میباشد که معمولا در محیط های آزمایشی از این نوع توپولوژی استفاده میشود.تصویر زیر نمایانگر این توپولوژی است.در این توپولوژی هر DFS سرور میتواند با DFS سرور دیگر فرآیند replication اطلاعات موجود در فولدر های اشتراکی را انجام دهد.یکی از مزیت های این توپولوژی در دسترس بودن سرور ها در هر زمان میباشد بطوریکه اگر یکی از سرور ها Down شود با سرور دیگر میتواند اطلاعاتش را replicate کند.اما یکی از مهمترین نقاط ضعف این توپولوژی ایجاد ترافیک بیش از حد روی لینک شبکه است که پهنای باند خیلی زیادی را اشغال خواهد کرد.پیشنهاد میشود در صورتی که از لینک های پرسرعت استفاده میکنید از این نوع توپولوژی استفاده کنید.
    Image

    No Topology?
    زمانیکه شما replication group را در ویندوز سرور 2008 یا 2012 پیکربندی میکنید گزینه آخر گزینه ای به نام No Topology است.شاید برایتان عجیب بنظر برسد که این توپولوژی که توپولوژی نیست پس چیست!!! گزینه No Topology به شما امکان ایجاد کردن replication group را بدون استفاده از توپولوژی فراهم میکند.این گزینه بعدا به شما اجازه میدهد تا replication topology خاص خود را انتخاب کنید.از این گزینه برای تست میتوانید در محیط های آزمایشی استفاده کنید.اما همیشه best practice ها را در نظر بگیرید. 

  • نظرات() 
  • یکشنبه 3 اردیبهشت 1396

    اگر چه ویندوز سرور 2008 و 2012 فرآیند Replication را در تکنولوژی سرویس DFS بهبود بخشیده است اما ما در این مقاله به شرح آنچه که مایکروسافت برای بهبود بیشتر و سلامت و نگهداری آن توصیه کرده است میپردازیم.در این مقاله به Best Practice های مایکروسافت درباره سرویس DFS میپردازیم.
    Backup Strategy(استراتژی پشتیبان گیری):
    اینکه فکر کنید فولدرها و فایل ها در DFS tree ذخیره میشوند و با سرور های دیگر این اطلاعات Replicate میشوند و نیازی به تهیه نسخه Backup از آنها ندارید متاسفانه در اشتباهید.داشتن سرور های DFS replica از اطلاعات شما در برابر وقوع حادثه ای مانند fail شدن هارد دیسک جلوگیری میکند.اما آن هیچ وقت از خرابی داده ها جلوگیری نمیکند.اگر فایلی دچار خرابی شداطلاعات خراب شده در سرور های تارگت هم Replicate میشود.
    بخاطر اینکه داده ها در هر سرور DFS replica ریپلیکیت و یکسان سازی میشوند شما میتوانید از یکی از سرور های DFS replica یک نسخه Backup تهیه کنید.اما چیز مهمی که حتما باید به خطر داشته باشید این است که نرم افزاری که عملیات Backup گیری از داده های سرور DFS را انجام میدهد نباید داده های آرشیو شده را هم به مجموعه اطلاعاتی که بکاپ گرفته شده اند اضافه کند،به این دلیل که file replication با فایل های بکاپ گرفته شده از نقطه نظر تاریخ و Time stamp(مهر زمانی) منجر به تداخل پارامتر های مذکور میشود.این مورد شاید جدی به نظر نرسد اما خب به عنوان Best Practice مایکروسافت بهتر است به آن عمل کنید تا از آسیب های احتمالی به داده هایتان جلوگیری کنید.
    Disk Space:
    شاید این خیلی بدیهی به نظر برسد اما برخی اوقات شاهد این مسئله هستیم که ظرفیت Staging Folder را آنقدر کم و کوچک در نظر می گیرند که واقعا مسخره به نظر می رسد ، درایوی که حاوی Staging Folder است باید آنقدر ظرفیت و فضای خالی داشته باشد تا بتواند فرآیند Replication را برای DFS مدیریت کند ، در عین حال این فضا به منظور یک فضای موقتی برای Replicate کردن داده هایی که ارسال و دریافت می شوند نیز در نظر گرفته می شود.
    The DFS Root:
    ملاحظات متعددی درباره ایجاد DFS Root وجود دارد که باید رعایت کنید.بنده پیشنهاد میکنم که با یک DFS Root خالی شروع به ایجاد آن کنید بنابراین با این کار شما میتوانید از Replicate شدن هر داده ای جلوگیری کنید.DFS root باید تنها شامل فولدر هایی باشد که توسط DFS مدیریت میشوند.من همچنین پیشنهاد میکنم که از Replicate شدن داده های فولدر های درون DFS Namespace ریشه جلوگیری کنید،به این دلیل که ویندوز علاوه بر replicate کردن اطلاعات root فولدر های تارگت را هم replicate خواهد کرد.شاید این چیز زیاد بدی نباشد اما این را به خاطر داشته باشید که target folder ها در بسیاری از نمونه ها به طور مستقل اطلاعات خودشان را با DFS ریشه Replicate میکنند.پس راه اندازی replication در سطح Root افزونگی یا redundancy برای Replication فراهم نمیکند.
    تصمیم گیری برای اینکه چه Replication ای مناسب است و یا اصلا Replication لازم است؟
    در هر حال DFS replication به شما در امر تقسیم بار کاری بین فایل سرور های متعدد کمک شایانی میکند و میزانی از fault tolerance یا تحمل خرابی را برایتان به ارمغان می آورد اما توجه کنید که این همیشه مطلوب نیست.برای مثال محیطی را در نظر بگیرید که کاربران به طور مداوم بر روی داده ها تغییرات اعمال میکنند.در این چنین محیط هایی هر آپدیتی میتواند شماره ورژن فایل را تغییر دهدکه باعث انجام فرآِیند DFS replication میشود.اگر تعداد زیادی از این آپدیت ها بین فایل ها انجام شود به دنبال آن DFS Replication های زیادی انجام میپذیرد که اصلا مناسب و مورد قبول نیست.این حادثه در اصطلاح Replication storms(توفان Replication) نامیده میشود.
    Replication storms ها قابل جلوگیری هستند،زیرا ویندوز سرور 2008 و 2012 به شما این امکان را میدهد تا مقدار پهنای باندی که توسط فرآیند Replication مصرف میشود را محدود کنید.مشکلی که در این قابلیت وجود دارد این است که اگر DFS replication پهنای باند کافی برای انجام دادن فرآیند replication نداشته باشد داده هایی که باید replicate میشدند بلافاصله با دیگر سرور ها synchronize نمیشوند که میتواند منجر به بوجود آمدن تداخل در ورژن های فایل شود.
    به طور معمول بهترین محیط ها محیط هایی هستند که کاربران از فایل سرور های دیگر داده ها را میخوانند اما تغییرات زیادی روی آنها ایجاد نمیکنند.در اینگونه محیط ها بارکاری replication مینیمم است زیرا replication زمانی اتفاق می افتد که آپدیتی اتفاق بیافتد.
    اگر کاربران سازمان تان بطور مداوم فایل ها را بروز رسانی میکنند شما میتوانید یک replication schedule برای آن تعریف کنید تا در ساعات کاری غیر اوج اقدام به replicate کردن داده هایی که میخواهند بروز رسانی شوند انجام دهد با این کار صرفه جویی موثری در پهنای باند لینک شبکه تان میشود.بار دیگر نیز این کار میتواند منجر به تداخل ورژن در دو نمونه جداگانه از فایل ها در هر بروز رسانی شود،قبل از اینکه replicate انجام گیرد.از این نقطه نظر شما باید تصمیمات جدی درباره انتخاب استراتژی تان با توجه به نیاز ها و شرایط سازمان تان بگیرید.
    نتیجه گیری:
    در این مقاله ما درباره موضوعاتی صحبت کردیم که شما میتوانید آنها را درمحیط های عملیاتی برای اطمینان حاصل کردن از اینکه DFS Replication در شرایط مناسب انجام پذیرد به کار بگیرید.ما همچنین درباره به کارگیری روش هایی که میتوانید برای عدم بوجود آمدن اختلال در شبکه در فرآیند replication انجام دهید نیز صحبت کردیم.بخاطر داشته باشید که این هایی که گفتیم تنها Best Practice های مایکروسافت در رابطه با این سرویس است و مسائل دیگر و حتی مهمتری نیز میتواند در فرآیند Replication صورت پذیرد.در مقاله بعد آموزش صفر تا صد راه اندازی سرویس DFS را در ویندوز سرور 2012 برایتان خواهیم داد. 

  • نظرات()