Problems with EV 11 and Amazon S3?

Ever since we upgraded from EV 10 to EV 11 we've been having issues accessing mail that has been migrated to our Amazon S3 storage.  It's not everything, just certain items.  The user gets prompted for credentials and of course no credentials work.  I've been working with Veritas support for the last few days but I don't feel like we're getting anywhere.  Anyone run into any issues like this??

7 Replies

Re: Problems with EV 11 and Amazon S3?

The last thing support told me is that based on the Dtrace, the issues are on Amazon's end.  But if it was working fine before the upgrade to 11, I just can't see how Amazon would be the culprit here!

Re: Problems with EV 11 and Amazon S3?

Try restarting the Net.TCP port sharing service on both servers and see if that improves the performance.

Thanks, but I don't think

Thanks, but I don't think it's a performance issue, the data is not coming back from S3 storage to the local storage.  The error in the event log is:

Unable to fetch item from 
Reason: Unspecified error  (0x80004005) 
Reference: GetOnlineAttachmentFileSize2 

Re: Problems with EV 11 and Amazon S3?

any luck on this one?

Re: Problems with EV 11 and Amazon S3?

No luck at all.  Dtraces have narrowed it down to a problem with some of our Amazon buckets.  For some reason, EV looks through all of the Amazon buckets and is generating an error when it gets to specific buckets.  Problem is with the creation date, apparently.  I deleted one bucket thinking that would be the fix, but it just got stuck on the next bucket and generated an error.  The buckets were just fine with EV 10.  EV 11 has been nothing but problems. 

Here's the dtrace...

<ListAllMyBucketsResult xmlns="http://"><Owner><ID>debf44a1e3678957bf09b37389b15bf3a69f5a180f178848eb9a7bfdad1818f1</ID><DisplayNam...>
<Bucket><Name>1Cloudstore</Name><CreationDate>2013-10-30T13:24:28.000Z</CreationDate></Bucket>
<Bucket><Name>2Cloudstore</Name><CreationDate>2013-10-30T13:28:12.000Z</CreationDate></Bucket>
<Bucket><Name>3Cloudstore</Name><CreationDate>2013-10-30T13:26:31.000Z</CreationDate></Bucket>
<Bucket><Name>CloudberryBackup</Name><CreationDate>2013-10-24T16:27:35.000Z</CreationDate></Bucket>
<Bucket><Name>1Backup</Name><CreationDate>2016-04-25T16:04:05.000Z</CreationDate></Bucket>
<Bucket><Name>2</Name><CreationDate>2011-06-06T22:40:09.000Z</CreationDate></Bucket>
<Bucket><Name>4Cloudstore</Name><CreationDate>2013-10-30T13:29:46.000Z</CreationDate></Bucket>
<Bucket><Name>5Cloudstore</Name><CreationDate>2013-10-30T13:¸¹ òçÍ


It then fails:
 
293    11:48:35.072     [3260]    (StorageManagement)    <17724>    EV:M    OST Streamer: [TID:19324] [Plugin] amazon:9B71D57D4617254EA4A371C2757B4E74: Invalid bucket name
294    11:48:35.072     [3260]    (StorageManagement)    <17724>    EV:M    OST Streamer: [TID:19324] OST API sts_create_lsu() failed with error: 2060001 - 'one or more invalid arguments'.

 

Re: Problems with EV 11 and Amazon S3?

Hi, This has been raised to engineering as an etrack and engineering in looking into this issue currently. Please work with your support representative for more updates around this issue. 

Highlighted

Re: Problems with EV 11 and Amazon S3?

One of the reasons I found is the incorrect bucket naming convention. EV currently checks the bucket naming convention as per amazon recommendations and don't allow any other character in the bucket name for any region. To support that, please see the following link: 

http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html#bucketnamingrules

"While currently, the US East (N. Virginia) region currently allows non-compliant DNS
bucket naming, we are moving to the same DNS-compliant bucket naming convention for the US East (N. Virginia) region in the coming months."

Also see the following comments in the link: 

- The US East (N. Virginia) region currently allows more relaxed standards for bucket naming, which can result in a bucket name that is not DNS-compliant.
- To avoid this problem, amazon recommends as a best practice that you always use DNS-compliant bucket names regardless of the region in which you create the bucket.
- If you use the AWS management console, bucket names must be DNS-compliant in all regions.

So I suggest, you have bucket name as per Amazon recommendation character and check if the issue still persist.