چیزهای که باید در مورد Replication در ساختار Directory Service بدانید

معمولا در محیطهای که بیش از چند Domain Controller وجود دارد برای بالا بردن Availability و دسترسی به اطلاعات بین چند DC از Replication یا همگان سازی استفاده می شود. در این مقاله قصد ندارم درباره کل پروسه Replication توضیح بدم و اینکه چگونه این پروسه بین DC ها ایجاد و جریان پیدا می کند. فقط نکات مهم این پرسه را برسی میکنیم
یک سوال مهم چرا ما به Replication نیاز داریم؟
در ساختار Directory Service یکسری اطلاعات مجزا مربوطه به قسمتهای مختلف Directory Service در کانتینریهای به نام Partition نگهداری می شوند. در یک Forest چندین پارتیشن داریم که بعضی از آنها در محدوده کل فارست باید اعمال شود و بعضی ها در محدود Domain. و اما پارتیشن ها:
Domain directory partition: Also known as the domain naming context (NC), contains domain-specific objects such as computer, user, and group accounts.
Configuration directory partition: Contains forest-wide data that controls site and replication operations.
Schema directory partition: Contains schema definitions for the forest.
Application directory partitions: Contain data that is particular to specific applications. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of domain.
بعضی از اطلاعات باید در کل Forest یکسان باشد و بعضی از آنها در یک دومین. همه Domain Controller ها در هر نقطه ای که باشند باید به این اطلاعات دسترسی داشته باشند. و این اطلاعات بوسیله Replication بین DC ها Sync می شوند. علاوه بر پارتیشن های بالا یکسری ابجکیت، سرویس ها و Role ها داریم که نیازمند Replication هستند مانند:

    Universal groups
    PDC emulator
    Global Catalog

etc.
نکته: Replication از سرویس FRS and DFS برای انتقال اطلاعات بین DC ها استفاده می کند. اگر FFL شما از Windows server 2003 به پایین باشد از FRS استفاده می شود ولی اگر FFL از Windows server 2008 به بالا باشد از DFS استفاده می کند.
DCها میتواند در یک Site یا چندین سایت در چندین نقطه جغرافیائی با همدیگر فعالیت کنند. شاید برای شما مهم باشه که در ساختار Directory Service سایت را چگونه تعریف می کنند؟
سایت در ساختارDirectory Service یک محدود جغرافیائی جدا می باشد که دارای Subnet یا Subnet های جداگانه ای هستش که با لینکهای پر سرعت به هم دیگر وصل می باشند. ممکن است شما در یک سایت چندین Domain داشته باشید یا یک Domain در چندین سایت باشد. که در این صورت مدیریت و بهینه سازی Replication دومین کنترول ها بین سایتهای مختلف مهمترین نقش طراح یا ادمین شبکه می باشد.
Intra-site Replication
اینگونه Replication درون یک سایت و بین Domain Controller های آن سایت اتفاق می افتد. وقتی تعقیری بر روی یکی از DC ها ایجاد شود DC ها بوسیلهChange Notifications به بقیه اعلام می کنند که ها ولک بیا ببین چی داروم اونا هم میان و خودشون رو بر روز می کنند.
نکته: وقتی می گوئیم یک DC می خواهد با DC دیگر Replication کند Replication در اینجا به معنی درخواست می باشد. و در پروسه Replication تمام درخواستها بصورت Pull هستند یعنی گرفتنی ، کشیدنی و DC مقصد اطلاعات را به DC مبدا ارسال می کند.
درون یک سایت ارتباطات ساختار بوسیله پروسه KCC یا Knowledge Consistency Checker بصورت اتوماتیک ایجاد می شود و KCC کانال ارتباطی یک DC با DC دیگر را بوسیله شیء به نام Connection object ایجاد می کند. Connection object ها همیشه بصورت Incoming Connection هستند.

DC های بویسله پارامترهای زیر Replication را مدیریت می کنند:

    Update Sequence Numbers
    High-watermark values
    UP-TO-Dateness vectors
    Change Stamps
    Polling

برای کسانی که می خواهند لیاقت لغب Microsoft Ensnaring را داشته باشند باید با ریزترین اشیاء در این ساختار اشنا باشند.
نکته: Replication درون یک سایت بر اساس تعقیراتی هستش که بر روی DC ها ایجاد می شود، اتفاق می افتد. اگر تعقیری در DC ی ایجاد شد DC 15 ثانیه صبر خواهد کرد ( به این تاخیر Intial Notification Delay می گویند) و منتظر می ماند که اگر تعقیری دیگه ای وجود داره ایجاد بشه تا یکباره همه اطلاعات را Replicate کنه. بعد از replicate 3 ثانیه صبر خواهد کرد (این تاخیر را Subsequent Notification Delay می نامیم) واطلاعات را برای DC دیگر ارسال می کند.
Inter-site Replication
این نوع Replication بین سایتهای Directory Service اتفاق می افتد. این Replication بر خلاف Intrasite بر اساس Schedule یا زمان بندی اجرا خواهد شد. مثلا اگر تعقیری در DC یکی از سایتها ایجاد شود بر اساس زمان بندی که انجام دادیم Replication برای Bridgehead Server ها ارسال خواهد شد. علاوه بر خاصیت Schedule ما گذینه دیگری به نام Replication Period داریم که تعداد تکرار Replication بر اساس زمانی که تعیین کردیم را مشخص می کند. که بصورت پیش فرض ,Replication Period 180 دقیقه معادل 3 ساعت می باشد.
هنگام replication بین سایتها پروسه KCC بصورت اتوماتیک در هر یک از سایتها یک نماینده انتخاب می کند. که وظیفه این نماینده دریافت Replication ار بقیه سایتها می باشد و انتشار آن بین DCهای سایت می باشد. همه این نماینده را با نام Bridgehead Server می شناسن.
نکته: پروسه KCC و مولفه آن یعنی Intersite Topology Generator کانکشنهای لازم (Connection object) بین سایتها را بصورت اتوماتیک ایجاد می کند. ISTG کانکشنها را بر اساس Site Link ها ایجاد می کند.

گفتیم که Bridgehead ها توسط KCC انتخاب می شوند. در شرایطی ما می توانیم این نقش را به سروری دیگری واگذار کنیم. برای اینکار لینک زیر را مطالعه کنید:
Designate a Server as a Preferred Bridgehead Server

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

نکته: در سازمانهای خیلی بزرگ که حجم Replication زیاد می باشد میتوانید این مسئولیت را بین چندین DC واگذار کنید. و اگر یکی از این DC ها Down شد KCC یکی را به دلخواه انتخاب می کند.
بحث جایگزین شدن DC دان شده بین سایتها بحث خییییلی مهمی می باشد که خارج از بحث این مقاله می باشد. حتما لینکهای که در آخر مقاله ضیمیه می کنم را بخوایند.
بحث دیگری که در Inter-Site وجود دارد بحث Replication Latency می باشد. Replication Latency مدت زمانی می باشد که "یک تعقیر بر روی دیگر DC ریپلیکت شود" اشاره دارد. مشخص کردن Replication Latency درون یک سایت خیلی سادس که در حالت نورمال کمتر از2 دقیقه می باشد. (بستگی به Node ها و سرعت ارتباط آن سایت دارد) ولی محاسبه این زمان بین سایتها کمی دشوار هستش در ابتدا باید مدت زمان رسیدن تعقیرات از DC مبدا به Bridgehead Server محاسبه شود و مدت زمانی که این Replication به دست Bridgehead Server مقابل برسد و همچنین فاکتورهای مانند Schedule و Replication Period در این محاسبه دخیل هستند. که بصورت پیش فرض وقتی یک تعقیر در یک سایت ایجاد شود در مدت زمان 3 ساعت 4 دقیقه این تعقیرات بر روی دیگر DC ها سایت مقابل اعمال می شود. (شما دستون بازه می تونید این تنظیمات را تعقیر دهید).

فرض کنید Schedule را بصورت تمام وقت تنظیم کردیم و Replication Period را بر روی 15 دقیقه ست کردیم. پس زمان دقیق convergence شدن اطلاعات بصورت زیر محاسبه می شود:

A to B = 15 min + B to C = 30 min + C to D = 45 min

علاوه بر محاسبه Replication Period ما تاخیر 15 ثانیه ای هم داریم که در کل تقریبا 105 ثانیه می باشد.
نکته خیلی مهم: همیشه Schedule and Replication Period همه Site Linkها (امکانش باشد) باید یکسان باشند.
در برخی از موارد یکسری تنظیمات داریم که با چنین مدت زمانی 45 دقیقه ای واقعا دردسر سازه مثلا یکی از کاربران انکانتش Lock شود. این بدبخت 45 دقیقه معطل شود!!! درضمن بعضی از تنظیمات امنیتی باید در کمترین زمان ممکن به دست دیگر DC برسد. این تنظیمات:

    Account Lockout Policy
    Domain Password Policy
    RID Master Moving
    Local Security Authority

برای حل این مشکل ما از Urgent Replication استفاده می کنیم. این نوع Replication همه تنظیمات Schedule and Replication Period را نادیده می گیرند. و تنظیمات بالا را به دست بقیه می رساند.
خانمها یک نمونه بارز از این نوع replication هستند. ://
Understanding Urgent Replication

https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/


همچنین یک قابلیتی وجود داره به نام inter-site change notifications که اگر تعقیری در یکی از DC ایجاد شد این تعقیر کمتر از 3 دقیقه می تواند به DC های دیگر سایتها اعمال شود. در مورد آن تحقیق کنید.
Site Link
بصورت فیزیکی هر یک از سایتها را بوسیله اتصالات Broadband به هم دیگر متصل می کنند. Site Link مسیر ارتباطی یک سایت با سایت دیگر را مشخص می کند و همچنین مسیر Replication را هم تعیین می کند (Replication Path). در کنسول AD Site and Service سایت لینکها را بر اساس دو پروتکل انتقال:

    IP or DS-RPC
    SMTP or ISM-SMTP

تنظیم می کنند. که اولویت با IP می باشد. SMTP در مواقعی استفاده می شود که لینک ارتباطی ما با شعبه دیگر Stable یا غیر قابل اعتماد باشد. همچنین SMTP نیاز به ساختار PKI دارد. وهمچنین نمی توان برای یک دومین از این پروتکل انتقال استفاده کرد. هر کدام از این لینکها دارای خاصیتی به نام Cost هستند. وظیفه Cost تعیین مسیر Replication بین سایتها می باشد و در خیلی از موارد مورد استفاده قرار می گیرد. زمانی که شما یک forest ایجاد می کنید یک site link به نام DEFAULTIPSITELINK بصورت پیش فرض ایجاد می شود. اگر شما چندین سایت داشته باشید و Site Linkی ایجاد نکنید KCC فرض می کند همه ی این سایتها با این Site Link وصل هستند و در صورت عدم ایجاد Site Link عملیات replication با مشکل مواجه می شود.
یکی از مشخصات مهم Site Link ها transitive بودن آنها می باشد. یعنی اگر ما سایت A, B and C داشته باشیم و سایت A و B را بوسیله Site Link متصل کرده باشیم و همچنین B به C سایتها A و C بدون نیاز به داشتن Site Link می توانند با هم دیگه Replicate کنند.
Site Link Bridges
یکی از مهترین پارمتر در تنظیمات AD Site and Service می باشد. Site Link Bridges مجموعه ای از Site Linkها می باشد که همه سایتها را به هم وصل میکند حتی سایتهای که بهم دیگر لینک نباشند!!!
 مثلا ما سه سایت داریم که بصورت Hup and Spoke می باشند. همه سایتها به شعبه اصلی وصل هستند و سایتهای Milan and Atlanta هیچگونه Site Linkی ندارند ولی چون Site Link Bridge بر روی این دو Site Link فعال می باشد این دو سایت می توانند با هم دیگه اطلاعات خود را replicate کنند. قابلیتی که باعث میشه Site link bridge این هنرنمائی را انجام دهد خاصیت transitive بودن Site Link Bridge ها می باشد.
نکته: بصورت پیش فرض Site Link Bridge بر روی Site Linkها فعال می باشد.
نکته: اگر سایتهای شما not fully routed, هستند (یعنی از Atlanta قادر نباشید Milan سایت را پینگ کنید) باید خاصیت Bridge all site links را بر روی Site Link ها غیر فعال کنید و در شرایطی باید یک Site Link Bridges بصورت دستی ایجاد کنید.

نکته: اگر 20 سایت داشته باشید که 19 تا از این سایتها full route باشند و یکیشون full route نباشه مجبورید Bridge all site links را بر بصورت کامل غیرفعال کنید.
And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site

 برای اینکه شعبه ها بتوانند با هم دیگر replicate کنند باید Bridge Site Link را غیر فعال و یک Bridge Site Link دستی ایجاد کنید. ایجاد یک Bridge Site Link مانند ایجاد یک Route بر روی یک Router می باشد.مثلا چهار سایت وجود دارد که بصورت Hup and Spock می باشد به نظر شما Bridge Site Link را چگونه ایجاد کنیم که همه بتوانند با هم دیگر replicate کنند؟؟؟؟
در بالا سه عدد site link وجود دارد:

    NYC-TO-SEATTEL
    NYC-TO-CHICAGO
    NYC-TO-MIAMI


اگر به Site Link ها نگاه کنید یکی از سایتها در همه Site Link ها مشترکه و آن هم سایت NYC می باشد. پس NYC مثل یک روتر عمل می کند و replicate سایتها را بین آنها منتقل می کند.
این یک قانونه که وقتی شما یک یا چند Bridge site link ایجاد می کنید با یکی از سایتها در کل Site Link ها وجود داشته باشد.
Each site link in a bridge must have at least one site in common with another site link in the bridge.
خب الان چند سناریو میگیم و با هم تجزیه و تحلیل می کنیم. سناریوی اول:
    همه آنها زیر مجموعه یک دومین فعالیت می کنند.
    همه DC ها نقش GC بر روی آنها فعال شده است.
    این سه سایت Full Route نیستند.
    دو عدد Site Link برای ارتباط این سه سایت استفاده شده .

الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟
تنها کاری که باید انجام دهیم غیر فعال کردن Bridge all site links هستش. همین و بس...
چطور!!!!!!؟؟؟؟؟؟
چون ساختار full route نیست ما Bridge site link را غیر فعال می کنیم. چرا یک Bridge site link نساختیم؟؟؟؟ چون هر سه سایت یک دیتای مشترک را نگهداری می کنند (یک دومین می باشد) در مثال بالا فرض کنید سایت NYC تعقیراتی ایجاد کرد، این تعقیرات در زمان معین با Bridgehead Server سایت SEA ریپلیکت می شود و در مرحله آخر سایت DFW از تعقیرات با خبر می شود و خود را با SEA سینک می کند.
سناریوی دوم:
    سه عدد سایت با دو دومین با نام های Reskit.com و Noam.reskit.com
    ساختار Full Route می باشد.
    DC های سایت NYC and DFW نقش GC بر روی آنها فعال شده است. ولی DC های سایت SEA نه.

الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟
این سایتها با دور روش می توانند با هم دیگر Replicate کنند:

    فعال بودن Bridge site link و استفاده از خاصیت transitive بین لینکها.
    غیر فعال کردن Bridge site link بر روی لینکها و ایجاد یک Bridge site link دستی.

بنظر شما چرا علاوه بر غیر فعال کردن Bridge site link باید یک Bridge site link دستی ایجاد کنیم؟؟؟
بخاطر اینکه دومین سایت SEA با بقیه فرق می کند و این دوسایت اطلاعات مختلفی را نگهداری می کنند پس بخاطر همین دلیل غیر فعال کردن Bridge site link نمی تواند موثر باشد. در نتیجه ما مجبوریم یک Bridge site link دستی ایجاد کنیم. در سناریوی بالا ایجاد Bridge Site Link بصورت دستی برای سایت NYC یک Route به سمت DFW از طریق سایت SEA ایجاد می کند که پروسه KCC بتواند طبق این مسیر Connection Object خود را ایجاد و اطلاعات خود را با سایت DFW بروز رسانی کند

آموزش بکاپ گیری در دایرکت ادمین

 میزبانی وب   
backup icon

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

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

در هنگام تهیه بکاپ حتما به مصرف حجم دیسک خود توجه نمایید. در صورتی که حجم دیسک اکانت شما کافی نباشد بکاپ ناقص تهیه خواهد شد.
برای تهیه بکاپ کامل لازم است حداقل ۴۰ درصد از حجم دیسک شما خالی باشد.
چگونه از وب سایت خود بکاپ بگیرم؟

1. ابتدا وارد محیط مدیریت هاست خود با توجه به مشخصات اکانت ارسالی توسط میزبان شوید.
2. سپس از صفحه اصلی وارد قسمت Create/Restore Backups شوید.
create restore backups
3. در صفحه ای که باز شده است، از بخش Backup All Domains کلیه گزینه ها را جهت فول بکاپ انتخاب کنید سپس بر روی Create Backup کلیک کنید.
full backup
4. پس از کلیک با صفحه بکاپ گیری در صف انجام قرار گرفت مواجه می شوید.
backup creation
5. پس از اتمام بکاپ گیری از طریق ایمیل مطلع خواهید شد. همچنین از صفحه اصلی با کلیک بر روی گزینه Message System در بالای صفحه، می‌توانید پیغام اتمام بکاپ را مشاهده نمایید.
backup ready
چگونه بکاپ گرفته شده را رستور نماییم؟

1. برای رستور بکاپ یا برگرداندن بکاپ، به قسمت Create/Restore Backups رجوع کنید.
2. از پایین صفحه در قسمت Select a File to Restore بکاپ مربوطه را انتخاب و بر روی Select Restore Options کلیک کنید.
restore options
3. در صفحه باز شده کلیه گزینه‌ها را برای رستور نمودن تمامی اطلاعات انتخاب نموده و بر روی Restore Selected Items کلیک کنید.
restore item
4. پس از اتمام رستور از طریق Message System مطلع خواهید شد.

دوره آموزشی CCNA Wireless CWNA قسمت اول : استاندارد سیگنال های رادیویی ( RF Standards )

رای ارتباط موفقیت آمیز ، دیوایس های وایرلسی میباست از روش های مرجع و استانداردی استفاده کنند که بین تمام دیوایس ها مشترک و سازگار باشد. این متد ها باید پارامتر ها و ویژگی هایی را دارا باشند که بدون کوچکترین تداخل شرایطی را ایجاد کنند تا دستگاه های وایرلس با یکدیگر تعامل داشته باشند و عملیات های مورد نظرشان را انجام دهند.
فصل دوم ، از سری آموزش های CCNA Wireless 200-355 CWNA به بررسی و معرفی این استاندارد ها ، نهاد های استاندارد گذاری و انواع متد ها خواهد پرداخت .
در مقاله پیش رو ، قصد داریم مفهوم ITU-R و FCC را باهم بررسی کنیم. با ما همراه باشید.

اتحادیه بین المللی مخابرات (ITU-R)
itu


وظیفه یک اداره نظارتی ارتباطات و مخابرات اینست که تعیین کند یا تصمیم بگیرد که کدام قسمت از موج های سیگنال رادیویی میتواند برای کدام هدف مشخص ، استفاده شود و بعلاوه چگونه میتواند استفاده شود. یک کشور ، ممکن است ارگان تعیین کننده مقررات خود را داشته باشد که موج های RF مربوطه را در مرز های مشخص خود کنترل میکند. اما ، بعضی از سیگنال های رادیویی با توجه به خصلت خود و فاکتور های مغیر متعددی میتوانند به مسافت های گسترده تری پخش (Spread) شود.
برای مثال ، یکی از اهدافِ ایستگاه های رادیویی این است که امواج خود را بصورت Broadcast از یک کشور به تمام کشور های دنیا منتقل کنند.
مثال مشابه دیگر این است که یک کارخانه سازنده رادیو احتمالا تجهیزات خود را بصورت جهانی به فروش برساند در این صورت مهم نیست که فرستنده و یا گیرنده در کدام نقطه از کره زمین وجود داشته باشند و کارخانه با توجه یک استاندارد معین تجهیزات خود را تولید میکند.
خب برای مدیریت امواج سیگنال های رادیویی در سطح جهانی ، سازمان ملل ؛ بخش بین المللی مخابرات اتحادیه ارتباطات رادیویی ( International Telecommunication Union Radio Communication Sector ) را تاسیس کرد.
ITU-R امواج و فرکانس های رادیویی را در 3 ناحیه مجزا تعریف میکند :
- ناحیه 1 : اروپا - آفریقا و آسیای شمالی
- ناحیه 2 :شمال و جنوب آمریکا
- ناحیه 3 : آسیای جنوبی و استرالیا
ITU-R وظایف متعددی دارد که در زیر به برخی از مهمترین آنها اشاره خواهیم کرد.
علاوه بر اینکه ITU-R تلاش میکند تا امواج RF برای تمام کشور ها قابل استفاده باشد ،همچنین سعی میکند تا مطمئن شود تا سیگنال هایی که از یک کشور به بیرون مخابره میشود با سیگنال های کشور های دیگر تداخل نداشته باشد. از وظیفه های ITU-R میتوان به کوشش برای تعیین کردنِ کاربرد مورد انتظار از هر قسمت از امواجِ RF نام برد.
ITU-R ، حتی مدار مربوط به ماهواره ها و فرکانس ها را ردیابی میکند ؛ بنابراین ، سیگنال های مربوط به ماهواره های یک کشور با سیگنال های ماهواره های کشور های دیگر تداخل پیدا نخواهد کرد.
بسیاری از باند ها در سیگنال های رادیویی شدیدا کنترل میشوند ، بدین منظور که شما باید قبل از استفاده از یک فرکانس خاص از یک نهاد نظارتی درخواست مجوز کنید.
نهاد های نظارتی ، معمولا نوع اجازه انتشار را تعیین میکنند و مجموعه ای از محدودیت ها را بر روی چیزهایی مانند منبع انتشار سیگنال ها و همچنین قدرت آنها ، اعمال میکنند.

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

در مقابل ، ITU-R ، برای مثال ، تنها دو محدوده فرکانس زیر را برای نرم افزار های صنعتی ، علمی و پزشکی ارائه کرده است که در اصطلاح به این نرم افزار ها ISM Applications ، میگویند. industrial, scientific, and medical (ISM)
دو محدوده فرکانس (ISM Bands) نامبرده که میتوانند بدون محدودیتی بر روی Wireless LAN ها پیاده سازی شوند عبارتند از :
2.400 تا 2.500 GHz
5.725 تا 5.825 GHz
دسترسی این محدوده از باند ها برای هرکسی که قصد دارد از آنها استفاده کند ، آزاد است.
به معنای دیگر ، میتوان از محدوده فرکانس باند های ISM بدون هیچگونه مجوز یا اجازه ای برای انتقال داده های مورد نظر استفاده کرد.
نکته قابل توجه در این است که ، در حالی که استفاده از باند های بدون مجوز بسیار راحت تر میباشد ؛ اما بسیار آسیب پذیر تر میباشند و میتوانند مورد سوء و دخالت قرار بگیرند.
برای مثال ، به دلیل اینکه ISM Bands قابلیت دسترسیِ بدون هیچگونه محدودیتی برای همگان دارد ، هکر ها میتوانند بر روی این بستر های ارتباطی ، شنود (Sniffing) انجام دهند و بیت های مربوط به داده های انتقالی را ببینند.
یا برای مثالی دیگر ، تصور کنید که شما تصمیم دارید برای اداره خود یک فرستنده وایرلس نصب کنید که از یک فرکانس [حالا هرچی!] استفاده میکند. روز بعد ، در اداره همسایه یک فرد دیگر فرستنده وایرلس خود را نصب میکند ، که از طرفی دقیقا در همان فرکانس شما سیگنال ها را Broadcast میکند یا حتی از فرکانسی استفاده میکند که با فرکانس شده Overlapping میشود. خب راه حل چیست؟
راه حل بسیار سادس . بخاطر اینکه هیچگونه مجوز و اعمال فاکتور های خاصی (unlicensed) در کار نیست ؛ شما میتوانید زحمت بکشید و transmitter خود را به فرکانس دیگری تغییر بدید یا قدری دیپلماسی به خرج بدهید و همسایه خود را راضی کنید تا او transmitter خود را به فرکانس دیگری منتقل کند.

    نکته : تمام فرکانس باند هایی که برای شبکه های وایرلس (Wireless LANs) ، استفاده میشود ؛ از نوعِ بدون مجوز میباشد.

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

    نکته : فرستنده هایی که بصورت بدون مجوز هستند (Unlicensed Transmitter) باید تنها باید میان محدوده فرکانس های تایید شده بمانند و سیگنال ها را در بین ماکسیمم Power Levelای که تایید شده است ، ارسال کند.

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

FCC
FCC


در ایالات متحده ، کمیسیون فدرال ارتباطات یا The Federal Communications Commission وظیفه دارد تا مقررات مربوط به فرکانس های رادیویی ، کانال های رادیویی و تعیین میزان قدرت انتقالی را بر عهده دارند.

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

همانطور که گفتیم ، ISM Band از محدوده فرکانس 2,4-2,5 GHz استفاده میکند که توسط ITU-R معرفی شده است.

    نکته : FCC به Unlicensed National Information Infrastructure (U-NII) ، فضای فرکانس 5GHz را برای تهجیزات شبکه اش ، اختصاص داده است .

U-NII ، در واقع به 4 زیر-باند تقسیم میشود :
U-NII-1 (Band 1): 5.15 to 5.25 GHz
U-NII-2 (Band 2): 5.25 to 5.35 GHz
GHz 5.725 تا U-NII-2 (Band 3): 5.47 (گسترش یافته)
GHz 5.825 تا U-NII-3 (Band 4): 5.725 ( همانند ISM )

    نکته : از این پس ، زمانی که صحبت از باند های 5GHz میشود ، مقادیر مختلف آن تحت عناوین مختلف بیان میشود ؛ مانند ، U-NII-1, UNII-1, U-NII و ... .

دوره آموزشی CCNA Data Center ، فصل 1 ، بخش 1 ، اصول شبکه : بررسی TCP/IP و مدل OSI_مقدمه

فصل اول از این سری آموزش های CCNA Data Center ، شما را با مهمترین مسائل مربوط به TCP/IP آشنا خواهد ساخت.
بخش نخست از این فصل ، شما را با مفهوم و پروتکل های مرتبط با TCP/IP ، و مسائلِ پایه شبکه بصورت کامل و جامع آشنا میسازد که یک تصویر کلی از قوانین شبکه را در اختیارتان قرار میدهد . با ما همراه باشید.

TCP/IP و مدل OSI
مدل شبکه ، یا در برخی تعاریف "معماری شبکه" و "طرح شبکه" (Networking Blueprint)، اشاره به مجموعه ای جامع از Document (سند) ها دارد که منحصرا هر سند یک عملکرد کوچک مورد نیاز برای شبکه را شرح میدهد.
در مجموع ، این اسناد چیزی را معین میکنند که باید برای یک کامپیوتر اتفاق بیوفتد ، تا شبکه شروع به کار کند.
برخی از اسناد یک "پروتکل" را معین میکند ؛ که یکسری قوانین منطقی را معین میکند که دستگاه ها باید این قوانین منطقی را رعایت کنند تا بتوانند با یکدیگر ارتباط برقرار کنند.
بقیه اسناد ، یکسری الزامات فیزیکی را برای شبکه معین میکنند. برای مثال ، یک سند میتواند میزان ولتاژ و Level فعلی کابلی که در حال انتقال داده میباشد را معین میکند.
برای درک بهترِ معماری شبکه ، تصور کنید که شما قصد ساختن یک خانه را دارید. قطعا شما میتوانید بدون داشتن یک طرح شروع به ساختن خانه کنید. اما ، طرح میتواند شما را مطمئن کند که خانه ، پایه و شالوده و ساختار درستی دارد. پس ، هیچوقت خراب نخواهد شد . ساختن شبکه هم دقیقا مشابه ساختن خانه میباشد ؛ بنابراین اگر برای ساخت شبکه طرح و معماری منظمی داشته باشید قطعا کار راحت تر و طبق یک چارچوب معین و دقیق پیش خواهد رفت.

تاریخچه ای که منجر به TCP/IP شد!
امروزه ، در دنیای شبکه کامپیوتر ها از مدل شبکه TCPIP یا Transmission Control ProtocolInternet Protocol استفاده میکنند. اما ، دنیا همیشه انقدر ساده نبود.
زمانی پروتکل های شبکه وجود نداشتند ، فروشندگان اولین پروتکل های شبکه را ساختند که این پروتکل ها فقط مختص فروشندگان بود و فقط این پروتکل ها کامپیوتر آنها را پشتیبانی میکردند.
برای مثال ، IBM معماری سیستم های شبکه خود را تحت عنوان SNR یا System Network Architecture را در سال 1974 ارائه کرد.
دیگر فروشندگان هم همچنین مدل و معماریِ اختصاصی شبکه خود را طراحی میکردند. بنابراین ، نتیجتاً اگر شما صاحب یک کمپانی شبکه بودید و کامپیوتر های مورد نیازتان را از این فروشندگان خریداری میکردید ، مهندسان شبکه شما مجبور بودند بر پایه مدل های شبکه مربوط به هر کامپیوتر ، شبکه های متفاوتی را طراحی کنند و آنها را به یکدیگر متصل کنند تا باهم تبادل اطلاعات انجام دهند که متصل کردن این کامپیوتر ها باعث ایجاد نوعی شبکه های ترکیبی میشد که کار با آنها را بسیار سخت میکرد.

HistoricalModels
    نکته : با وجود اینکه فروشندگان مدل های اختصاصی شبکه خود را ارائه میکردند ، این مدل ها معمولا عملکرد بسیار خوبی داشتند.

سازمان بین المللی استاندارد سازی (ISO) در اوایل 1970 ، این وظیفه را بر عهده گرفت تا یکسری مدل ها را ایجاد کند .

    اولین مدلی که ارائه شد ، مدلی بود که تحت عنوان OSI شناخته میشود.

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

    دومین مدل ، در وزارت دفاع ایالات متحده (DoD) طراحی شد. برای پیشبردِ این مدل محققان و کارشناس های مختلف از دانشگاه های گوناگون داوطلب شدند تا به DoD در این زمینه کمک کنند.سرانجام این تلاش ها ، منجر به معرفی پروتکل TCP/IP شد.

در دهه 1990 ، کمپانی های شبکه شروع به اضافه کردنِ استادارد های OSI و TCPIP به شبکه های شرکت خود کردند. اما ، در پایان دهه 1990 ، TCPIP طرفداران بیشتری پیدا کرد و OSI دور انداخته شد.
امروزه در قرن 21 ، TCP/IP به نوعی حمکرانی میکند ، هرچند هنوز هم مدل های اختصاصی شبکه وجود دارند اما تقریبا به فراموشی سپرده شدند.
در رابطه با مدل OSI نیز ، که با سختی فراوان توسعه پیدا کرد ، بخاطر فرآیند استاندارد سازی کندتری که در مقایسه با TCP/IP دارد ، هیچوقت نتوانست در بازار جهانی به صورت چشمگیری موفقیت بدست آورد.
TCP/IP که توسط افراد متخصص داوطلب از شاخه های گوناگون ساخته شده ، قدرتمندترین مدل شبکه ایست که تا به امروز ساخته شده است.

در بخش 1 از فصل نخست از سری مقاله های CCNA Data Center ، ما بطور کامل و مفصل از 0 تا 100 این لایه را مورد بررسی و ارزیابی قرار خواهیم داد.
روش های مختلف و جذابی برای یادگیری هرچه بهتر این مدل و واقعیات جالبی در مورد TCP/IP و چگونگی کارکرد این مدل ارائه خواهد شد.
همچنین در این بخش ، شما در مورد یکسری از اصطلاحات مورد استفاده در OSI را خواهید آموخت. با itpro همراه باشید.