এনটিপি বিচ্ছুরণ কী এবং আমি কীভাবে এটি নিয়ন্ত্রণ করতে পারি?


20

আমরা বিচ্ছিন্ন নেটওয়ার্কগুলিতে উবুন্টু 14.04 সার্ভারগুলি রোল আউট করেছি, এনটিপিডি ৪.২..6p5 চলছে, গ্রাহকরা প্রদত্ত একাধিক এনটিপি সার্ভার ব্যবহার করার জন্য কনফিগার করেছেন (পুল.ntp.org অ্যাক্সেস নেই)। আমাদের বোবা টার্মিনাল ক্লায়েন্ট ডিভাইসগুলি ব্যারিবক্স (1.00-rc2) এবং ল্যারি ডলিটল থেকে ntpclient 2010 এর একটি পুরানো সংস্করণ চালায় ।

এই সেটআপটি বছরের পর বছর ধরে দুর্দান্ত কাজ করেছে, তবে সম্প্রতি আমরা একটি নতুন গ্রাহকের সাথে রোডব্লক করেছি। ntpdate-debianলিনাক্স সার্ভারের সাথে সম্পর্কিত হিসাবে তারা আমাদের 5 টি ইন-হাউস এনটিপি সার্ভার ঠিকানা সরবরাহ করেছে যা তাদের নিজেরাই দুর্দান্ত কাজ করবে বলে মনে হচ্ছে । ব্যাসিবক্স পক্ষের ক্ষেত্রে, ntpclient"ছত্রাক খুব বেশি" এর সাথে অভিযোগ করে। ডিবাগ আউটপুট ntpclientথেকে, এনটিপি সার্ভার থেকে "1217163.1" পাওয়া যায় তবে এটি সর্বাধিক মান সমর্থন করে নিখুঁত (65536)।

$ /usr/sbin/ntpclient -s -i 15 -h 10.17.162.250 -d
Configuration:
  -c probe_count 1
  -d (debug)     1
  -g goodness    0
  -h hostname    10.17.162.250
  -i interval    15
  -l live        0
  -p local_port  0
  -q min_delay   800.000000
  -s set_clock   1
  -x cross_check 1
Listening...
Sending ...
recvfrom
packet of length 48 received
Source: INET Port 123 host 10.17.162.250
LI=0  VN=3  Mode=4  Stratum=4  Poll=4  Precision=-20
Delay=60745.2  Dispersion=1346801.8  Refid=10.31.10.21
Reference 3668859928.942079
(sent)    3668859928.708371
Originate 3668859928.708371
Receive   3668859928.963271
Transmit  3668859928.963369
Our recv  3668859928.708371
Total elapsed:      0.00
Server stall:      93.09
Slop:             -93.09
Skew:          255443.94
Frequency:             0
 day   second     elapsed    stall     skew  dispersion  freq
42463 56728.708  rejected packet: abs(DISP)>65536

এগুলি একই ল্যানের সমস্ত ডিভাইস তাই খোলামেলাভাবে আমি flabbergasted। অগস্ট এমনকি।

ntpq -pnউবুন্টু 14.04 সার্ভার থেকে আউটপুট এখানে দেওয়া হয়েছে :

user@host:~$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l 1025   64    0    0.000    0.000   0.000
 10.17.162.249   10.17.6.10       5 u   23 1024   37    0.865  1381.07 697.260
 10.31.10.22     .LOCL.           1 u 1044 1024   17   29.586  -838.06 397.342
 10.17.6.10      10.31.10.21      4 u 1065 1024   17    0.366  105.245 402.999
*10.31.10.21     132.246.11.238   3 u    5 1024   37   29.418  794.292 616.796
 10.17.6.11      10.31.10.21      4 u 1038 1024   17    0.408  120.030 381.058

আমার প্রশ্নগুলি হ'ল:

  1. বিচ্ছুরণ কী এবং এর মান কী পরিবর্তন করতে পারে?
  2. এনটিপি সার্ভারগুলি থেকে আরও বিশদ পেতে আমি কমান্ডগুলি চালাতে পারি?
  3. ভুলটি উবুন্টু সার্ভারের পক্ষেই থাকতে পারে ntp.conf? সত্যিই সেখানে বিশেষ কিছু নেই।
  4. এক্ষেত্রে কোনও পরিবর্তনকে পরিবর্তন করতে চান?

কেবল ধরে নিচ্ছি - সরবরাহ করা পাঁচটি এনটিপি সার্ভারের ঘড়িগুলি কি কোনও ভাল? আপনি কি আপনার কনফিগারগুলি থেকে সবচেয়ে খারাপটিকে বাদ দিতে পারেন?
ক্রিগগি

1
আপনার অফসেট এবং জিটটারগুলি খুব বেশি। কমপক্ষে একটি সঠিক উত্স পান ।
মনিকা পুনরায় ইনস্টল করুন - এম শ্রাইডার

উত্তর:


21

আমি এখানে উত্তরগুলিতে কিছু বিভ্রান্তি দেখছি। প্রারম্ভিকদের জন্য, ntpclientঅন্তত -sমোডে, সম্পূর্ণ এনটিপি ক্লায়েন্ট হিসাবে অভিনয় করছে না, এটি কেবল একটি প্যাকেট প্রেরণ এবং গ্রহণ করছে , সুতরাং কোনও "শেষ 8 প্যাকেট প্রাপ্ত হয়নি"। এটি আসলে তার নিজস্ব বিচ্ছুরণের মোটেও অনুমান করে না।

পরিবর্তে, এটি যে মুদ্রণটি মুদ্রণ করে তা হ'ল সার্ভারের দ্বারা ফিরিয়ে দেওয়া প্যাকেটের "রুট ডিসপ্রেসন" (রুটডিস্প) নামটি, যা সেই সার্ভার এবং সঠিক সময়ের মধ্যে ত্রুটি / পার্থক্যের মোট পরিমাণের একটি অনুমান। যেভাবে এটি গণনা করা হচ্ছে তা বেশ সহজ: প্রতিটি এনটিপি সার্ভার হয় তার বাহ্যিক ঘড়ি (উদাহরণস্বরূপ একটি রেডিও বা জিপিএস রিসিভার) থেকে, বা অন্য কোনও এনটিপি সার্ভার থেকে সময় পায়। কোনও সার্ভার যদি কোনও বাহ্যিক ঘড়ি থেকে সময় পেয়ে যায় তবে এর মূল বিচ্ছুরণটি clock ঘড়ির আনুমানিক সর্বাধিক ত্রুটি। যদি এটি অন্য এনটিপি সার্ভারের থেকে সময় পায়, তবে এর মূল বিচ্ছুরণটি হ'ল সার্ভারের মূল বিচ্ছুরণ এবং তাদের মধ্যে নেটওয়ার্ক লিঙ্কের দ্বারা বিচ্ছুরিত বিভাজন।

এখানে বিভ্রান্তির একটি বিষয় হ'ল এনটিপিকিউ এবং ক্রোনী প্রদর্শন বিচ্ছুরণ এবং সেকেন্ডের মধ্যে মূল বিচ্ছুরণ, যা মানুষ সন্ধান করতে অভ্যস্ত, এনটিপিপ্লিয়েন্ট এটি মাইক্রোসেকেন্ডগুলিতে প্রদর্শন করে । নির্বিশেষে, 1217163 এর মান এখনও বেশ বেশি। একটি ভাল এনটিপি সার্ভার কয়েক মিলিসেকেন্ডের মধ্যে সময় জানে; কয়েক দশক বা শত শত মিলিসেকেন্ডের মধ্যে একটি খারাপ। ইতিমধ্যে আপনাকে বলছে যে এর সময়টি কেবলমাত্র +/- 1.2 সেকেন্ডের মধ্যে বিশ্বাস করা যায়।

আপনি প্রকৃতপক্ষে এই সার্ভারের সাথে সিঙ্ক্রোনাইজ করার জন্য এনটিপি পেতে পারেন -x 0বা -tবিকল্পটি (এনটিপিপ্লিনেন্টের সংস্করণের উপর নির্ভর করে) পাস করে যা এনটিপি স্যানিটি চেকগুলি অক্ষম করে। আপনার যদি কেবল মোটামুটি সঠিক সময় (কয়েক সেকেন্ডের মধ্যে) প্রয়োজন হয় তবে তা যথেষ্ট ভাল হতে পারে। তবে, এই জাতীয় খারাপ সার্ভারের সাথে সিঙ্ক্রোনাইজ করতে অস্বীকার করার ক্ষেত্রে এনটিপিপ্লিয়েন্ট বেশ যুক্তিসঙ্গত। ntpqউবুন্টু মেশিনে আপনার আউটপুটটি তার সমস্ত সার্ভারের জন্য কয়েকশ মিলি সেকেন্ডের এক ঝাঁকুনি দেখায়, যদিও তাদের বিলম্ব কম রয়েছে, যা খুব অবিশ্বাস্য নেটওয়ার্ককে নির্দেশ করে, সমস্ত সার্ভারের অনিয়মিত সময় সরবরাহের ষড়যন্ত্র বা একটি মৌলিক সার্ভারে টাইমকিপিংয়ের সমস্যা।

এটি আমার সম্পর্কেও উদ্বেগ প্রকাশ করে যে সার্ভারটি 10.31.10.22 LOCL( অপ্রচলিত স্থানীয় ঘড়ি) এর একটি রেফিটের বিজ্ঞাপন দিচ্ছে তবে এর স্তর 1 টি রয়েছে Usually সাধারণত স্থানীয় ঘড়িটি 10 ​​টি স্ট্র্যাটামে থাকে যাতে এটি কেবল সর্বশেষ-রিসোর্ট সিঙ্ক্রোনাইজেশন উত্স হিসাবে ব্যবহৃত হয় একটি ঝাঁক দূরে রাখা থেকে রাখা হয় 10.31.10.22 হয় ভুল কনফিগার্ড করা এবং নেটওয়ার্কের বাকী অংশগুলিকে খারাপ সময় সরবরাহ করা, বা এটি LOCLএনটিপির নিয়ন্ত্রণের বাইরে কোনও প্রোগ্রাম দ্বারা ভাল সময়কে শৃঙ্খলাবদ্ধ করা হচ্ছে, সেক্ষেত্রে ভুল কনফিগারেশনটি কেবল রেফিটকে বিজ্ঞাপন দিচ্ছে; এটি যেমন GPSবা যা তার সময় সরবরাহ করে তা ওভাররাইড করা উচিত ।


চমত্কার উত্তর। আমি চেষ্টা করব -x 0বা -tআবার রিপোর্ট করব। সম্পর্কিত 10.31.10.22, আমি এটি সার্ভারের তালিকা থেকে বাইরে নিয়ে যেতে পারি। দুর্দান্ত ধরা এই সার্ভারগুলি সম্পর্কে আমার কাছে সত্যিই কোনও তথ্য নেই, কোনও এনটিপি সার্ভারের থেকে বিশদ পাওয়ার জন্য অন্য কোনও ডিবাগ কমান্ড রয়েছে নাকি এটি বেশ কিছুটা ntpq -p?
জেফ

যেমনটি আপনি বলেছেন, -tস্যুইচটি উচ্চ বিস্তৃতি সত্ত্বেও ইন-হাউস এনটিপি সার্ভারকে বিশ্বাস করে। এটি এলোমেলোভাবে কেন এর মতো শীর্ষে যায় তা আমরা এখনও ব্যাখ্যা করতে পারি না তবে এটি অন্য পোস্টের জন্যও হতে পারে। ধন্যবাদ.
জেফ


12

"বিচ্ছুরণ কী?" এর জন্য কেবল একটি আংশিক উত্তর

একটি সাধারণ এনটিপি রাউন্ড ট্রিপ:

client |        | server
    t1 |------->| t2
    t3 |<-------| t4

এটি দুটি সূত্র দেয়, অফসেট (ক্লায়েন্ট এবং সার্ভারের মধ্যে সময়ের পার্থক্য) এবং নিম্নলিখিত সূত্রগুলির সাথে বিলম্ব (নেটওয়ার্ক ভ্রমণের সময় প্রয়োজনীয়):

offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)

ক্লায়েন্ট সর্বশেষতম 8 টি প্যাকেট প্রাপ্ত বর্তমান অফসেটটি নির্বাচন করে, সবচেয়ে ছোট বিলম্বের সাথে একটিটি বেছে নেয়।

একই 8 টি প্যাকেটগুলি শেষ ধাপে নির্বাচিত একটিতে এই 8 অফসেটের পার্থক্যের একটি ওজনিত গড়ের মাধ্যমে বিস্তারের গণনা করতে ব্যবহৃত হয় , যেখানে দেরিটি ওজনকে ফ্যাক্টর হিসাবে ব্যবহৃত হয়, আরও ছোট ও বিলম্বকে আরও বেশি ওজন দেয়। এটি মানগুলির "স্প্রেড" এর জন্য একটি পরিমাপ এবং একটি টাইম সার্ভারের গুণমান গণনা করতে ব্যবহৃত হয়, বিশেষত যদি আপনার পছন্দমতো একাধিক থাকে।


সূত্র সম্পর্কে নিশ্চিত? সর্বোপরি, কেবলমাত্র T4-t2 এবং t3-t1 জড়িত পক্ষগুলির পক্ষে জ্ঞাত
হেজেন ভন ইটজেন

@ হ্যাগেনভোন এটজেন সময়টি প্যাকেটে অন্তর্ভুক্ত করা যেতে পারে
টমাস

@ তবে আমিও বিশ্বাস করি যে সূত্রগুলির সাথে একটি সমস্যা আছে; দেখতে এখানে পৃষ্ঠা 28 এবং এই শ্বেতপত্র , উভয় মিলস দ্বারা। যেভাবে আপনি আপনার টি তৈরি করেছেন, তা হওয়া উচিত offset = 1/2 * [(T2-T1) + (T4-T3)]এবং `বিলম্ব = (টি 3-টি 1) - (টি 4-টি 2) '
ইয়ান রিলে

সোভেন, t3/t4আপনি সাধারণত রাউন্ড ট্রিপটিতে সঠিক জায়গায় থাকেন? ট্র্যাফিক প্রবাহ এবং বিলম্বের গণনা থেকে বোঝা যাচ্ছে যে এগুলি অন্যভাবে t4 -t1হওয়া উচিত : মোট আরটিটি t3-t2হওয়া উচিত, সার্ভারের অভ্যন্তরে কাটানো সময় হওয়া উচিত।

7

আপনার ছড়িয়ে পড়া এবং স্কিউ প্রচুর, স্থানীয় ঘড়ি থেকে সেই পিয়ারের কাছে খুব বড় অফসেট রয়েছে। আপনার অফসেটগুলি লোকালটির সাথে তুলনা করা উচিত dateএবং ঘড়িটি ম্যানুয়ালি সেট করা উচিত।

এনটিপিডি দৌড়াদৌড়ি পান এবং ntpq -pসহকর্মীদের সকলটি ব্যবহার করে কোনও হোস্ট থেকে দেখান । এটি আরও ভালগুলি নির্বাচন করবে।


যোগ করা হয়েছে ntpq -pnআমার প্রশ্ন আউটপুট। এটি দেখার জন্য আপনাকে ধন্যবাদ।
জেফ

4
আর অফসেটে ও শতকরা জিটার? এটা খুব ভাল না। আপনি পুল.ntp.org এর মতো ইন্টারনেট উত্সগুলিতে কোনও অ্যাক্সেসের কথা উল্লেখ করেননি তবে সেগুলি আরও ভাল সম্পাদন করে। জিপিএস, একটি রেডিও উত্স, একটি পিপিএস ইনপুট বা অনুরূপ মতো একটি রেফারেন্স ক্লক যুক্ত করার বিষয়টি বিবেচনা করুন। অথবা এমন কোনও স্থানীয় ঘড়ি সহ হোস্ট চয়ন করুন যা পুরো জায়গা জুড়ে নয়।
জন মাহোয়াল্ড

5

এই সিসকো ডকুমেন্টেশন অনুসারে , " সেকেন্ডে রিপোর্ট হওয়া বিচ্ছুরণ হ'ল সর্বাধিক ঘড়ির সময়ের পার্থক্য যা স্থানীয় ঘড়ি এবং সার্ভার ঘড়ির মধ্যে কখনও দেখা যায়"। সম্পূর্ণরূপে ভাঙ্গা নয় এমন এনটিপি সার্ভারগুলির সাথে, একটি উচ্চ ছড়িয়ে পড়া কখনই ঘটবে না। কেবলমাত্র সম্ভাব্য দৃশ্যটি যখন আপনার ক্লায়েন্টটি এনটিপি প্রবেশ করে এবং এখন পর্যন্ত কেবলমাত্র তার স্থানীয় ঘড়ি উপলব্ধ থাকে available এবং তারপরেও, আপনি প্রতিবেদন করেছেন তত বেশি ছড়িয়ে ছিটিয়ে থাকা ঘড়ির সাথে মিল রয়েছে যা দুটি সপ্তাহেরও বেশি সময় বন্ধ রয়েছে ।

এটি নিশ্চিত করার জন্য পর্যাপ্ত হওয়া উচিত যে স্থানীয় ঘড়ি শুরুতে খুব বেশি দূরে নয় (এমনকি কয়েক ঘন্টা এখনও গ্রহণযোগ্য হবে), হয় বিআইওএস-এ ঘড়িটি (এবং তারিখ এমনকি!) সামঞ্জস্য করে বা ntpdateশুরু করার আগে একবার জারি করে ntpdক্লায়েন্ট উপর।


1
এনটিপিপ্লিয়েন্ট মাইক্রোসেকেন্ডগুলিতে মানগুলি প্রতিবেদন করছে, সুতরাং তালিকাভুক্ত ছড়িয়ে পড়াটি আসলে actually 1.2 সেকেন্ড নয়, সপ্তাহ নয় :) এছাড়াও, সিসকো ডকের ব্যাখ্যাটি এই মানটির সাথে প্রযোজ্য নয়।
hobbs
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.