স্টোরেজ ক্যাপাসিটি ট্র্যাকিং সহ ক্ষণস্থায়ী ভলিউম: স্টেরয়েডগুলিতে খালি ডির

কিছু অ্যাপ্লিকেশানের ডেটা সঞ্চয় করারও প্রয়োজন, তবে তারা এই বিষয়টি নিয়ে বেশ আরামদায়ক যে ডেটা পুনরায় চালু করার পরে সংরক্ষণ করা হবে না।

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

Kubernetes ইতিমধ্যে বিভিন্ন ধরনের আছে ক্ষণস্থায়ী ভলিউম, কিন্তু তাদের কার্যকারিতা K8 এ যা প্রয়োগ করা হয়েছে তার মধ্যে সীমাবদ্ধ।

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

এটি ভলিউমগুলির জন্য একটি সমস্যা হতে পারে যা উল্লেখযোগ্য হোস্ট সংস্থানগুলি ব্যবহার করে বা শুধুমাত্র কিছু হোস্টে উপলব্ধ স্টোরেজের জন্য। এই কারণেই কুবারনেটস 1.19 দুটি নতুন আলফা টেস্টিং ভলিউম বৈশিষ্ট্য উপস্থাপন করেছে যা ধারণাগতভাবে EmptyDir ভলিউমের মতো:

• সাধারণ উদ্দেশ্য ক্ষণস্থায়ী ভলিউম;

• CSI স্টোরেজ ক্ষমতা ট্র্যাকিং।

নতুন পদ্ধতির সুবিধা:

• স্টোরেজ স্থানীয় বা নেটওয়ার্কের মাধ্যমে সংযুক্ত হতে পারে;

• ভলিউমগুলির একটি নির্দিষ্ট আকার থাকতে পারে যা অ্যাপ্লিকেশন দ্বারা অতিক্রম করা যাবে না;

• যেকোন CSI ড্রাইভারের সাথে কাজ করে যা স্থায়ী ভলিউমের বিধান সমর্থন করে এবং (ক্ষমতা ট্র্যাকিং সমর্থন করতে) কলটি বাস্তবায়ন করে GetCapacity;

• ড্রাইভার এবং সেটিংসের উপর নির্ভর করে ভলিউমগুলিতে কিছু প্রাথমিক ডেটা থাকতে পারে;

• ভলিউম সহ সমস্ত স্ট্যান্ডার্ড অপারেশন (একটি স্ন্যাপশট তৈরি করা, আকার পরিবর্তন করা ইত্যাদি) সমর্থিত;

• ভলিউম যেকোন অ্যাপ্লিকেশন কন্ট্রোলারের সাথে ব্যবহার করা যেতে পারে যা একটি মডিউল বা ভলিউম স্পেসিফিকেশন গ্রহণ করে;

• Kubernetes শিডিউলকারী তার নিজের থেকে উপযুক্ত নোড নির্বাচন করে, তাই আপনাকে আর শিডিউলার এক্সটেনশনগুলিকে প্রভিশন এবং কনফিগার করতে এবং ওয়েবহুক পরিবর্তন করতে হবে না।

অ্যাপ্লিকেশন অপশন

অতএব, সাধারণ উদ্দেশ্য ক্ষণস্থায়ী ভলিউম নিম্নলিখিত ব্যবহারের ক্ষেত্রে উপযুক্ত:

মেমক্যাশেডের জন্য RAM এর প্রতিস্থাপন হিসাবে স্থায়ী মেমরি

মেমক্যাশেডের সর্বশেষ রিলিজ সমর্থন যোগ করা হয়েছে ক্রমাগত মেমরি ব্যবহার করে (Intel Optane, ইত্যাদি, প্রায়. অনুবাদক) নিয়মিত RAM এর পরিবর্তে। একটি অ্যাপ্লিকেশন কন্ট্রোলারের মাধ্যমে মেমক্যাশ স্থাপন করার সময়, আপনি CSI ড্রাইভার ব্যবহার করে PMEM থেকে প্রদত্ত আকারের একটি ভলিউম বরাদ্দ করার অনুরোধ করতে সাধারণ উদ্দেশ্য ক্ষণস্থায়ী ভলিউম ব্যবহার করতে পারেন, উদাহরণস্বরূপ PMEM-CSI.

একটি কর্মক্ষেত্র হিসাবে LVM স্থানীয় স্টোরেজ

RAM-এর চেয়ে বড় ডেটা নিয়ে কাজ করে এমন অ্যাপ্লিকেশনগুলির জন্য একটি আকার বা কর্মক্ষমতা মেট্রিক্স সহ স্থানীয় স্টোরেজ প্রয়োজন হতে পারে যা Kubernetes থেকে নিয়মিত EmptyDir ভলিউম সরবরাহ করতে পারে না। উদাহরণস্বরূপ, এই উদ্দেশ্যে এটি লেখা হয়েছিল TopoLVM.

ডেটা ভলিউমের জন্য শুধুমাত্র-পঠন অ্যাক্সেস

একটি ভলিউম বরাদ্দের ফলে একটি পূর্ণ ভলিউম তৈরি হতে পারে যখন:

• পুন: প্রতিষ্ঠা ভলিউম স্ন্যাপশট;

• সৃষ্টি ভলিউম কপি;

• The তথ্য স্থানধারক.

এই ভলিউমগুলি শুধুমাত্র-পঠন মোডে মাউন্ট করা যেতে পারে।

এগুলো কিভাবে কাজ করে

সাধারণ উদ্দেশ্য ক্ষণস্থায়ী ভলিউম

সাধারণ উদ্দেশ্য ক্ষণস্থায়ী ভলিউমের একটি মূল বৈশিষ্ট্য হল নতুন ভলিউম উৎস, EphemeralVolumeSource, একটি ভলিউম অনুরোধ তৈরি করার জন্য সমস্ত ক্ষেত্র রয়েছে (ঐতিহাসিকভাবে একটি স্থায়ী ভলিউম অনুরোধ, PVC বলা হয়)। নতুন কন্ট্রোলার ইন kube-controller-manager এমন একটি ভলিউম উৎস তৈরি করে এমন পডগুলি দেখে এবং তারপর সেই পডগুলির জন্য একটি পিভিসি তৈরি করে৷ CSI ড্রাইভারের জন্য, এই অনুরোধটি অন্যদের মতই দেখায়, তাই এখানে বিশেষ সমর্থনের প্রয়োজন নেই।

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

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

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

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

স্টোরেজ ক্যাপাসিটি ট্র্যাকিং

সাধারণত সিএসআই ড্রাইভার কোথায় ভলিউম তৈরি করবে সে সম্পর্কে শিডিউলারের কোন জ্ঞান নেই। এই তথ্যের অনুরোধ করার জন্য শিডিউলারের সরাসরি ড্রাইভারের সাথে যোগাযোগ করার কোন উপায় নেই। অতএব, শিডিউলার পোল নোডগুলি যতক্ষণ না এটি এমন একটি খুঁজে পায় যার উপর ভলিউমগুলি অ্যাক্সেস করা যেতে পারে (দেরীতে বাঁধাই) বা অবস্থানের পছন্দ সম্পূর্ণভাবে ড্রাইভারের উপর ছেড়ে দেয় (তাত্ক্ষণিক বাঁধাই)৷

নতুন এপিআই CSIStorageCapacity, যা আলফা পর্যায়ে রয়েছে, প্রয়োজনীয় ডেটা etcd-এ সংরক্ষণ করার অনুমতি দেয় যাতে এটি শিডিউলারের কাছে উপলব্ধ হয়। সাধারণ উদ্দেশ্য ক্ষণস্থায়ী ভলিউমের জন্য সমর্থনের বিপরীতে, আপনি যখন ড্রাইভার স্থাপন করেন, তখন আপনাকে অবশ্যই সঞ্চয় ক্ষমতা ট্র্যাকিং সক্ষম করতে হবে: external-provisioner স্বাভাবিক মাধ্যমে ড্রাইভার থেকে প্রাপ্ত ক্ষমতা তথ্য প্রকাশ করা উচিত GetCapacity.

যদি সময়সূচীকে এমন একটি পডের জন্য একটি নোড নির্বাচন করতে হয় যাতে একটি আনবাউন্ড ভলিউম দেরী বাইন্ডিং ব্যবহার করে এবং ড্রাইভারটি পতাকা সেট করে স্থাপনের সময় এই বৈশিষ্ট্যটি সক্ষম করে। CSIDriver.storageCapacity, তারপরে পর্যাপ্ত স্টোরেজ ক্ষমতা নেই এমন নোডগুলি স্বয়ংক্রিয়ভাবে বাতিল হয়ে যাবে। এটি সাধারণ উদ্দেশ্য ক্ষণস্থায়ী এবং স্থায়ী ভলিউমের জন্য কাজ করে, কিন্তু CSI ক্ষণস্থায়ী ভলিউমের জন্য নয় কারণ তাদের পরামিতিগুলি কুবারনেটস দ্বারা পড়তে পারে না।

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

যেহেতু kubernetes সময়সূচীকে সম্ভাব্য পুরানো তথ্যের সাথে কাজ করতে বাধ্য করা হয়, তাই ভলিউম তৈরি করার সময় প্রতিটি ক্ষেত্রেই ক্ষমতা উপলব্ধ হবে এমন কোন গ্যারান্টি নেই, তবে পুনরায় চেষ্টা ছাড়াই এটি তৈরি হওয়ার সম্ভাবনা তবুও বৃদ্ধি পেয়েছে।

বিশেষ দ্রষ্টব্য আপনি আরও বিশদ তথ্য পেতে পারেন, সেইসাথে নিরাপদে "বিড়াল স্ট্যান্ডে অনুশীলন" করতে পারেন এবং সম্পূর্ণরূপে বোধগম্য পরিস্থিতির ক্ষেত্রে, নিবিড় কোর্সে যোগ্য প্রযুক্তিগত সহায়তা সহায়তা পেতে পারেন - কুবারনেটস বেস 28-30 সেপ্টেম্বর অনুষ্ঠিত হবে, এবং আরও উন্নত বিশেষজ্ঞদের জন্য কুবারনেটস মেগা অক্টোবর 14-16।

নিরাপত্তা

সিএসআইস্টোরেজ ক্যাপাসিটি

CSIStorageCapacity অবজেক্টগুলি নামস্থানে থাকে; প্রতিটি CSI ড্রাইভারকে তার নিজস্ব নামস্থানে রোল আউট করার সময়, সেই স্থানের CSIStorageCapacity-এ RBAC অধিকারগুলিকে সীমাবদ্ধ করার সুপারিশ করা হয় কারণ এটি স্পষ্ট যে ডেটা কোথা থেকে আসছে। কুবারনেটস যাইহোক এটি পরীক্ষা করে না, এবং সাধারণত ড্রাইভারগুলিকে একই নামস্থানে রাখা হয়, তাই শেষ পর্যন্ত ড্রাইভারগুলি কাজ করবে এবং ভুল ডেটা প্রকাশ করবে না বলে আশা করা হয় (এবং এখানেই আমার কার্ড ব্যর্থ হয়েছে, প্রায়. দাড়িওয়ালা কৌতুকের উপর ভিত্তি করে অনুবাদক)

সাধারণ উদ্দেশ্য ক্ষণস্থায়ী ভলিউম

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

উদাহরণ

আলাদা শাখা PMEM-CSI-এ আলফা পর্যায়ের সমস্ত বৈশিষ্ট্য সহ QEMU ভার্চুয়াল মেশিনের ভিতরে একটি Kubernetes 1.19 ক্লাস্টার চালানোর জন্য প্রয়োজনীয় সমস্ত পরিবর্তন রয়েছে। ড্রাইভার কোড পরিবর্তিত হয়নি, শুধুমাত্র স্থাপনা পরিবর্তিত হয়েছে.

একটি উপযুক্ত মেশিনে (লিনাক্স, একজন সাধারণ ব্যবহারকারী ব্যবহার করতে পারেন ডকশ্রমিক, দেখুন এখানে বিস্তারিত) এই কমান্ডগুলি ক্লাস্টার আনবে এবং PMEM-CSI ড্রাইভার ইনস্টল করবে:

git clone --branch=kubernetes-1-19-blog-post https://github.com/intel/pmem-csi.git
cd pmem-csi
export TEST_KUBERNETES_VERSION=1.19 TEST_FEATURE_GATES=CSIStorageCapacity=true,GenericEphemeralVolume=true TEST_PMEM_REGISTRY=intel
make start && echo && test/setup-deployment.sh

সবকিছু কাজ করার পরে, আউটপুটে ব্যবহারের জন্য নির্দেশাবলী থাকবে:

The test cluster is ready. Log in with [...]/pmem-csi/_work/pmem-govm/ssh.0, run
kubectl once logged in.  Alternatively, use kubectl directly with the
following env variable:
   KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.config

secret/pmem-csi-registry-secrets created
secret/pmem-csi-node-secrets created
serviceaccount/pmem-csi-controller created
...
To try out the pmem-csi driver ephemeral volumes:
   cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
   [...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -

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

$ kubectl get 
        -o go-template='{{range .items}}{{if eq .storageClassName "pmem-csi-sc-late-binding"}}{{.metadata.name}} {{.nodeTopology.matchLabels}} {{.capacity}}
{{end}}{{end}}' 
        csistoragecapacities
csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 30716Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

একটি একক বস্তুর নিম্নলিখিত বিষয়বস্তু রয়েছে:

$ kubectl describe csistoragecapacities/csisc-6cw8j
Name:         csisc-sqdnt
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  storage.k8s.io/v1alpha1
Capacity:     30716Mi
Kind:         CSIStorageCapacity
Metadata:
  Creation Timestamp:  2020-08-11T15:41:03Z
  Generate Name:       csisc-
  Managed Fields:
    ...
  Owner References:
    API Version:     apps/v1
    Controller:      true
    Kind:            StatefulSet
    Name:            pmem-csi-controller
    UID:             590237f9-1eb4-4208-b37b-5f7eab4597d1
  Resource Version:  2994
  Self Link:         /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
  UID:               da36215b-3b9d-404a-a4c7-3f1c3502ab13
Node Topology:
  Match Labels:
    pmem-csi.intel.com/node:  pmem-csi-pmem-govm-worker1
Storage Class Name:           pmem-csi-sc-late-binding
Events:                       <none>

আসুন একটি একক সাধারণ উদ্দেশ্য ক্ষণস্থায়ী ভলিউম সহ একটি ডেমো অ্যাপ্লিকেশন তৈরি করার চেষ্টা করি। ফাইল বিষয়বস্তু pmem-app-ephemeral.yaml:

# This example Pod definition demonstrates
# how to use generic ephemeral inline volumes
# with a PMEM-CSI storage class.
kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app-inline-volume
spec:
  containers:
    - name: my-frontend
      image: intel/pmem-csi-driver-test:v0.7.14
      command: [ "sleep", "100000" ]
      volumeMounts:
      - mountPath: "/data"
        name: my-csi-volume
  volumes:
  - name: my-csi-volume
    ephemeral:
      volumeClaimTemplate:
        spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 4Gi
          storageClassName: pmem-csi-sc-late-binding

তৈরি করার পরে, উপরের নির্দেশাবলীতে দেখানো হয়েছে, আমাদের কাছে এখন একটি অতিরিক্ত পড এবং পিভিসি রয়েছে:

$ kubectl get pods/my-csi-app-inline-volume -o wide
NAME                       READY   STATUS    RESTARTS   AGE     IP          NODE                         NOMINATED NODE   READINESS GATES
my-csi-app-inline-volume   1/1     Running   0          6m58s   10.36.0.2   pmem-csi-pmem-govm-worker1   <none>           <none>
$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
NAME                                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
my-csi-app-inline-volume-my-csi-volume   Bound    pvc-c11eb7ab-a4fa-46fe-b515-b366be908823   4Gi        RWO            pmem-csi-sc-late-binding   9m21s

পিভিসি মালিক - অধীনে:

$ kubectl get -o yaml pvc/my-csi-app-inline-volume-my-csi-volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    pv.kubernetes.io/bind-completed: "yes"
    pv.kubernetes.io/bound-by-controller: "yes"
    volume.beta.kubernetes.io/storage-provisioner: pmem-csi.intel.com
    volume.kubernetes.io/selected-node: pmem-csi-pmem-govm-worker1
  creationTimestamp: "2020-08-11T15:44:57Z"
  finalizers:
  - kubernetes.io/pvc-protection
  managedFields:
    ...
  name: my-csi-app-inline-volume-my-csi-volume
  namespace: default
  ownerReferences:
  - apiVersion: v1
    blockOwnerDeletion: true
    controller: true
    kind: Pod
    name: my-csi-app-inline-volume
    uid: 75c925bf-ca8e-441a-ac67-f190b7a2265f
...

জন্য প্রত্যাশিত আপডেট তথ্য pmem-csi-pmem-govm-worker1:

csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 26620Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

যদি অন্য অ্যাপ্লিকেশনের 26620Mi-এর বেশি প্রয়োজন হয়, তাহলে শিডিউলকারী বিবেচনা করবে না pmem-csi-pmem-govm-worker1 যে কোনো ক্ষেত্রে.

এরপরে কী?

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

• KEP-1698: জেনেরিক ক্ষণস্থায়ী ইনলাইন ভলিউম

• KEP-1472: স্টোরেজ ক্যাপাসিটি ট্র্যাকিং

উত্স: www.habr.com