Back in November of last year when the announcement was made that Ingress-NGINX was being retired, மற்ற பலரைப் போலவே நாமும் சற்று கவனத்தில் கொள்ளப்பட்டோம். நாங்கள் குபெர்னெட்டஸுக்குச் சென்றதில் இருந்து இன்க்ரெஸ்-என்ஜிஐஎன்எக்ஸ் எங்கள் போக்குவரத்து வழித்தடத்தைக் கையாண்டது. புதியதைப் பற்றி கொஞ்சம் பேசப்பட்டது[–>Gateway API இது Ingress ஐ மாற்றுகிறது மற்றும் அதற்கு மாறுவது பயனுள்ளதாக இருக்கும், ஆனால் தீவிரமான ஆற்றல் முதலீடு செய்யப்படவில்லை. Ingress-NGINX நன்றாக வேலை செய்தது மேலும் எனக்கு இன்னும் நிறைய வேலைகள் இருந்தன. இப்போது, ஓய்வு பெற வேண்டிய கட்டாயத்தில், நாங்கள் ஒரு திட்டத்தை உருவாக்கி அதை குறுகிய கால வரைபடத்தில் பொருத்த வேண்டும்.
உடன் ஏ[–>vast landscape of options, செயல்படுத்தல்களை நிறுவி அவற்றைச் சோதிக்கத் தொடங்கும் முன், சாத்தியக்கூறுகளைக் குறைக்க வேண்டும். மற்றொரு இன்க்ரஸ் கன்ட்ரோலரைக் காட்டிலும் கேட்வே API க்கு நகர்த்தவும், புதிய அம்சங்களைப் பயன்படுத்திக் கொள்ளவும், பாத்திரங்களை சிறப்பாகப் பிரிக்கவும் இந்த வாய்ப்பைப் பயன்படுத்த விரும்புகிறோம் என்பதில் நாங்கள் உறுதியாக இருந்தோம். நாங்கள் இதை விரைவாகச் செய்ய வேண்டும், இருப்பினும், கேட்வே API இல் ஹெட்விண்ட்ஸ் இருந்தால், மற்றொரு இன்க்ரெஸ் செயல்படுத்தலுக்கு மாறுவதும் ஒரு விருப்பமாக இருக்கலாம்.
சில ஆரம்ப ஆராய்ச்சியின் மூலம், விளையாடும் மைதானத்தை மூன்று கேட்வே செயலாக்கங்கள் மற்றும் காப்புப்பிரதிகளாக இரண்டு நுழைவு விருப்பங்களாகக் குறைக்க சில அளவுகோல்களை நாங்கள் அமைத்துள்ளோம்.
- NGINX கேட்வே துணி
- போக்குவரத்து
- இஸ்டியோ
எங்களின் முதல் அளவுகோல், எங்கள் மாற்றீடு செயல்படுத்தப்பட வேண்டும் என்பதே[–>the list of fully-conformant implementations. ஒப்பிட்டுப் பார்ப்பதற்கு இது ஒரு நல்ல அடிப்படையைக் கொடுக்கும். நாங்கள் GCP மற்றும் Azure இல் இயங்குகிறோம், எனவே கிளவுட்-சார்ந்த தீர்வுகளை அகற்றியுள்ளோம். அங்கிருந்து பார்த்தோம்[–>1.4 feature matrix, ஏ[–>third-party benchmark மற்றும் ஒவ்வொரு செயல்படுத்தலின் சில தனிப்பட்ட அம்சங்கள். இது மேலே குறிப்பிட்டுள்ள மூன்று விருப்பங்களை எங்களுக்கு விட்டுச்சென்றது.
துரதிர்ஷ்டவசமாக, எங்கள் பழைய நண்பர்[–>HAProxy நான் இந்தத் திட்டத்தைத் தொடங்கும் போது நிராகரிக்கப்பட்ட செயலாக்கங்கள் பட்டியலில் இருந்தது. ஸ்டாக் ஓவர்ஃப்ளோவை GKE க்கு மாற்றுவதற்கு முன் பல ஆண்டுகளாக தரவு மையத்தில் HAProxyஐ நம்பகத்தன்மையுடன் பயன்படுத்தினேன். அது கண்டிப்பாக சோதனைக்கு கட் செய்திருக்கும். எழுதும் நேரத்தில், அது முழு இணக்கத்திற்கு நகர்த்தப்பட்டது.
Ingress உடன் ஒட்டிக்கொள்வதற்கான ஃபால்பேக் விருப்பங்களைப் பொறுத்தவரை, Traefik NGINX உடன் அதன் சிறுகுறிப்பு இணக்கத்தன்மையுடன் ஒரு கட்டாய வழக்கை உருவாக்கியது. நடைமுறையில், அவற்றில் பெரும்பாலானவை[–>annotations நாங்கள் பயன்படுத்துகிறோம் மறைக்கப்படவில்லை, எனவே விருப்பம் அதன் பிரகாசத்தை இழந்தது. F5 NGINX உள்ளீடு செயல்படுத்தல் ஒரு பாதுகாப்பான பந்தயம் என்று தோன்றியது, ஆனால் மேம்பட்ட ரூட்டிங் நிலையான குபெர்னெட்ஸ் வகைகளை விட செயல்படுத்தல் சார்ந்த ஆதாரங்களை நம்பியிருப்பதை நான் கண்டேன். பயன்படுத்தப்படும் நிலையான இடைமுகங்களை அடிப்படையாகக் கொண்ட பிற கட்டுப்படுத்திகளை ஒருங்கிணைக்க முயற்சிக்கும்போது இது சிக்கல்களை ஏற்படுத்துகிறது.
முடிவில், வேறொரு உள்ளீட்டிற்கு மாறுவதை என்னால் நியாயப்படுத்த முடியவில்லை, அதனால் நான் அவற்றை ஆரம்பத்திலேயே சோதிப்பதை விட்டுவிட்டேன்.
சோதனைக்காக எங்களின் உபயோகப் பொருட்களை உருவாக்க, எங்கள் முக்கிய தயாரிப்பு கிளஸ்டர்களில் இருந்து YAML கோப்புகளுக்கு அனைத்து உள்ளீட்டு பொருட்களையும் மாற்றியுள்ளோம், மேலும் அவற்றை வெவ்வேறு பயன்பாட்டு கேஸ் பக்கெட்களாக அலசவும் வரிசைப்படுத்தவும் Claude ஐப் பயன்படுத்தினோம். எங்களின் பெரும்பாலான வழித்தடங்கள் சில வெளியூர்களுடன் மிகவும் நேரடியானவை. இது எங்களுக்கு எழுதுவதற்கு சுமார் அரை டஜன் பயன்பாட்டு கேஸ் சோதனைகளை விட்டுச்சென்றது, மேலும் இரண்டு வெவ்வேறு அளவிடுதல் அளவுகோல்களை இயக்க வேண்டும்.
சோதனை அமைப்பிற்கு, முக்கிய பின்தளத்தில் HTTPBin செயல்படுத்தல் இருந்தது. HTTP தொடர்பான எதையும் சோதிக்க இது ஒரு சிறந்த கருவியாகும், இது ஒரு சோதனை கிளையண்டின் கோரிக்கை மற்றும் பதில் இரண்டையும் சரிபார்க்க உங்களை அனுமதிக்கிறது. இதற்கு ஒரு சிறந்த உதாரணம்: சில ட்ராஃபிக்கிற்காக ஹோஸ்ட் தலைப்புகளை மாறும் வகையில் மேலெழுத வேண்டிய ஒரு சந்தர்ப்பம் எங்களிடம் உள்ளது. HTTPBin உள்ளது /headers கோரிக்கை தலைப்புகளை JSON பதிலாக வழங்கும் இறுதிப்புள்ளி. இது ஒரு சோதனை வழக்கை எழுத அனுமதிக்கிறது, அங்கு நாம் X ஹோஸ்ட் தலைப்பை அனுப்புகிறோம் மற்றும் சேவையகம் Y ஹோஸ்ட் தலைப்பைப் பெறும் என்று எதிர்பார்க்கிறோம்.
இரண்டாவது பின்தளத்தில் செயல்படுத்தப்பட்டது perf.இது மிகவும் எளிமையான Go இணைய சேவையகமாகும், இது அதிக எண்ணிக்கையிலான கோரிக்கைகளுக்கு மிக விரைவாக பதிலளிக்க முடியும். செயல்திறன் வரம்புகள் எங்குள்ளது என்பதைப் பார்க்க, நுழைவாயிலின் கோரிக்கை விகிதத்தை அதிகரிக்க இது அனுமதிக்கும். செயலில் உள்ள இணைப்புகள் மற்றும் கோரிக்கைகளின் எண்ணிக்கை அதிகரிக்கத் தொடங்கும் பட்சத்தில், செயல்திறன் சோதனைக்கு மெதுவான பதில்களை உருவகப்படுத்த, தாமத மதிப்பை அனுப்ப, இணைய சேவையகத்தில் ஒரு அளவுரு சேர்க்கப்பட்டது. எனக்குத் தெரியாது, ஆனால் HTTPBin அதே திறனுடன் ஒரு முடிவுப் புள்ளியைக் கொண்டுள்ளது. அதிக சுமையின் கீழ் HTTPBin இன் செயல்திறனைப் பற்றி எனக்குத் தெரியவில்லை, எனவே சோதனைகள் Go சேவையகத்தைப் பயன்படுத்துகின்றன. சோதனை அமைப்பு இப்படி இருந்தது.
மூன்று வரிசைப்படுத்தல்களை அமைப்பது மிகவும் நேரடியானது, இருப்பினும் ட்ரேஃபிக் உடன் நான் கண்டறிந்த ஒரு ஆரம்ப எரிச்சல் ஒரு ட்ரேஃபிக் “நுழைவுப் புள்ளி” அமைக்க வேண்டிய அவசியம். இது TCP கேட்பவரை உள்ளமைக்கும் Traefik குறிப்பிட்ட உள்ளமைவு பகுதியாகும். நீங்கள் இதைச் சேர்த்து ஒரு நுழைவாயிலை உருவாக்கவில்லை என்றால், நீங்கள் நுழைவாயிலில் சேர்க்கும் கேட்போர் பிழையை எறிவார்கள். இது நுழைவாயில் சுருக்கத்தை ஓரளவிற்கு உடைக்கிறது.
மூன்று செயலாக்கங்களும் எங்கள் பயன்பாட்டு நிகழ்வுகளைக் கையாள முடிந்தது. கேட்வே ஏபிஐ அம்சங்களில் நாங்கள் சுவாரஸ்யமாகக் கண்டோம், இஸ்டியோ பெரும்பாலான பெட்டிகளைத் தேர்ந்தெடுத்தது மற்றும் ட்ரேஃபிக் குறைந்தது. நாங்கள் விரைவாகக் கற்றுக்கொண்ட ஒரு விஷயம் என்னவென்றால், சில கேட்வே ஏபிஐ அம்சங்கள் காகிதத்தில் நன்றாகத் தெரிந்தன, ஆனால் நமக்குத் தேவையான ஆழம் இல்லை. எடுத்துக்காட்டாக, தலைப்பு மாற்றியமைத்தல் செயல்பாடு in[–>HTTPRoute நிலையான மதிப்புகளை மட்டுமே கையாளுகிறது. மேலே குறிப்பிட்டுள்ள நிலையில், நமக்கு ஒரு டைனமிக் ரீஜெக்ஸ் வெளிப்பாடு தேவைப்பட்டால், ஒவ்வொரு செயல்படுத்தலின் நீட்டிப்புப் புள்ளிகளுக்கும் நாம் செல்ல வேண்டியிருந்தது. இவை அனைத்தும் எங்கள் தேவைகளைப் பூர்த்தி செய்யும் அளவுக்கு நெகிழ்வானவை மற்றும் உங்கள் தேவைகள் மற்றும் செயல்படும் செயல்பாட்டைப் பொறுத்து xRoute அல்லது கேட்வேயின் சூழலில் இருந்து வெவ்வேறு நடத்தைகளை குறிப்பிட அனுமதித்தது. நாங்கள் சோதித்த நிகழ்வுகளுக்கு, இஸ்டியோ வடிப்பான்கள் NGINX அல்லது Traefik சமமானதை விட மிகவும் சிக்கலானதாக இருந்தன.
சில சந்தர்ப்பங்களில், செயல்படுத்தல்-குறிப்பிட்ட நடத்தை போதுமான அளவு மாறிவிட்டது, அவற்றைச் செயல்படுத்த எங்கள் பயன்பாடுகளை மாற்றியமைக்க வேண்டியிருந்தது. தற்போது பயன்படுத்துகிறோம் ngx_http_auth_request_module அங்கீகார சேவைக்கு கோரிக்கைகளை அனுப்ப. மற்ற செயலாக்கங்கள் ஒரே மாதிரியான செயல்பாட்டைக் கொண்டுள்ளன, ஆனால் இஸ்டியோவின் வெளிப்புற அங்கீகாரம் கணிசமாக வித்தியாசமாக செயல்படுகிறது. இது போன்ற சிக்கலான ஒருங்கிணைப்புகள் வலி புள்ளிகள் மற்றும் நீங்கள் ஒரு புதிய தீர்வுக்கு இடம்பெயரும் போது விஷயங்களை கணிசமாக மெதுவாக்கும்.
செயல்திறன் பகுப்பாய்வை நான் விரும்புகிறேன், எனவே முயல் துளைகளுக்குச் சென்று மிகவும் விரிவான தகவல்களைச் சேகரிப்பது எனக்கு மிகவும் எளிதானது. இந்த விஷயத்தில், மிகக் குறைந்த நேரம் மற்றும் ஆதாரங்களுடன், விஷயங்களை எளிமையாகவும் நடைமுறை ரீதியாகவும் வைத்திருப்பதில் நான் உறுதியாக இருக்க வேண்டும். மறைமுகமாக, சில அளவில், மிகத் தெளிவான வெற்றியாளர்களும் தோல்வியுற்றவர்களும் இருப்பார்கள். ஆனால் பொதுவான அளவுகோல் ஒப்பீட்டை நாங்கள் முயற்சிக்கவில்லை. இந்த செயலாக்கங்கள் நமது தற்போதைய அளவிடுதல் தேவைகளை பூர்த்தி செய்யுமா என்பதை நாம் தெரிந்து கொள்ள வேண்டும்.
நாங்கள் சோதிக்க வேண்டிய இரண்டு முதன்மை அளவிடுதல் காரணிகள் எங்களிடம் இருந்தன. எங்கள் பொது ஸ்டாக் எக்ஸ்சேஞ்ச் தள நெட்வொர்க்கிற்கு, ஒவ்வொரு வரிசைப்படுத்துதலும் எங்கள் தினசரி போக்குவரத்தின் ஒரு பகுதியை நியாயமான எண்ணிக்கையிலான பிரதிகளுடன் கையாள முடியும் என்பதை நாங்கள் சரிபார்க்க வேண்டும். எங்கள் நிறுவன தயாரிப்புக்காக, ஒவ்வொரு வாடிக்கையாளரும் தற்போது எட்டு நுழைவு ஆதாரங்களைப் பெறுகிறார்கள், எனவே HTTPRoutes எண்ணிக்கையை அளவிடுவதை நாங்கள் சோதிக்க விரும்புகிறோம்.
ஆர்பிஎஸ் வெர்சஸ் கேட்வேஸ் பெஞ்ச்மார்க்கிற்கு, 10,000 ஆர்பிஎஸ் இலக்கைத் தேர்ந்தெடுத்தோம், இது எங்களின் வழக்கமான நிலையான டிராஃபிக்கை விட சில ஹெட்ரூமை விட்டுச் செல்லும். சில சோதனைச் சுற்றுச் சோதனைகளுக்குப் பிறகு, ஒவ்வொரு நுழைவாயிலின் நான்கு பிரதிகள், ஒவ்வொன்றும் தனித்தனி முனையில் இருக்கும்படி சோதனைச் சூழலை அமைத்துள்ளோம். இவை இருந்தன e2-standard-4 GCP கம்ப்யூட் முனைகள். சோதனை கிளையண்டிற்கு, அதிக எண்ணிக்கையிலான இணைப்புகளைக் கையாளும் வகையில் கட்டமைக்கப்பட்ட கணினியில் K6 ஐ இயக்குகிறோம். கிளையன்ட் ஒரு அஸூரில் ஓடினார் Standard_DC8as_cc_v5 உதாரணம்.
0, 150 மற்றும் 350 எம்எஸ் உருவகப்படுத்தப்பட்ட சர்வர் தாமதத்துடன் சோதனைகளை நடத்தினோம். மூன்று செயலாக்கங்களும் இந்த ஆரம்ப சோதனைகளை சிக்கலின்றி கையாண்டன. அனைத்து சோதனைகளின் முடிவுகளும் ஒப்பீட்டளவில் ஒத்தவை. 150ms தாமத சோதனையின் முடிவுகள் இதோ.
http_req_duration..............: avg=188.27ms min=176ms
med=180.22ms max=820.56ms p(90)=195.11ms p(95)=219.31ms
http_req_duration..............: avg=205.34ms min=176.15ms
med=183.13ms max=1.83s p(90)=244.14ms p(95)=297.59ms
http_req_duration..............: avg=186.73ms min=176.03ms
med=180.52ms max=3.48s p(90)=194.34ms p(95)=216.32ms
ஆரம்பத்தில், 5000 HTTPRoutes இலக்குடன் இந்த சோதனையை நடத்தினேன். இம்மூன்றும் இந்த எண்ணிக்கையிலான வழித்தடங்களில் ஒன்றிணைக்க முடிந்தாலும், எங்களின் நடைமுறை வரம்பு மிகவும் குறைவாக உள்ளது என்பதை பின்னர் அறிந்து கொள்கிறோம். நான் படித்தேன்[–>this third-party benchmark Traefik மற்றும் NGINX இல் உள்ள சில சிக்கல்கள் மற்றும் ரூட்டிங் மாற்றங்களைக் கையாள்வது பற்றி. 5000 HTTPRoutes ஐ உருவாக்கி, ஒவ்வொன்றும் ஒரு வழி விதியுடன் ஒரே மாதிரியான சோதனையை அமைத்தேன், மேலும் சரியான பதிலைத் தரும் வரை அந்த வழிகளுக்கு ஒரே நேரத்தில் கோரிக்கைகளை அனுப்பினேன். இதன் மூலம் அவர்கள் அனைவரும் சரியாக வழியனுப்பி வைக்கப்பட்டிருப்பதைக் காண முடிந்தது.
ட்ரேஃபிக் அனைத்து வழிகளையும் ஏற்றாத மூன்றாம் தரப்பு சோதனைகளில் இருந்து சரியான சிக்கல்களை நான் பார்க்கவில்லை என்றாலும், மற்ற இரண்டு செயலாக்கங்களை விட இது அதிக நேரம் எடுக்கும். ஐந்து நிமிடங்களுக்குப் பிறகு நேரம் முடிந்ததால், Traefikக்கான அசல் தோல்வியடைந்த சோதனையை இங்கே பார்க்கலாம். ஐந்து நிமிட காலக்கெடுவை விட சற்று அதிகமாக எடுத்துக்கொண்டு, அனைத்து வழிகளையும் Traefik ஏற்றியது.
=== RUN TestRoutedPaths
=== RUN TestRoutedPaths/gw-nginx
gateway_test.go:443: 5000/5000 paths pending, retrying in 5s
gateway_test.go:443: 105/5000 paths pending, retrying in 5s
gateway_test.go:443: 105/5000 paths pending, retrying in 5s
gateway_test.go:443: 87/5000 paths pending, retrying in 5s
gateway_test.go:335: applied 5000 HTTPRoutes
gateway_test.go:443: 3/5000 paths pending, retrying in 5s
gateway_test.go:431: all 5000 routes converged in 42.047s
=== RUN TestRoutedPaths/gw-istio
gateway_test.go:443: 5000/5000 paths pending, retrying in 5s
gateway_test.go:443: 1167/5000 paths pending, retrying in 5s
gateway_test.go:443: 93/5000 paths pending, retrying in 5s
gateway_test.go:443: 93/5000 paths pending, retrying in 5s
gateway_test.go:443: 32/5000 paths pending, retrying in 5s
gateway_test.go:443: 32/5000 paths pending, retrying in 5s
gateway_test.go:335: applied 5000 HTTPRoutes
gateway_test.go:431: all 5000 routes converged in 41.981s
=== RUN TestRoutedPaths/gw-traefik
gateway_test.go:443: 5000/5000 paths pending, retrying in 5s
gateway_test.go:443: 4939/5000 paths pending, retrying in 5s
gateway_test.go:443: 4921/5000 paths pending, retrying in 5s
gateway_test.go:335: applied 5000 HTTPRoutes
gateway_test.go:443: 4871/5000 paths pending, retrying in 5s
gateway_test.go:443: 4856/5000 paths pending, retrying in 5s
gateway_test.go:443: 4833/5000 paths pending, retrying in 5s
gateway_test.go:443: 4827/5000 paths pending, retrying in 5s
gateway_test.go:443: 4823/5000 paths pending, retrying in 5s
gateway_test.go:443: 4820/5000 paths pending, retrying in 5s
gateway_test.go:443: 4816/5000 paths pending, retrying in 5s
gateway_test.go:443: 4811/5000 paths pending, retrying in 5s
...
--- FAIL: TestRoutedPaths (441.53s)
--- PASS: TestRoutedPaths/gw-nginx (56.68s)
--- PASS: TestRoutedPaths/gw-istio (79.96s)
--- FAIL: TestRoutedPaths/gw-traefik (304.88s)
--- FAIL: TestRoutedPaths (410.94s)
--- PASS: TestRoutedPaths/gw-nginx (60.82s)
--- PASS: TestRoutedPaths/gw-istio (46.98s)
--- FAIL: TestRoutedPaths/gw-traefik (303.13s)5000 வழிகள் கொண்ட நுழைவாயில் ஏற்றப்பட்டவுடன், இது மிகவும் லட்சியமான இலக்கு என்பதை நாங்கள் கண்டுபிடித்தோம். கேட்வே வழியாக 10k RPS ஐ உருவாக்கிய முந்தைய K6 பெஞ்ச்மார்க்கை இயக்குவது மிகவும் தோல்வியடைந்தது. தாமத நேரங்கள் நம்பமுடியாத அளவிற்கு அதிகமாக இருந்தன மற்றும் சோதனை கிளையன்ட் வெடிக்கும் வரை செயலில் உள்ள கோரிக்கைகளின் எண்ணிக்கை அதிகரிக்கும். ஒரே நுழைவாயிலில் 1,000க்கும் மேற்பட்ட வழித்தடங்கள் தேவைப்படாது என்பதால், இந்த இலக்கை நாங்கள் திருத்தி மீண்டும் K6 பெஞ்ச்மார்க்கை இயக்கினோம். இந்த முறை பதில் நேரங்கள் எங்கள் ஆரம்ப முடிவுகளைப் போலவே இருந்தன.
K6 ட்ராஃபிக் சோதனை இயங்கும் போது பாதைகளை மாற்றுவதையும் சோதித்தேன். இஸ்டியோ மற்றும் ட்ரேஃபிக் பாதிக்கப்படவில்லை, ஆனால் 1,000 வழிகள் கட்டமைக்கப்பட்டபோது ஒரு HTTPRoute புதுப்பிக்கப்பட்டபோது NGINX குறிப்பிடத்தக்க தாமத ஸ்பைக்கை அனுபவித்தது. பாதை புதுப்பிப்புகளின் போது ஏற்பட்ட இரண்டு பெரிய லேட்டன்சி ஸ்பைக்குகளை வரைபடத்தில் காணலாம்.
எங்கள் எல்லா சோதனைகளையும் நடத்தி, இந்த மூன்று செயலாக்கங்களின் அம்சங்களையும் பண்புகளையும் பகுப்பாய்வு செய்த பிறகு, நாங்கள் இஸ்டியோவுடன் முன்னேற முடிவு செய்தோம். அனைத்து சோதனைகளிலும் இஸ்டியோவின் நிலைத்தன்மை மற்றும் செயல்திறன் முக்கிய காரணியாகும். எந்த விருப்பத்திலும் நாம் வெற்றிபெற முடியும் என்று நான் நினைக்கிறேன், ஆனால் இறுதியில் இஸ்டியோ மூன்றில் மிகவும் உறுதியானதாகத் தோன்றியது. நமது தற்போதைய பயன்பாட்டு வழக்கைத் தாண்டி இது பல மேம்பட்ட அம்சங்களைக் கொண்டுள்ளது என்பதும் சுவாரஸ்யமானது.
வரும் வாரங்களில் நாங்கள் குடியேற்றத்தை மேற்கொள்வோம். குறிப்பிடத்தக்க ஏதாவது ஒன்றை நாங்கள் கண்டால், நான் கண்டறிந்ததைப் பகிர்ந்து கொள்ள ஒரு பின்தொடர் இடுகையை எழுதுவதில் மகிழ்ச்சி அடைவேன்.
Leave a Reply