🥇Тarantool কার্তুজ: তিন লাইনে লুয়া ব্যাকএন্ডের শারডিং

Mail.ru গ্রুপে আমাদের আছে Tarantool - এটি Lua-এ একটি অ্যাপ্লিকেশন সার্ভার, যা ডাটাবেস হিসেবেও দ্বিগুণ হয় (অথবা বিপরীত?)। এটি দ্রুত এবং দুর্দান্ত, তবে একটি সার্ভারের ক্ষমতা এখনও সীমাহীন নয়। উল্লম্ব স্কেলিংও একটি প্রতিষেধক নয়, তাই ট্যারান্টুলের অনুভূমিক স্কেলিং-এর জন্য সরঞ্জাম রয়েছে - vshard মডিউল [1]. এটি আপনাকে বিভিন্ন সার্ভার জুড়ে ডেটা শার্ড করার অনুমতি দেয়, তবে এটি সেট আপ করতে এবং ব্যবসায়িক যুক্তি সংযুক্ত করতে আপনাকে এটির সাথে টিঙ্কার করতে হবে।

সুসংবাদ: আমরা কিছু বড় শট সংগ্রহ করেছি (যেমন [2], [3]) এবং অন্য একটি কাঠামো তৈরি করেছে যা এই সমস্যার সমাধানটিকে উল্লেখযোগ্যভাবে সরল করবে।

ট্যারান্টুল কার্টিজ জটিল বিতরণ সিস্টেম উন্নয়নের জন্য একটি নতুন কাঠামো. এটি আপনাকে অবকাঠামোগত সমস্যা সমাধানের পরিবর্তে ব্যবসায়িক যুক্তি লেখার উপর ফোকাস করতে দেয়। কাটের নীচে আমি আপনাকে বলব কিভাবে এই ফ্রেমওয়ার্ক কাজ করে এবং কীভাবে এটি ব্যবহার করে বিতরণ করা পরিষেবাগুলি লিখতে হয়।

এবং কি, ঠিক, সমস্যা?

আমাদের একটি ট্যারান্টুলা আছে, আমাদের ভিশার্ড আছে - আপনি আর কি চান?

প্রথমত, এটি সুবিধার বিষয়। vshard কনফিগারেশন Lua টেবিলের মাধ্যমে কনফিগার করা হয়। সঠিকভাবে কাজ করার জন্য একাধিক ট্যারান্টুল প্রক্রিয়াগুলির একটি বিতরণ করা সিস্টেমের জন্য, কনফিগারেশনটি সর্বত্র একই হতে হবে। কেউ ম্যানুয়ালি এটি করতে চায় না। অতএব, সমস্ত ধরণের স্ক্রিপ্ট, উত্তরযোগ্য এবং স্থাপনার সিস্টেম ব্যবহার করা হয়।

কার্টিজ নিজেই vshard কনফিগারেশন পরিচালনা করে, এটি তার উপর ভিত্তি করে এটি করে নিজস্ব বিতরণ কনফিগারেশন. এটি মূলত একটি সাধারণ YAML ফাইল, যার একটি অনুলিপি প্রতিটি Tarantool উদাহরণে সংরক্ষণ করা হয়। সরলীকরণ হল যে ফ্রেমওয়ার্ক নিজেই তার কনফিগারেশন নিরীক্ষণ করে এবং নিশ্চিত করে যে এটি সর্বত্র একই।

দ্বিতীয়ত, এটা আবার সুবিধার বিষয়। ব্যবসায়িক যুক্তির বিকাশের সাথে vshard কনফিগারেশনের কোন সম্পর্ক নেই এবং শুধুমাত্র প্রোগ্রামারকে তার কাজ থেকে বিভ্রান্ত করে। যখন আমরা একটি প্রকল্পের আর্কিটেকচার নিয়ে আলোচনা করি, আমরা প্রায়শই পৃথক উপাদান এবং তাদের মিথস্ক্রিয়া সম্পর্কে কথা বলি। 3টি ডেটা সেন্টারে একটি ক্লাস্টার চালু করার বিষয়ে চিন্তা করা খুব তাড়াতাড়ি।

আমরা এই সমস্যাগুলি বারবার সমাধান করেছি, এবং কিছু সময়ে আমরা এমন একটি পদ্ধতির বিকাশ করতে পেরেছি যা অ্যাপ্লিকেশনটির সাথে তার সমগ্র জীবনচক্র জুড়ে কাজকে সহজ করে তোলে: সৃষ্টি, বিকাশ, পরীক্ষা, CI/CD, রক্ষণাবেক্ষণ।

কার্টিজ প্রতিটি ট্যারান্টুল প্রক্রিয়ার জন্য একটি ভূমিকার ধারণা প্রবর্তন করে। ভূমিকা এমন একটি ধারণা যা একজন বিকাশকারীকে কোড লেখার উপর ফোকাস করতে দেয়। প্রকল্পে উপলব্ধ সমস্ত ভূমিকা একটি Tarantool উদাহরণে চালানো যেতে পারে, এবং এটি পরীক্ষার জন্য যথেষ্ট হবে।

ট্যারান্টুল কার্টিজের মূল বৈশিষ্ট্য:

স্বয়ংক্রিয় ক্লাস্টার অর্কেস্ট্রেশন;
নতুন ভূমিকা ব্যবহার করে অ্যাপ্লিকেশনের কার্যকারিতা প্রসারিত করা;
উন্নয়ন এবং স্থাপনার জন্য অ্যাপ্লিকেশন টেমপ্লেট;
অন্তর্নির্মিত স্বয়ংক্রিয় শার্ডিং;
Luatest টেস্টিং ফ্রেমওয়ার্কের সাথে একীকরণ;
WebUI এবং API ব্যবহার করে ক্লাস্টার ব্যবস্থাপনা;
প্যাকেজিং এবং স্থাপনার সরঞ্জাম।

ওহে বিশ্ব!

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

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

এই দুটি কমান্ড কমান্ড লাইন ইউটিলিটিগুলি ইনস্টল করবে এবং আপনাকে টেমপ্লেট থেকে আপনার প্রথম অ্যাপ্লিকেশন তৈরি করার অনুমতি দেবে:

$ cartridge create --name myapp

এবং আমরা যা পাই তা হল:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

এটি একটি রেডিমেড "হ্যালো, ওয়ার্ল্ড!" সহ একটি গিট সংগ্রহস্থল। আবেদন আগে নির্ভরতা ইনস্টল করে (ফ্রেমওয়ার্ক নিজেই সহ): আসুন এখনই এটি চালানোর চেষ্টা করি:

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

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

অ্যাপ্লিকেশন ডেভেলপমেন্ট

শুধু কল্পনা করুন, আমরা এমন একটি প্রকল্প ডিজাইন করছি যা অবশ্যই ডেটা গ্রহণ করবে, এটি সংরক্ষণ করবে এবং দিনে একবার একটি প্রতিবেদন তৈরি করবে।

আমরা একটি ডায়াগ্রাম আঁকা শুরু করি এবং এটিতে তিনটি উপাদান রাখি: গেটওয়ে, স্টোরেজ এবং সময়সূচী। আমরা আরও স্থাপত্য নিয়ে কাজ করছি। যেহেতু আমরা স্টোরেজ হিসাবে vshard ব্যবহার করি, আমরা স্কিমে vshard-রাউটার এবং vshard-storage যোগ করি। গেটওয়ে বা সময়সূচী উভয়ই সঞ্চয়স্থানে সরাসরি অ্যাক্সেস করবে না; রাউটারটি এর জন্যই এটি তৈরি করা হয়েছিল।

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

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

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

এবং যখন স্টেজিং বা উৎপাদনে স্থাপনার কথা আসে, তখন আমরা হার্ডওয়্যার ক্ষমতার উপর নির্ভর করে প্রতিটি ট্যারান্টুল প্রক্রিয়াকে তার নিজস্ব ভূমিকা নির্ধারণ করব:

টপোলজি ব্যবস্থাপনা

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

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

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

ভূমিকার জীবন

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

function init()
function validate_config()
function apply_config()
function stop()

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

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

ক্লাস্টার কল validate_config и apply_config প্রতিবার বিতরণকৃত কনফিগারেশন পরিবর্তন হয়। যখন একটি কনফিগারেশন একটি দ্বি-পর্যায়ের প্রতিশ্রুতি দ্বারা প্রয়োগ করা হয়, ক্লাস্টারটি পরীক্ষা করে যে প্রতিটি ভূমিকা এই নতুন কনফিগারেশনটি গ্রহণ করার জন্য প্রস্তুত এবং প্রয়োজনে ব্যবহারকারীকে একটি ত্রুটি রিপোর্ট করে। যখন সবাই একমত যে কনফিগারেশন স্বাভাবিক, তারপর apply_config.

ভূমিকারও একটি পদ্ধতি আছে stop, যা ভূমিকার আউটপুট পরিষ্কার করার জন্য প্রয়োজন। যদি আমরা বলি যে এই সার্ভারে শিডিউলারের আর প্রয়োজন নেই, তবে এটি সেই ফাইবারগুলিকে থামাতে পারে যা এটি দিয়ে শুরু হয়েছিল init.

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

আরেকটি গুরুত্বপূর্ণ বিষয় হচ্ছে দোষ সহনশীলতা নিশ্চিত করা। কার্টিজ স্বাস্থ্য নিরীক্ষণের জন্য SWIM প্রোটোকল ব্যবহার করে [4]. সংক্ষেপে, প্রক্রিয়াগুলি UDP-এর মাধ্যমে একে অপরের সাথে "গুজব" বিনিময় করে - প্রতিটি প্রক্রিয়া তার প্রতিবেশীদের সর্বশেষ খবর জানায় এবং তারা প্রতিক্রিয়া জানায়। হঠাৎ উত্তর না আসলে, তারান্টুল সন্দেহ করতে শুরু করে যে কিছু ভুল হয়েছে, এবং কিছুক্ষণ পরে এটি মৃত্যুর আবৃত্তি করে এবং আশেপাশের সবাইকে এই খবর জানাতে শুরু করে।

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

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

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

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

স্থাপনার সরঞ্জাম

আমি দেখানোর প্রতিশ্রুতি দিয়েছিলাম কিভাবে কার্টিজ অ্যাপ্লিকেশন স্থাপনে সাহায্য করে। অন্যদের জীবন সহজ করতে, ফ্রেমওয়ার্ক প্যাকেজ RPM প্যাকেজ:

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

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

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

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

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

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

কনফিগারেশনে, আমরা HTTP পোর্ট নির্দিষ্ট করেছি যেখানে কার্টিজ ওয়েব ইন্টারফেস পরিবেশন করে - 8080। আসুন এটিতে যান এবং একবার দেখে নেওয়া যাক:

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