এমএমওআরপিজি সার্ভার রক্ষণাবেক্ষণ


14

দেখে মনে হয় বেশিরভাগ মিম্পোরপিজ গেমগুলির কিছু নিয়মিত সার্ভার রক্ষণাবেক্ষণ থাকে, কিছু প্রতিদিন, কিছু সপ্তাহে একবার। এটি আসলে তাদের কী করতে হবে এবং এটি কেন প্রয়োজনীয়?

আপনি যদি এই জাতীয় প্রকল্প দিয়ে শুরু করেন তবে এড়াতে আপনি কী করতে পারেন?

উত্তর:


17

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

আমি মনে করি একটি হট-প্যাচিং সিস্টেম তৈরি করা সম্ভব তবে এটি অবিশ্বাস্যরকম জটিল হবে। আমি যা বুঝি সেগুলি থেকে, একটি এমএমও সার্ভার "অ্যাপ্লিকেশন" বিভিন্ন ধরণের বিভিন্ন উপাদান নিয়ে গঠিত -

  • লগইন সার্ভার - প্রমাণীকরণ পরিচালনা করে এবং গেমপ্লে সার্ভারগুলির মধ্যে একটি "হাব" হিসাবে কাজ করে। কোনও ক্লায়েন্ট একবার খেলাতে গেলে তারা আর লগইন সার্ভারের সাথে ইন্টারঅ্যাক্ট করে না। এই জাতীয় সিস্টেমে আপনি প্যাচগুলি প্রয়োগ করতে এবং গেমপ্লেতে হস্তক্ষেপ না করে লগইন সার্ভার পুনরায় চালু করতে পারেন (যদিও আপনার এমন একটি সময় থাকবে যেখানে লোকেরা লগ ইন করতে পারবে না)।

  • গেমপ্লে সার্ভার - মেশিনগুলির ক্লাস্টারগুলি যৌক্তিক স্বতন্ত্র ইউনিটে ("ওয়ার্ল্ডস" ইত্যাদিতে) গোষ্ঠীভুক্ত। এটি অনুমান করা হয় যে প্রতিটি গেমপ্লে ক্লাস্টার একে অপরের সাথে রাষ্ট্রের সাথে যোগাযোগ করতে কিছু প্রকার অভ্যন্তরীণ যোগাযোগ প্রোটোকল ব্যবহার করে; আপনার সম্ভবত প্রতিটি ক্লাস্টারটি একবারে প্যাচ করতে হবে। এটি করার একটি সম্ভাব্য উপায় হ'ল উষ্ণ-ব্যর্থতা প্যাচ করা। আপনার তখন উভয়ের পক্ষে সক্ষম হবেন

    1. উষ্ণ ব্যর্থতার সাথে সংযোগ স্থাপন করতে এবং পুরানো ক্লাস্টার থেকে সংযোগ বিচ্ছিন্ন করতে ক্লায়েন্টকে সিগন্যাল করুন।
    2. সমস্ত ক্লায়েন্ট স্থানান্তর করার সময় ব্যর্থতা এবং পুরানো অ্যাপ্লিকেশন সার্ভারের মধ্যে রাষ্ট্রকে সিঙ্ক করুন।
  • ডেটাবেস সার্ভার - কিছুটা ধ্রুবক ডেটাস্টোর, যেমন একটি আরডিবিএমএস। আশা করি আপনি প্রায়শই ডাটাস্টোরে পরিবর্তন করছেন না। সম্ভবত প্রতিটি গেমপ্লে সার্ভার / ক্লাস্টারের একটি আলাদা ডেটাস্টোর থাকে। আপনি উষ্ণ ব্যর্থতার সাথে একই কৌশলটি ব্যবহার করতে সক্ষম হতে পারেন (এবং গেমপ্লে সার্ভারগুলিকে সংযোগ বিচ্ছিন্ন করতে, পুরাতন এবং ফেইলওভার ডেটাবেসগুলি সিঙ্ক করার জন্য অপেক্ষা করুন, তারপরে ব্যর্থতার সাথে পুনরায় সংযোগ স্থাপন করুন) তবে এটি আমার কাছে বেশ ঝুঁকিপূর্ণ বলে মনে হয়।

উপরের সমস্ত ক্ষেত্রে ইতিমধ্যে একটি জটিল সিস্টেমে অবিশ্বাস্য পরিমাণ জটিলতা যুক্ত করে এমন একটি জায়গার প্রচলন করা হয় যেখানে কোড ব্যর্থতা ডেটা ক্ষতি বা দুর্নীতির কারণ হতে পারে।

আর একটি সমাধান হ'ল এমন একটি ভাষা ব্যবহার করা যা 100% আপটাইমের জন্য ডিজাইন করা এবং হটপ্যাচিং চলমান কোডের জন্য অন্তর্নির্মিত সক্ষমতা রয়েছে। এরলং একটি ভাল পছন্দ ( হটপ্যাচিং উদাহরণ ) এবং জাভাতে একই রকম কার্যকারিতা রয়েছে


12

অন্য কারও কাছে আসলে এমন কিছু চালানোর অভিজ্ঞতা নেই? হাহ।

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

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

আমার সাথে সবচেয়ে বেশি অভিজ্ঞতা আছে (আমি একজন যুদ্ধক্ষেত্রের লোকের চেয়ে লেজারের লোকের চেয়ে বেশি), সুতরাং এর কয়েকটি উদাহরণ আরও পূর্ব-পূর্বমুখী।

সিস্টেমের কারণগুলি যতদূর যেতে পারে:

  • শারীরিক নোডগুলি ধারাবাহিকভাবে ব্যর্থ হয়। যখন কোনও নোড ব্যর্থ হয়, সাধারণত এটির ক্রিয়াকলাপ যে কোনও উপায় ব্যবহার করে অন্যত্র স্থানান্তরিত হয় mig তবে নোডটিকে যত তাড়াতাড়ি সম্ভব আবার পরিষেবাতে ফেলা দরকার। ইভির ক্ষেত্রে, তারা স্ট্যাকলেস প্রসেসিং ভাষা এবং ভার্চুয়াল সার্ভার উভয়ই ব্যবহার করে; আমি নিশ্চিত নই যে ব্লিজার্ডের আর্কিটেকচার কেমন।
  • ডাটাবেস ধারাবাহিকতা পরীক্ষা করা প্রয়োজন, লগগুলি ফ্লাশ করা প্রয়োজন এবং সূচি এবং ডেটা ক্যাশে পুনর্নির্মাণ করা প্রয়োজন। এটি কেবলমাত্র একটি "লাইভ" ডাটাবেস উদাহরণ সহ EVE এর মতো সিস্টেমে গুরুত্বপূর্ণ।
  • অপারেটিং সিস্টেম প্যাচগুলি এমন সময়ে প্রয়োগ করা দরকার যখন তারা খুব বেশি ক্রিয়াকলাপ অন্য কোথাও স্থানান্তর না করে নোডগুলি রিবুট করতে পারে। মাইগ্রেশন অনেকগুলি নেটওয়ার্ক সংস্থান গ্রহণ করে যা অন্যথায় অনলাইন প্রসেসিংয়ের জন্য উত্সর্গ করা যেতে পারে।
  • আরডিবিএমএস-ভিত্তিক এমএমওগুলির ডেটা লকিং এবং রেফারেনশিয়াল অখণ্ডতা নিয়ে বিশাল সমস্যা রয়েছে। ডাউনটাইম ক্রিয়াকলাপ লগগুলি থেকে অবিচলিত লকগুলি এবং সততা বিরতিগুলি পরিষ্কার করতে ব্যবহৃত হয়।
  • বেশিরভাগ গেম ভারী ব্যবহারের ক্ষেত্রগুলিতে, যেমন পূর্ব উপকূল বনাম পশ্চিম উপকূল মার্কিন যুক্তরাষ্ট্রে স্থিতিশীল বা আধা-স্থির জন্য (নীচে ক্যাচিং সংক্ষিপ্ত বিবরণ দেখুন) জন্য ভৌগোলিকভাবে নির্ধারিত ডেটা ক্যাশে প্রয়োগ করে। এই ক্যাশগুলি ডাউনটাইমের সময় ম্যানুয়ালি আপডেট হয়।

সফ্টওয়্যার কারণ হিসাবে:

  • গেমস, অপারেটিং করার সময়, প্রচুর ওলটিপি ব্যবহার করে - এটি অন লাইন লেনদেন প্রক্রিয়াজাতকরণ - ডাটাবেসে পাঠানোর / লেখার ধরণ। তবে, কখনও কখনও আপনি সংক্ষিপ্তসার প্রতিবেদন চান ... যেমন আপনি গত 3 বছরের গ্রাইন্ডিংয়ে কতটা নির্দিষ্ট জন্তুকে হত্যা করেছেন like এটি একটি ওএলএপি রিপোর্ট দ্বারা সর্বোত্তমভাবে পরিচালিত হয় - এটি অন লাইন অ্যানালিটিকাল প্রসেসিং - যা দানবিক ডেটাসেটে প্রচুর সারি ভিত্তিক সংক্ষিপ্তসার তথ্য রয়েছে। বাস্তবে, গেমগুলি এমন সিস্টেমগুলি প্রয়োগ করে যেগুলি পড়ার প্রয়োজন এমন প্রশ্নের সংখ্যা সীমাবদ্ধ করতে ক্যাশ তৈরি করতে OLAP ব্যবহার করে - যেমন, তারা একটি নির্দিষ্ট তারিখের মতো মোট তৈরি করে এবং আপনি যখন প্রশ্নটি জিজ্ঞাসা করেন তারা কেবল সারিগুলি পড়েন ওয়ালটিপি স্টোর থেকে নির্দিষ্ট সময়ের থেকে সময়কাল সংক্ষিপ্তসার করা হয়েছে। দু'জনকে মার্জ করুন এবং আপনার জীবনটি কতটা নিরর্থক হয়ে উঠেছে তা আপনি প্রকৃতপক্ষে প্রমাণ করতে পারেন।
  • পূর্বোক্ত হট-প্যাচিং, যা আমি একটি সফ্টওয়্যার সমস্যা হিসাবে দেখি তবে সফ্টওয়্যার বিকাশকারীরা সিস্টেম সমস্যা হিসাবে দেখেন। ;)
  • আইটেমগুলির পুনরায় পূরণের স্টোর - ইভটিতে গ্রহাণু বেল্টগুলি প্রতি রাতে সতেজ করা হয় এবং নির্দিষ্ট কিছু কমপ্লেক্সগুলিও পুনর্ব্যবহার করা হয়। এটি অন-লাইনের সময় কিছুটা হলেও করা যেতে পারে তবে কিছু অ্যালগরিদম খুব জটিল এবং অফ-লাইন মোডে করা দরকার কারণ তারা আগের দিনের অর্থনৈতিক ক্রিয়াকলাপের সংক্ষিপ্তসারের সময় সংক্ষেপে ডাটাবেসটিকে তার হাঁটুর কাছে নিয়ে আসে।

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

আপনি যদি খেয়াল করেন, ইভটির রক্ষণাবেক্ষণটি ইংল্যান্ডের দুপুর যখন হয়, যেখানে প্রাথমিক ডাটাসেন্টার।


3

আমি সন্দেহ করি যে বরফখণ্ড (রক্ষণাবেক্ষণের জন্য মঙ্গলবার সকালে যে আপনি আপনার প্রশ্ন পোস্ট করছেন) এটির পুরো সময়টি পুরো ক্লাস্টারের জন্য; প্রতিটি সার্ভার কাজ সম্পাদন করতে দীর্ঘ সময় নেয় না।

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

কেন তারা রক্ষণাবেক্ষণ সম্পাদন করে, এগুলির কিছুটি কেবল একটি পারফরম্যান্স রিবুট হতে পারে। যদিও এটি দুর্দান্ত হবে যদি এই ধরনের রিবুটগুলি প্রয়োজন না হয় তবে এটি না করার প্রভাব বনাম এমন করার ব্যয়টি তাদের পছন্দকে এখানে নির্দেশিত করে।

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

শেষ পর্যন্ত, সেই বৃহত গ্রাহক বেসকে রাষ্ট্রীয় অনলাইন পরিষেবা সরবরাহ করার মেকানিক্স কোনও ওয়েবসাইট বা অন্যান্য traditionalতিহ্যবাহী ইন্টারনেট-ভিত্তিক পরিষেবা সম্পর্কে কথা বলার সময় আমরা যে কয়েকটি সেরা অভ্যাসগুলি গ্রহণ করতে পারি তা চ্যালেঞ্জ করে।


আসলে, বেশিরভাগ চ্যালেঞ্জগুলি সেই কেন্দ্রীয় রাজ্য-রক্ষণাবেক্ষণ নোড, ডাটাবেসকে ঘিরে। এটিই অনুমোদনের রেকর্ড। অন্যান্য সমস্ত জিনিস যা রাষ্ট্র পরিচালনা করে বলে মনে হয় (সার্ভার, ক্লায়েন্ট এবং এর মধ্যে থাকা কোনও ক্যাশেিং সিস্টেম) তা কেবল ডেটাবেসে কোনও ডেটা তৈরি করে সে সম্পর্কে কেবল আলোচক। ল্যাগ এমন সময় যা এটি রেকর্ড করেছে তা শৃঙ্খলার পিছনে নিশ্চিত করতে ডাটাবেস গ্রহণের সময়।
কার্ল কাটজ্কে

1

এভিই অনলাইনে সাম্প্রতিক কিছু বাড়ানো ডাউনটাইমগুলির মধ্যে একটি দ্রুত এসএএন এর মতো নতুন হার্ডওয়্যার ইনস্টল করার বিষয়ে ছিল। যখন কেউ নতুন ড্রাইভে নতুন ফাইলগ্রুপ তৈরি করে এবং তারপরে মূলটি খালি করে প্রযুক্তিগতভাবে ডেটা সর্বাধিক স্থানান্তর করতে পারে, তার ফলে ধ্রুবক I / O এর কারণে কর্মক্ষমতা হ্রাস পেতে পারে of সুতরাং তারা 1.1TB ডাটাবেস পৃথক করে এটিকে একযোগে সরিয়ে নেওয়ার বিকল্প বেছে নিয়েছে

এই প্রশ্নের উত্তরও নির্দিষ্ট প্রয়োগের উপর নির্ভর করে। উদাহরণস্বরূপ, একটি নির্দিষ্ট তারকা সিস্টেম পরিচালনা করে এমন একটি সার্ভার গেম প্লে ব্যাহত না করে হটস্যাপ করা যায় না, সুতরাং ডাউনটাইমটি সম্ভাব্য হটস্পটে আরও শক্তিশালী সার্ভারগুলি পুনরায় সাইন ইন করতে ব্যবহৃত হয়। এছাড়াও, তারা সিস্টেমগুলির মালিকানা গণনা (সার্বভৌমত্ব) গণনা করা হয়। এটি দশক বিভিন্ন ভেরিয়েবলের উপর নির্ভর করে, যা প্লেয়ারের ক্রিয়াগুলির উপর নির্ভর করে সমস্ত পরিবর্তন করতে পারে। বলার অপেক্ষা রাখে না যে লাইভটি করা অতিরিক্ত মাত্রায় লকিং এবং / বা অন্যান্য সমঝোতার সমস্যার কারণ হতে পারে। কিন্তু সেরা ছেড়ে দেওয়া হয় অ্যাড্রেসিং Stackoverflow


ভার্চুয়ালাইজেশনের মাধ্যমে আরও উপলব্ধ সংস্থান সহ ভার্চুয়েড লোড করা সার্ভারগুলি হার্ডওয়ারে স্থানান্তরিত করার জন্য সরাসরি এবং স্বয়ংক্রিয়ভাবে করা বেশ সম্ভব হওয়া উচিত ... বিশেষত এমন একটি খেলায় যেখানে বেশিরভাগ অ্যাকশন ল্যাগটি অনেক মিলিসেকেন্ডে (কখনও কখনও একশো শতাধিক) পরিমাপ করা হয়। তবে এটি জটিল এবং ব্যয়বহুল হতে পারে
Os

ওসকার, মনে রাখবেন যে ইভিও এবং ওউ এর পিছনে মূল প্রযুক্তিটি 2002 সালে প্রায় লেখা হয়েছিল, এই প্রযুক্তিগুলি সত্যই পরিপক্ক হওয়ার আগে।
কার্ল কাটজকে

0

সম্ভবত এমন কিছু যা আপনি ক্লাস্টারিং / লোড-ব্যালান্সিংয়ের মাধ্যমে যেমন বড় ডিবি স্কিমা পরিবর্তনের মাধ্যমে মোকাবেলা করতে পারেন নি।


0

সাম্প্রতিক বিষয়ে আমি লিনাক্স সার্ভারগুলিকে পুনরায় বুট করার আরও একটি ভাল পয়েন্ট উল্লেখ করা হয়েছিল, যা যাচাই করে যা পুনরায় বুট করার পরে বা কোনও (বড়) কনফিগারেশন পরিবর্তনের পরে সবকিছু সঠিকভাবে শুরু হয়।


0

এমএমওআরপিজি গেমস দ্বারা হার্ডওয়্যার (বা হার্ডওয়্যার রিপ্লেসমেন্ট) এর একটি সাধারণ আপগ্রেডকে "সার্ভার রক্ষণাবেক্ষণ" হিসাবে উপস্থাপন করা হয়েছে। তাই তুচ্ছ আমরা প্রায়শই ভুলে যাই।


0

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

আপনি http://www.next-gen.cc এ আমার সাইটটি পরীক্ষা করে দেখতে পারেন ।


0

আমি বিশ্বাস করি যে রক্ষণাবেক্ষণ উইন্ডোটি নিয়মিত হার্ডওয়্যার প্রতিস্থাপনের জন্য উপাদানগুলি যাতে ব্যর্থ না হয় তা নিশ্চিত করে।


সাধারণত না। তারা হার্ডওয়্যারে কিছু ভবিষ্যদ্বাণীমূলক মেট্রিক চালাবে, তবে তারা সাধারণত কোনও সিস্টেমে সমস্ত অনুরাগী বা অন্যান্য 'ব্যয়যোগ্য' বিটগুলি সক্রিয়ভাবে প্রতিস্থাপন করে না যতক্ষণ না এটি ব্যর্থ হওয়ার লক্ষণগুলি দেখায়, অর্থাত RPM গুলি নামছে বা স্মার্ট একটি উচ্চ রাইনের ত্রুটি গণনা দেখায় না।
কার্ল কাটজকে
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.